From report at bugs.python.org Tue May 1 00:54:13 2012 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 30 Apr 2012 22:54:13 +0000 Subject: [issue14660] Implement PEP 420: Implicit Namespace Packages In-Reply-To: <1335265720.13.0.725647299701.issue14660@psf.upfronthosting.co.za> Message-ID: <1335826453.01.0.694145197833.issue14660@psf.upfronthosting.co.za> Eric V. Smith added the comment: I've modified zipimport to support namespace packages, and checked it in to the feature branch. This completes all of the functionality I think needs to be added. Next up is adding tests. ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 01:04:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 30 Apr 2012 23:04:45 +0000 Subject: [issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions In-Reply-To: <1280333027.17.0.112361474517.issue9400@psf.upfronthosting.co.za> Message-ID: <1335827085.65.0.285581435216.issue9400@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 01:06:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 30 Apr 2012 23:06:29 +0000 Subject: [issue14157] time.strptime without a year fails on Feb 29 In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za> Message-ID: <1335827189.57.0.194354070285.issue14157@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Fine with me. ---------- nosy: +pitrou stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 01:07:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 30 Apr 2012 23:07:45 +0000 Subject: [issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails) In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335827265.84.0.954461482895.issue14662@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I wasn?t sure whether we should document it? No, it should remain "hidden". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 01:09:16 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 30 Apr 2012 23:09:16 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za> Message-ID: <1335827356.89.0.453200551114.issue14082@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hynek, did you get a notification of my review on Rietveld? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 02:32:59 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Tue, 01 May 2012 00:32:59 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za> Message-ID: <1335832379.46.0.993780936688.issue14082@psf.upfronthosting.co.za> Hynek Schlawack added the comment: I didn't. :/ I'll look into it tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 03:35:24 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 01 May 2012 01:35:24 +0000 Subject: [issue14703] Update PEP metaprocesses to describe PEP czar role Message-ID: <1335836124.46.0.0512543168568.issue14703@psf.upfronthosting.co.za> New submission from Nick Coghlan : The PEP czar role isn't yet described in the relevant meta PEPs. We should fix that, as well as updating the PEP metadata to include the named czar where relevant. ---------- components: None messages: 159740 nosy: ncoghlan priority: normal severity: normal status: open title: Update PEP metaprocesses to describe PEP czar role type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 04:37:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 May 2012 02:37:58 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 96cb47f8142e by Senthil Kumaran in branch '3.2': issue13183 - Fix pdb skipping frames after hitting a breakpoint and running step. Patch by Xavier de Gaye http://hg.python.org/cpython/rev/96cb47f8142e New changeset 5ea23739e9ba by Senthil Kumaran in branch '2.7': issue13183 - Fix pdb skipping frames after hitting a breakpoint and running step. Patch by Xavier de Gaye http://hg.python.org/cpython/rev/5ea23739e9ba New changeset ab63e874265e by Senthil Kumaran in branch 'default': issue13183 - Fix pdb skipping frames after hitting a breakpoint and running step. Patch by Xavier de Gaye http://hg.python.org/cpython/rev/ab63e874265e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 04:49:48 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 01 May 2012 02:49:48 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: <1335840588.2.0.748271193337.issue13183@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Hello Xavier, Thanks for the explanation. Understood the reason for setting the frame_returning to None. The patch is committed in all python versions and the issue is fixed now. Thanks for the patch and prodding through this. -- Senthil ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 06:32:23 2012 From: report at bugs.python.org (Meador Inge) Date: Tue, 01 May 2012 04:32:23 +0000 Subject: [issue14701] parser module doesn't support 'raise ... from' In-Reply-To: <1335812123.91.0.810471517196.issue14701@psf.upfronthosting.co.za> Message-ID: <1335846743.62.0.512793394031.issue14701@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 07:58:54 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 May 2012 05:58:54 +0000 Subject: [issue14371] Add support for bzip2 compression to the zipfile module In-Reply-To: <1332243041.43.0.499117498297.issue14371@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 028e8e0b03e8 by Martin v. L?wis in branch 'default': Issue #14371: Support bzip2 in zipfile module. http://hg.python.org/cpython/rev/028e8e0b03e8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 07:59:21 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 01 May 2012 05:59:21 +0000 Subject: [issue14371] Add support for bzip2 compression to the zipfile module In-Reply-To: <1332243041.43.0.499117498297.issue14371@psf.upfronthosting.co.za> Message-ID: <1335851961.67.0.746300520463.issue14371@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 08:47:32 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 01 May 2012 06:47:32 +0000 Subject: [issue14366] Supporting lzma compression in zip files In-Reply-To: <1332112236.1.0.964135054036.issue14366@psf.upfronthosting.co.za> Message-ID: <1335854852.66.0.291130369665.issue14366@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- title: Supporting bzip2 and lzma compression in zip files -> Supporting lzma compression in zip files _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 10:33:13 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 May 2012 08:33:13 +0000 Subject: [issue14366] Supporting lzma compression in zip files In-Reply-To: <1335854852.73.0.902143665291.issue14366@psf.upfronthosting.co.za> Message-ID: <1335861332.2567.15.camel@raxxla> Serhiy Storchaka added the comment: Here is the patch which adds support for lzma in zipfile. Later I'll move `lzma_props_encode` and `lzma_props_decode` to lzma module. ---------- Added file: http://bugs.python.org/file25430/lzma_in_zip.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 7bdac82c16ab Doc/library/zipfile.rst --- a/Doc/library/zipfile.rst Tue May 01 09:00:59 2012 +0200 +++ b/Doc/library/zipfile.rst Tue May 01 11:29:44 2012 +0300 @@ -97,12 +97,20 @@ .. versionadded:: 3.3 +.. data:: ZIP_LZMA + + The numeric constant for the LZMA compression method. This requires the + lzma module. + + .. versionadded:: 3.3 + .. note:: The ZIP file format specification has included support for bzip2 compression - since 2001. However, some tools (including older Python releases) do not - support it, and may either refuse to process the ZIP file altogether, or - fail to extract individual files. + since 2001, and for LZMA compression since 2006. However, some tools + (including older Python releases) do not support these compression + methods, and may either refuse to process the ZIP file altogether, + or fail to extract individual files. .. seealso:: @@ -133,11 +141,11 @@ adding a ZIP archive to another file (such as :file:`python.exe`). If *mode* is ``a`` and the file does not exist at all, it is created. *compression* is the ZIP compression method to use when writing the archive, - and should be :const:`ZIP_STORED`, :const:`ZIP_DEFLATED`; or - :const:`ZIP_DEFLATED`; unrecognized - values will cause :exc:`RuntimeError` to be raised. If :const:`ZIP_DEFLATED` or - :const:`ZIP_BZIP2` is specified but the corresponded module - (:mod:`zlib` or :mod:`bz2`) is not available, :exc:`RuntimeError` + and should be :const:`ZIP_STORED`, :const:`ZIP_DEFLATED`, + :const:`ZIP_BZIP2` or :const:`ZIP_LZMA`; unrecognized + values will cause :exc:`RuntimeError` to be raised. If :const:`ZIP_DEFLATED`, + :const:`ZIP_BZIP2` or :const:`ZIP_LZMA` is specified but the corresponded module + (:mod:`zlib`, :mod:`bz2` or :mod:`lzma`) is not available, :exc:`RuntimeError` is also raised. The default is :const:`ZIP_STORED`. If *allowZip64* is ``True`` zipfile will create ZIP files that use the ZIP64 extensions when the zipfile is larger than 2 GB. If it is false (the default) :mod:`zipfile` @@ -161,7 +169,7 @@ Added the ability to use :class:`ZipFile` as a context manager. .. versionchanged:: 3.3 - Added support for :mod:`bzip2` compression. + Added support for :mod:`bzip2` and :mod:`lzma` compression. .. method:: ZipFile.close() diff -r 7bdac82c16ab Lib/test/support.py --- a/Lib/test/support.py Tue May 01 09:00:59 2012 +0200 +++ b/Lib/test/support.py Tue May 01 11:29:44 2012 +0300 @@ -45,6 +45,11 @@ except ImportError: bz2 = None +try: + import lzma +except ImportError: + lzma = None + __all__ = [ "Error", "TestFailed", "ResourceDenied", "import_module", "verbose", "use_resources", "max_memuse", "record_original_stdout", @@ -62,7 +67,7 @@ "get_attribute", "swap_item", "swap_attr", "requires_IEEE_754", "TestHandler", "Matcher", "can_symlink", "skip_unless_symlink", "import_fresh_module", "requires_zlib", "PIPE_MAX_SIZE", "failfast", - "anticipate_failure", "run_with_tz", "requires_bz2" + "anticipate_failure", "run_with_tz", "requires_bz2", "requires_lzma" ] class Error(Exception): @@ -513,6 +518,8 @@ requires_bz2 = unittest.skipUnless(bz2, 'requires bz2') +requires_lzma = unittest.skipUnless(lzma, 'requires lzma') + is_jython = sys.platform.startswith('java') # Filename used for testing diff -r 7bdac82c16ab Lib/test/test_zipfile.py --- a/Lib/test/test_zipfile.py Tue May 01 09:00:59 2012 +0200 +++ b/Lib/test/test_zipfile.py Tue May 01 11:29:44 2012 +0300 @@ -13,7 +13,7 @@ from random import randint, random from unittest import skipUnless -from test.support import TESTFN, run_unittest, findfile, unlink, requires_zlib, requires_bz2 +from test.support import TESTFN, run_unittest, findfile, unlink, requires_zlib, requires_bz2, requires_lzma TESTFN2 = TESTFN + "2" TESTFNDIR = TESTFN + "d" @@ -361,6 +361,55 @@ self.assertEqual(openobj.read(1), b'1') self.assertEqual(openobj.read(1), b'2') + @requires_lzma + def test_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_open_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_open_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_random_open_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_random_open_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_readline_read_lzma(self): + # Issue #7610: calls to readline() interleaved with calls to read(). + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_readline_read_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_readline_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_readline_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_readlines_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_readlines_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_iterlines_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_iterlines_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_low_compression_lzma(self): + """Check for cases where compressed data is larger than original.""" + # Create the ZIP archive + with zipfile.ZipFile(TESTFN2, "w", zipfile.ZIP_LZMA) as zipfp: + zipfp.writestr("strfile", '12') + + # Get an open object for strfile + with zipfile.ZipFile(TESTFN2, "r", zipfile.ZIP_LZMA) as zipfp: + with zipfp.open("strfile") as openobj: + self.assertEqual(openobj.read(1), b'1') + self.assertEqual(openobj.read(1), b'2') + def test_absolute_arcnames(self): with zipfile.ZipFile(TESTFN2, "w", zipfile.ZIP_STORED) as zipfp: zipfp.write(TESTFN, "/absolute") @@ -508,6 +557,13 @@ info = zipfp.getinfo('b.txt') self.assertEqual(info.compress_type, zipfile.ZIP_BZIP2) + @requires_lzma + def test_writestr_compression_lzma(self): + zipfp = zipfile.ZipFile(TESTFN2, "w") + zipfp.writestr("b.txt", "hello world", compress_type=zipfile.ZIP_LZMA) + info = zipfp.getinfo('b.txt') + self.assertEqual(info.compress_type, zipfile.ZIP_LZMA) + def zip_test_writestr_permissions(self, f, compression): # Make sure that writestr creates files with mode 0600, # when it is passed a name rather than a ZipInfo instance. @@ -686,6 +742,11 @@ for f in (TESTFN2, TemporaryFile(), io.BytesIO()): self.zip_test(f, zipfile.ZIP_BZIP2) + @requires_lzma + def test_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_test(f, zipfile.ZIP_LZMA) + def test_absolute_arcnames(self): with zipfile.ZipFile(TESTFN2, "w", zipfile.ZIP_STORED, allowZip64=True) as zipfp: @@ -826,6 +887,16 @@ b'\x00 \x80\x80\x81\x00\x00\x00\x00afilePK' b'\x05\x06\x00\x00\x00\x00\x01\x00\x01\x003\x00\x00\x00[\x00' b'\x00\x00\x00\x00'), + zipfile.ZIP_LZMA: ( + b'PK\x03\x04\x14\x03\x00\x00\x0e\x00nu\x0c=FA' + b'KE\x1b\x00\x00\x00n\x00\x00\x00\x05\x00\x00\x00af' + b'ile\t\x04\x05\x00]\x00\x00\x00\x04\x004\x19I' + b'\xee\x8d\xe9\x17\x89:3`\tq!.8\x00PK' + b'\x01\x02\x14\x03\x14\x03\x00\x00\x0e\x00nu\x0c=FA' + b'KE\x1b\x00\x00\x00n\x00\x00\x00\x05\x00\x00\x00\x00\x00' + b'\x00\x00\x00\x00 \x80\x80\x81\x00\x00\x00\x00afil' + b'ePK\x05\x06\x00\x00\x00\x00\x01\x00\x01\x003\x00\x00' + b'\x00>\x00\x00\x00\x00\x00'), } def test_unicode_filenames(self): @@ -1094,6 +1165,10 @@ def test_testzip_with_bad_crc_bzip2(self): self.check_testzip_with_bad_crc(zipfile.ZIP_BZIP2) + @requires_lzma + def test_testzip_with_bad_crc_lzma(self): + self.check_testzip_with_bad_crc(zipfile.ZIP_LZMA) + def check_read_with_bad_crc(self, compression): """Tests that files with bad CRCs raise a BadZipFile exception when read.""" zipdata = self.zips_with_bad_crc[compression] @@ -1126,6 +1201,10 @@ def test_read_with_bad_crc_bzip2(self): self.check_read_with_bad_crc(zipfile.ZIP_BZIP2) + @requires_lzma + def test_read_with_bad_crc_lzma(self): + self.check_read_with_bad_crc(zipfile.ZIP_LZMA) + def check_read_return_size(self, compression): # Issue #9837: ZipExtFile.read() shouldn't return more bytes # than requested. @@ -1150,6 +1229,10 @@ def test_read_return_size_bzip2(self): self.check_read_return_size(zipfile.ZIP_BZIP2) + @requires_lzma + def test_read_return_size_lzma(self): + self.check_read_return_size(zipfile.ZIP_LZMA) + def test_empty_zipfile(self): # Check that creating a file in 'w' or 'a' mode and closing without # adding any files to the archives creates a valid empty ZIP file @@ -1296,6 +1379,11 @@ for f in (TESTFN2, TemporaryFile(), io.BytesIO()): self.zip_test(f, zipfile.ZIP_BZIP2) + @requires_lzma + def test_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_test(f, zipfile.ZIP_LZMA) + def zip_open_test(self, f, compression): self.make_test_archive(f, compression) @@ -1341,6 +1429,11 @@ for f in (TESTFN2, TemporaryFile(), io.BytesIO()): self.zip_open_test(f, zipfile.ZIP_BZIP2) + @requires_lzma + def test_open_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_open_test(f, zipfile.ZIP_LZMA) + def zip_random_open_test(self, f, compression): self.make_test_archive(f, compression) @@ -1374,6 +1467,11 @@ for f in (TESTFN2, TemporaryFile(), io.BytesIO()): self.zip_random_open_test(f, zipfile.ZIP_BZIP2) + @requires_lzma + def test_random_open_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_random_open_test(f, zipfile.ZIP_LZMA) + @requires_zlib class TestsWithMultipleOpens(unittest.TestCase): @@ -1618,6 +1716,31 @@ for f in (TESTFN2, TemporaryFile(), io.BytesIO()): self.iterlines_test(f, zipfile.ZIP_BZIP2) + @requires_lzma + def test_read_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.read_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_readline_read_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.readline_read_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_readline_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.readline_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_readlines_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.readlines_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_iterlines_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.iterlines_test(f, zipfile.ZIP_LZMA) + def tearDown(self): for sep, fn in self.arcfiles.items(): os.remove(fn) diff -r 7bdac82c16ab Lib/zipfile.py --- a/Lib/zipfile.py Tue May 01 09:00:59 2012 +0200 +++ b/Lib/zipfile.py Tue May 01 11:29:44 2012 +0300 @@ -27,8 +27,13 @@ except ImportError: bz2 = None +try: + import lzma # We may need its compression method +except ImportError: + lzma = None + __all__ = ["BadZipFile", "BadZipfile", "error", - "ZIP_STORED", "ZIP_DEFLATED", "ZIP_BZIP2", + "ZIP_STORED", "ZIP_DEFLATED", "ZIP_BZIP2", "ZIP_LZMA", "is_zipfile", "ZipInfo", "ZipFile", "PyZipFile", "LargeZipFile"] class BadZipFile(Exception): @@ -52,11 +57,13 @@ ZIP_STORED = 0 ZIP_DEFLATED = 8 ZIP_BZIP2 = 12 +ZIP_LZMA = 14 # Other ZIP compression methods not supported DEFAULT_VERSION = 20 ZIP64_VERSION = 45 BZIP2_VERSION = 46 +LZMA_VERSION = 63 # Below are some formats and associated data for reading/writing headers using # the struct module. The names and structures of headers/records are those used @@ -365,6 +372,8 @@ if self.compress_type == ZIP_BZIP2: min_version = max(BZIP2_VERSION, min_version) + elif self.compress_type == ZIP_LZMA: + min_version = max(LZMA_VERSION, min_version) self.extract_version = max(min_version, self.extract_version) self.create_version = max(min_version, self.create_version) @@ -478,6 +487,79 @@ return c +def lzma_props_encode(specs): + assert specs['id'] == lzma.FILTER_LZMA1 + prop = (specs['pb'] * 5 + specs['lp']) * 9 + specs['lc'] + return struct.pack(' Message-ID: <1335861628.2567.17.camel@raxxla> Serhiy Storchaka added the comment: Note that the supporting of bzip2 increases the time of testing test_zipfile in 1.5x, and lzma -- 2x (total 3x). May be not all tests are needed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 10:52:03 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 01 May 2012 08:52:03 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1335805326.99.0.207445523375.issue14532@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > However, this generally is not a security risk. You should explain what you already said: it is not a risk because the length of a HMAC is fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 11:58:25 2012 From: report at bugs.python.org (Mark Shannon) Date: Tue, 01 May 2012 09:58:25 +0000 Subject: [issue14699] Calling a classmethod_descriptor directly raises a TypeError for wrong number of parameters. In-Reply-To: <1335780682.19.0.434044540817.issue14699@psf.upfronthosting.co.za> Message-ID: <1335866305.87.0.0856158848018.issue14699@psf.upfronthosting.co.za> Mark Shannon added the comment: New patch in response to review. ---------- Added file: http://bugs.python.org/file25431/classmethoddescr_call.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 13:03:35 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 01 May 2012 11:03:35 +0000 Subject: [issue14694] Option to show leading zeros for bin/hex/oct In-Reply-To: <1335715935.12.0.0678651117983.issue14694@psf.upfronthosting.co.za> Message-ID: <1335870215.2.0.406858947148.issue14694@psf.upfronthosting.co.za> Mark Dickinson added the comment: I'm rejecting this: the functionality is already there in str.format, and there's little to be gained by adding another way to do it. ---------- nosy: +eric.smith resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 13:09:06 2012 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 01 May 2012 11:09:06 +0000 Subject: [issue14694] Option to show leading zeros for bin/hex/oct In-Reply-To: <1335715935.12.0.0678651117983.issue14694@psf.upfronthosting.co.za> Message-ID: <1335870546.24.0.445419739616.issue14694@psf.upfronthosting.co.za> Eric V. Smith added the comment: I agree with Mark. This can also be done slightly more efficiently with plain format(): >>> format(324, "016b") '0000000101000100' >>> format(324, "016o") '0000000000000504' >>> format(324, "016x") '0000000000000144' And with either format() or str.format(), you can add the appropriate prefix: >>> format(324, "#016b") '0b00000101000100' >>> format(324, "#016o") '0o00000000000504' >>> format(324, "#016x") '0x00000000000144' I don't see ever adding all of the possible options to bin(), etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 13:23:32 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Tue, 01 May 2012 11:23:32 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za> Message-ID: <1335871412.52.0.659839765605.issue14082@psf.upfronthosting.co.za> Hynek Schlawack added the comment: I have answered to the (two weeks old :-/) review. There are three open questions in there we'll have to figure out before I fix the patch: - should copyxattr() remove xattrs in dst that aren't present in src? Make it an option like `remove_missing_xattr`? - use "None" for `namespaces` in copyxattrs() to indicate we want to copy all of them? - add a ignore_errors option? ISTM, that "all namespaces" don't make much sense without ignore_errors as there seem to be some internal xattr etc. Suggestion: copyxattrs() has ignore_errors as default and returns a list of xattr it couldn't copy as (xattr, exception) tuples? Or an "on error" handler like in rmtree? I'd prefer the first one as ISTM that failures happen more often than not. ---------- assignee: -> hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 13:41:06 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Tue, 01 May 2012 11:41:06 +0000 Subject: [issue14662] shutil.move doesn't handle ENOTSUP raised by chflags on OS X In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335872466.67.0.371507445966.issue14662@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- assignee: -> hynek title: shutil.move broken in 2.7.3 on OSX (chflags fails) -> shutil.move doesn't handle ENOTSUP raised by chflags on OS X _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 13:57:46 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 01 May 2012 11:57:46 +0000 Subject: [issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions In-Reply-To: <1280333027.17.0.112361474517.issue9400@psf.upfronthosting.co.za> Message-ID: <1335873466.9.0.181110538985.issue9400@psf.upfronthosting.co.za> Richard Oudkerk added the comment: There are plenty of other "bad" exception classes apart from CalledProcessError, including TimeoutExpired in the same file. In fact I suspect this is true of the majority of the exception classes in the stdlib which override __init__. So I am not sure how much good it would do to fix just one example. Python 3.x's Pool wraps bad exception instances in a MaybeEncodingError class which at least lets you see a stringification of the original exception. I am not sure whether you would want to see a backport of this. Even though 2.7 is in bug fix mode, I think a backport would still be appropriate since it stops a pickling error from killing a worker process, causing a hang. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 13:58:33 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 01 May 2012 11:58:33 +0000 Subject: [issue14669] test_multiprocessing failure on OS X Tiger In-Reply-To: <1335370611.47.0.977907847024.issue14669@psf.upfronthosting.co.za> Message-ID: <1335873513.26.0.654509599063.issue14669@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: The buildbot seems happy, let's close! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 14:22:42 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 01 May 2012 12:22:42 +0000 Subject: [issue13585] Add contextlib.ExitStack In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za> Message-ID: <1335874962.83.0.824479454842.issue13585@psf.upfronthosting.co.za> Nick Coghlan added the comment: Latest draft of API is here: http://contextlib2_dev.readthedocs.org/en/latest/index.html#contextlib2.ExitStack An updated version of the "I forgot I could use multiple context managers in a with statement" example: with ExitStack() as stack: src = open(source) stack.callback(src.close) dest = open(destination, 'w') stack.callback(dest.close) copy(src, dest) The example of opening a collection of files remains unchanged (aside from s/ContextStack/ExitStack/). Also see: http://contextlib2_dev.readthedocs.org/en/latest/index.html#replacing-any-use-of-try-finally-and-flag-variables ---------- assignee: rhettinger -> ncoghlan resolution: later -> title: Add contextlib.CallbackStack -> Add contextlib.ExitStack _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 14:41:50 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 May 2012 12:41:50 +0000 Subject: [issue6759] zipfile.ZipExtFile.read() is missing universal newline support In-Reply-To: <1335711858.3414.9.camel@localhost.localdomain> Message-ID: <1335876259.2567.38.camel@raxxla> Serhiy Storchaka added the comment: I know how to remove universal newline support, I know how after this correct these functions (with issue14371 they partially corrected), but I don't know how to deprecate universal newline support. What should be done? Can you initiate a discussion in Python-Ideas or Python-Dev? Now only zipfile trying to implement this PEP (and failed), io ignores 'U' mode, gzip checks and raises. With regard to this issue, I note that there are tests that check that read() returns unmodified data (UniversalNewlineTests.read_test in Lib/test/test_zipfile.py). It looks weird, but apparently, this behavior is expected and deliberate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 15:56:16 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 May 2012 13:56:16 +0000 Subject: [issue14699] Calling a classmethod_descriptor directly raises a TypeError for wrong number of parameters. In-Reply-To: <1335780682.19.0.434044540817.issue14699@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset eab5120cc208 by Benjamin Peterson in branch '3.2': fix calling the classmethod descriptor directly (closes #14699) http://hg.python.org/cpython/rev/eab5120cc208 New changeset e1a200dfd5db by Benjamin Peterson in branch 'default': merge 3.2 (#14699) http://hg.python.org/cpython/rev/e1a200dfd5db New changeset 6484f5a51285 by Benjamin Peterson in branch '2.7': fix calling the classmethod descriptor directly (closes #14699) http://hg.python.org/cpython/rev/6484f5a51285 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 16:10:24 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 01 May 2012 14:10:24 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335881424.38.0.391777867159.issue13959@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Windows is currently failing test_imp: http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/214/steps/test/logs/stdio ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 16:32:40 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 01 May 2012 14:32:40 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335882760.14.0.33394110571.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: That test is going to stay intermittent until issue #14657 gets resolved else the exact reason for the failure is going to be hard to debug remotely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 17:40:56 2012 From: report at bugs.python.org (Jon Oberheide) Date: Tue, 01 May 2012 15:40:56 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1335886856.1.0.808474976986.issue14532@psf.upfronthosting.co.za> Jon Oberheide added the comment: > You should explain what you already said: it is not a risk because the > length of a HMAC is fixed. Well, that's not entirely accurate. Exposing the length of the HMAC can expose what underlying hash is being used (eg. HMAC-SHA1 has different length than HMAC-MD5). It's generally not considered a risk since exposing the algorithm being used shouldn't impact your security (unless you're doing it very wrong). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 19:41:09 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 01 May 2012 17:41:09 +0000 Subject: [issue1303434] Please include pdb with windows distribution Message-ID: <1335894069.71.0.258576638814.issue1303434@psf.upfronthosting.co.za> Martin v. L?wis added the comment: All active branches use this now. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 20:02:06 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 01 May 2012 18:02:06 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: <1335895326.79.0.122202961464.issue13183@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The test fails on Windows. Whereas on Unix, the two step commands produce this output: -> print('1') (Pdb) step 1 --Return-- > /net/pao/export/home/staff/loewis/work/33/bar.py(2)bar()->None -> print('1') (Pdb) step --Return-- > /net/pao/export/home/staff/loewis/work/33/main.py(5)foo()->None -> bar() (Pdb) quit on Windows, they produce this output: -> print('1') (Pdb) step --Call-- > c:\users\martin\33\python\lib\encodings\cp850.py(18)encode() -> def encode(self, input, final=False): (Pdb) step > c:\users\martin\33\python\lib\encodings\cp850.py(19)encode() -> return codecs.charmap_encode(input,self.errors,encoding_map)[0] (Pdb) quit I.e. the stepping enters the print, and breaks in the codec. Reopening the issue. ---------- nosy: +loewis status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 20:45:37 2012 From: report at bugs.python.org (Sandro Tosi) Date: Tue, 01 May 2012 18:45:37 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1335897937.43.0.432369592211.issue14468@psf.upfronthosting.co.za> Sandro Tosi added the comment: +1 It is important to note that if you have a 'cpython' as a clone (which pulls and pushed to hg.python.org) and from it you clone '2.7' and '3.2' (as I think it's the most common setup) you first have to pull from cpython and then on the other 2. Anyhow, is anyone up for preparing a patch? else I'll happily work on it in the coming days. ---------- nosy: +sandro.tosi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 20:47:11 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 01 May 2012 18:47:11 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: <1335898031.06.0.818297164559.issue13183@psf.upfronthosting.co.za> Xavier de Gaye added the comment: My fault :( The call to print is useless for the test, so I suggest to replace it with a plain 'pass' statement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 20:51:20 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 01 May 2012 18:51:20 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1335898280.44.0.459706415952.issue14468@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- assignee: -> sandro.tosi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 20:56:30 2012 From: report at bugs.python.org (David M. Rogers) Date: Tue, 01 May 2012 18:56:30 +0000 Subject: [issue14704] NameError Issue in Multiprocessing Message-ID: <1335898590.74.0.306368822304.issue14704@psf.upfronthosting.co.za> New submission from David M. Rogers : Python Devs, There is an issue relating to variable lookup using exec from within multiprocessing's fork()-ed process. I'm attempting to use the forked process as a generic remote python shell, but exec is unable to reach variables from within functions. This issue makes it impossible to define a function which uses un-passed variables defined in the remote process. The simplest way to reproduce the error is: --- err.py --- from multiprocessing import Process, Pipe def run_remote(con, name): my_name = name for i in range(2): code = con.recv() exec code me, he = Pipe() p = Process(target=run_remote, args=(he, "Sono Inglese de Gerrards Cross.")) p.start() me.send("print my_name") # works me.send(""" def show_name(): print my_name show_name() # doesn't work """) --- end err.py --- This program prints: $ python2.6 err.py Sono Inglese de Gerrards Cross. Process Process-1: Traceback (most recent call last): File "/sw/lib/python2.6/multiprocessing/process.py", line 232, in _bootstrap self.run() File "/sw/lib/python2.6/multiprocessing/process.py", line 88, in run self._target(*self._args, **self._kwargs) File "err.py", line 7, in run_remote exec code File "", line 4, in File "", line 3, in show_name NameError: global name 'my_name' is not defined I'm using Mac OSX (10.6.8) and Python 2.6.5 (r265:79063, Sep 23 2010, 14:05:02) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin The issue (with the same traceback) also occurs for: Python 2.7 (r27:82500, Sep 29 2010, 15:34:46) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Using exactly the same set of exec calls locally results in the correct behavior. --- noerr.py --- my_name = "Sono Inglese de Gerrards Cross." exec "print my_name" exec """ def show_name(): print my_name show_name() """ --- end noerr.py --- ---------- components: None messages: 159764 nosy: frobnitzem priority: normal severity: normal status: open title: NameError Issue in Multiprocessing versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 21:06:30 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 01 May 2012 19:06:30 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: <1335899190.55.0.827327615328.issue13183@psf.upfronthosting.co.za> Martin v. L?wis added the comment: That indeed makes the test pass. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 21:16:36 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 01 May 2012 19:16:36 +0000 Subject: [issue14704] NameError Issue in Multiprocessing In-Reply-To: <1335898590.74.0.306368822304.issue14704@psf.upfronthosting.co.za> Message-ID: <1335899796.14.0.0190359542865.issue14704@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks for the report. This is expected behaviour. It isn't actually anything to do with multiprocessing; it's to do with invoking exec from within a function scope. You can see the same effect with code like this: code = """\ def show_name(): print my_name show_name() """ def run(): my_name = "me" exec code run() See http://docs.python.org/reference/executionmodel.html#interaction-with-dynamic-features for more explanation. ---------- nosy: +mark.dickinson resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 1 22:27:03 2012 From: report at bugs.python.org (James Hutchison) Date: Tue, 01 May 2012 20:27:03 +0000 Subject: [issue10376] ZipFile unzip is unbuffered In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za> Message-ID: <1335904023.66.0.586151516086.issue10376@psf.upfronthosting.co.za> James Hutchison added the comment: See attached, which will open a zipfile that contains one file and reads it a bunch of times using unbuffered and buffered idioms. This was tested on windows using python 3.2 You're in charge of coming up with a file to test it on. Sorry. Example output: Enter filename: test.zip Timing unbuffered read, 5 bytes at a time. 10 loops took 6.671999931335449 Timing buffered read, 5 bytes at a time (4000 byte buffer). 10 loops took 0.7350001335144043 ---------- Added file: http://bugs.python.org/file25432/zipfiletest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 01:19:11 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 May 2012 23:19:11 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 4b98ce6ef95e by Victor Stinner in branch 'default': Issue #14687: Optimize str%args http://hg.python.org/cpython/rev/4b98ce6ef95e New changeset a966f9311ebb by Victor Stinner in branch 'default': Issue #14687: Cleanup PyUnicode_Format() http://hg.python.org/cpython/rev/a966f9311ebb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 02:01:19 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 May 2012 00:01:19 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 3b2aa777b725 by Senthil Kumaran in branch '2.7': fix windows test failure - issue13183 http://hg.python.org/cpython/rev/3b2aa777b725 New changeset d17ecee3f752 by Senthil Kumaran in branch '3.2': fix windows test failure - issue13183 http://hg.python.org/cpython/rev/d17ecee3f752 New changeset 0269c592c8b1 by Senthil Kumaran in branch 'default': fix closes issue13183 - windows test failure http://hg.python.org/cpython/rev/0269c592c8b1 ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 03:55:47 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 02 May 2012 01:55:47 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> Message-ID: <1335923747.34.0.831492226954.issue14632@psf.upfronthosting.co.za> Brian Curtin added the comment: The test for this issue seems to fail about half of the time on Windows. ====================================================================== ERROR: test_race (test.test_logging.HandlerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\python-dev\cpython-main\lib\test\test_logging.py", line 605, in test_race h = logging.handlers.WatchedFileHandler(fn, delay=delay) File "c:\python-dev\cpython-main\lib\logging\handlers.py", line 421, in __init__ logging.FileHandler.__init__(self, filename, mode, encoding, delay) File "c:\python-dev\cpython-main\lib\logging\__init__.py", line 965, in __init__ StreamHandler.__init__(self, self._open()) File "c:\python-dev\cpython-main\lib\logging\__init__.py", line 987, in _open return open(self.baseFilename, self.mode, encoding=self.encoding) PermissionError: [Errno 13] Permission denied: 'c:\\users\\brian\\appdata\\local\\temp\\test_logging-3-lxjo5t.log' I also get this failure when running in the VS2010 branch: ====================================================================== ERROR: test_race (test.test_logging.HandlerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\python-dev\porting\cpython\lib\test\test_logging.py", line 600, in cleanup os.unlink(fn) PermissionError: [Error 32] The process cannot access the file because it is being used by another process: 'c:\\users\\brian\\appdata\\local\\temp\\test_logging3-6ujeil.log' ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 04:03:38 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 02 May 2012 02:03:38 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: <1335924218.05.0.276252062839.issue13183@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Fixed again with replacing print with pass. But it is strange behavior that "stepping through" enters print in Windows and does not so in Unix. What's the difference in windows that could cause this? Not sure if this was expected behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 05:00:44 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 02 May 2012 03:00:44 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1335927644.08.0.784929753562.issue14626@psf.upfronthosting.co.za> Larry Hastings added the comment: > I personally think that offering mere wrappers around syscalls doesn't > make much sense: Python is a very-high level language, and so should > its library be. I very much agree. I suggest anyone who thinks the os module is a thin veneer over syscalls needs to examine the Win32 implementation of os.stat. > - *at() syscalls are not portable: if it's not supported, what's > remove(path='toto', dir_fd=fd) supposed to do? Throw an exception? NotImplementedError. > - it's not clear how one's supposed to check that the functions are > available: right now, one can do [a hasattr check] > How would that work with dir_fd argument? try/except. If someone (maybe even me) championed PEP 362 (Function Signature Object, introspection on functions) then we could LBYL, but that's only a theory right now. > stat(path, *, followlinks=True, dirfd=None) > is backwards, it should be > stat(dirfd, path, *, followlinks=True) > since, `path` is relative to `dirfd`. You could hypothetically rearrange all the arguments at the call site by using 100% keyword arguments: stat(dir_fd=whatever, path=thingy, follow_symlinks=True) I admit it's unlikely anyone will bother. > Actually, the proper way to do this would be to use overloading, but > Python doesn't support it (and even if it did, I think overloading > would probably be a bad idea anyway). Speaking *purely hypothetically*, we could actually overload it. It'd be at runtime, as what in Python is not. Since stat is implemented in C it would look like: if (-1 == PyArg_ParseTupleAndKeyword(arguments-with-dir_fd)) { PyErr_Clear(); if (-1 == PyArg_ParseTupleAndKeyword(arguments-without-dir_fd)) { /* etc. */ However, Python doesn't have overloading because we shouldn't do it. I'm against overloading here, for the same reason that I'm against argument polymorphism (fold faccess into access by allowing the first argument to be either an int or a string). This sort of polymorphism leads to lack of clarity and awkward problems. > I'll probably have to think some time to understand what the hell is > the last dir_fd argument. Renaming, removing a file is simple and > direct, so should the API be. I counter with TOOWWTDI. There are currently four chmod functions in os: chmod, fchmod, fchmodat, and lchmod. If you want to change the mode of a file, which do you use? You may also face the problem that you don't want chmod to follow symbolic links, yet you've never heard of lchmod. I feel the sad truth of the situation is, it is desirable that Python support all this functionality, but there is no simple and obviously-right way to do so. So which alternative is less undesirable: a combinatoric explosion of functions, or a combinatoric explosion of arguments to existing functions? I suggest the latter is less undesirable because it is marginally clearer: at least you always know which function to call, and the documentation on how to use it in its multiple forms will be all in one place. (Though this would not help the hapless programmer who suspected maybe there *was* a second function somewhere, searching forever for a function that doesn't actually exist.) Also, I suggest that the programmer reading the documentation for os would see the same parameters (dir_fd, follow_symlinks) as part of many different functions and would quickly learn their semantics. > - finally, although useful, the *at() family is a really poor and > confusing API, which will likely be used by less than 0.1% of the > overall Python users. Complicating the whole posix module API just > to shave off a few functions is IMHO a bad idea. I understand your critique. In defense of the proposal, I will say that when Guido asked me to connect with the storchaka and try to shepherd the process, he specifically cited the *at() functions as examples of new functions that could be obviated by folding the functionality into the existing APIs. Not that I claim this gives me carte blanche to check an implementation in. Simply that I believe Guido liked the idea in the abstract. It could be that he wouldn't like the result, or that my proposal (which purposely carried out the idea to its logical extreme) goes too far. In the absence of a BDFL ruling on the proposal, I think I should produce a patch implementing the full proposal, then bring it up in c.l.p-d and get a community vote. How's that sound? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 05:58:48 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 02 May 2012 03:58:48 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335931128.52.0.972530507713.issue13210@psf.upfronthosting.co.za> Brian Curtin added the comment: As of a40f47cc7691, Richard's idea is now the implementation, which seems to work well and has simplified the changes quite well. Attached is code_changes.diff which shows all of the necessary code changes as of now. The test_import failure you were originally seeing has gone away (it was on default as well, I guess it has been fixed). test_email fails on the default branch as well so nothing new there. ---------- Added file: http://bugs.python.org/file25433/code_changes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 07:39:00 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 02 May 2012 05:39:00 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1335924218.05.0.276252062839.issue13183@psf.upfronthosting.co.za> Message-ID: <4FA0C86B.8030601@v.loewis.de> Martin v. L?wis added the comment: > But it is strange behavior that "stepping through" enters print in > Windows and does not so in Unix. What's the difference in windows > that could cause this? Not sure if this was expected behavior. On Unix, the codec most likely is UTF-8, which is directly written in C, i.e. doesn't support Python single-stepping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 07:41:30 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 May 2012 05:41:30 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 6c9ce7e34511 by Martin v. L?wis in branch 'default': Issue #13183: Revert 0b53b70a40a0 (reenable test on windows) http://hg.python.org/cpython/rev/6c9ce7e34511 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 08:25:37 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 02 May 2012 06:25:37 +0000 Subject: [issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za> Message-ID: <1335939937.97.0.232425382295.issue9377@psf.upfronthosting.co.za> Martin v. L?wis added the comment: For Windows versions that support it, we could use GetNameInfoW, available on XPSP2+, W2k3+ and Vista+. The questions then are: what to do about gethostbyaddr, and what to do about the general case? Since the problem appears to be specific to Windows, it might be appropriate to find a solution to just the Windows case, and ignore the general issue. For gethostbyaddr, decoding would then use CP_ACP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 08:31:09 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 02 May 2012 06:31:09 +0000 Subject: [issue9123] insecure os.urandom on VMS In-Reply-To: <1277869715.19.0.305414138773.issue9123@psf.upfronthosting.co.za> Message-ID: <1335940269.0.0.134833955066.issue9123@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm closing this as "won't fix". Unless somebody is able to report that they actually tested the proposed change successfully, there is no point in adding it. Most likely, Python won't even build on VMS, in which case this is not a security issue at all. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 08:32:46 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 02 May 2012 06:32:46 +0000 Subject: [issue14530] distutils's build_wininst command fails to correctly interpret the data_files argument In-Reply-To: <1333907900.33.0.191070589139.issue14530@psf.upfronthosting.co.za> Message-ID: <1335940366.78.0.161731750324.issue14530@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Mario: would you like to work on a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 08:33:12 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 02 May 2012 06:33:12 +0000 Subject: [issue14529] distutils's build_msi command ignores the data_files argument In-Reply-To: <1333907359.21.0.0116056941941.issue14529@psf.upfronthosting.co.za> Message-ID: <1335940392.2.0.0193259020713.issue14529@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Mario: would you like to work on a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 08:56:38 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 02 May 2012 06:56:38 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <1335217931.89.0.157136074708.issue14656@psf.upfronthosting.co.za> Message-ID: <1335941798.1.0.392969189464.issue14656@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Sorry, I missed the patch. I still fail to see the problem that this solves: what compiler produces "control reaches end of non-void function without return" for the current code? ISTM that your patch has the potential of *introducing* such a warning on some compilers, since you are removing the return statement (and the compiler may not be smart enough to determine that Py_FatalError does not return). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 11:29:19 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 02 May 2012 09:29:19 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* Message-ID: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> New submission from Larry Hastings : Currently functions that parse their arguments with the PyArg_ParseTuple family which want to take a boolean-ish parameter face two choices: * take an "int", then test whether or not the int is 0, or * take an "object", then call PyObject_IsTrue themselves. The former is foolish; though it works with ints and bools, it doesn't work with any other type (float, str, list, etc) which strictly speaking are valid for boolean fields. And this is common enough that the latter should not be necessary. I propose to add support for a new format character to the PyArg_ParseTuple family: 'b', which specifies 'boolean'. Its implementation would be much the same as that of 'd' except: * the output type would be "int" instead of "double", * it would check for a -1 instead of calling PyErr_Occured, and * it would call PyObject_IsTrue instead of PyFloat_AsDouble. If we cared, I could also add 'B', which would only accept either Py_True or Py_False. But I see no reason why we'd ever want to strictly enforce the type... do you? (I can see MvL's argument now: "We've lived this long without it. YAGNI.") If there's interest I'll knock out a patch. I expect it to be less than ten lines not counting documentation and test. (Less than twenty if folks actually want 'B'.) ---------- assignee: larry components: Interpreter Core messages: 159781 nosy: larry priority: normal severity: normal status: open title: Add 'bool' format character to PyArg_ParseTuple* type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 12:15:24 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 02 May 2012 10:15:24 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335953724.54.0.682186177419.issue13210@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Posted some comments. Also, I see you didn't remove the old SxS functionality, no longer used by VS2010 (see my sxs.patch) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 12:39:45 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 May 2012 10:39:45 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1335955185.14.0.566485631191.issue14705@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, I too have encountered this in the process of working on issue 14626. For this purpose it is appropriate to use a special converter (with 'O&'). I suppose it must be a strict ?onverter; there is no point in specifying followlinks=[1, 2, 3]. If it is somewhere need a nonstrict ones -- use 'O' and then check the how to in this particular case. Would be good to have a special letter for this format, but note that 'b' and 'B' are already used. It is better first to use the ?onverter, and expand the format only when the enough number of uses. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 12:57:25 2012 From: report at bugs.python.org (Adi Roiban) Date: Wed, 02 May 2012 10:57:25 +0000 Subject: [issue14706] Inconsistent os.access os.X_OK on Solaris and AIX when running as root Message-ID: <1335956245.89.0.218192392031.issue14706@psf.upfronthosting.co.za> New submission from Adi Roiban : The return value of os.access(FILE, os.X_OK) is not consistent across operating system when executed as "root" I have tested with Python 2.5 on Linux and Solaris, but there is a bug in python-nose reporting the same behavior with Python 2.6 on Solaris and AIX. http://code.google.com/p/python-nose/issues/detail?id=423 ------- On Solaris: $ ls -al -rw-rw-r-- 1 buildslave other 1079 May 1 16:25 nose_runner.py $ ./bin/python Python 2.5.6 (r256:88840, Nov 1 2011, 12:19:05) [GCC 3.4.3 (csl-sol210-3_4-branch+sol_rpath)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.access('nose_runner.py', os.X_OK) False $ sudo ./bin/python Python 2.5.6 (r256:88840, Nov 1 2011, 12:19:05) [GCC 3.4.3 (csl-sol210-3_4-branch+sol_rpath)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.access('nose_runner.py', os.X_OK) True ------ On Linux: $ ls -al -rw-rw-r-- 1 adi adi 1079 2012-05-02 11:25 nose_runner.py $ ./bin/python Python 2.5.5 (r255:77872, Sep 14 2010, 16:22:46) [GCC 4.4.5] on linux2 >>> import os >>> os.access('nose_runner.py', os.X_OK) False $ sudo ./bin/python Python 2.5.5 (r255:77872, Sep 14 2010, 16:22:46) [GCC 4.4.5] on linux2 >>> import os >>> os.access('nose_runner.py', os.X_OK) False ---------- messages: 159784 nosy: adiroiban priority: normal severity: normal status: open title: Inconsistent os.access os.X_OK on Solaris and AIX when running as root type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 13:23:20 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 02 May 2012 11:23:20 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1335957800.52.0.151027955601.issue14705@psf.upfronthosting.co.za> Larry Hastings added the comment: > For this purpose it is appropriate to use a special converter > (with 'O&'). The converter works--but, then, a similar converter would also work for double, and float, and long long and many others. If long long is special enough to merit explicit support in PyArg_ParseTuple, then bool definitely is, as I strongly suspect bool is used much more frequently. > I suppose it must be a strict ?onverter; there is no point > in specifying followlinks=[1, 2, 3]. I don't see a need for that either, but--where would you draw the line? What is the principle that says "ints are okay, floats are... okay, lists are not"? Python has a long-established concept of the "truthiness" of an expression. I *strongly* suggest we stick with that unless we have a *very* good reason why not. > note that 'b' and 'B' are already used. I'm a moron! I must have looked right at it and it didn't register. 't' (truth) and 'f' (false) are also taken. As is 'c' (conditional). The only thing I can come up with that's remotely related and isn't already taken is 'p' for predicate. > It is better first to use the ?onverter, and expand the format > only when the enough number of uses. I suspect there are already loads of places in the standard library that should be using this rather than abusing 'i'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 13:35:18 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 May 2012 11:35:18 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <1335941798.1.0.392969189464.issue14656@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I think you misuse __builtin_unreachable(): the code *is* reachable, it is just very unlikely. I really prefer to return something looking valid and continue the execution of the program, instead of calling the evil Py_FatalError() in release mode which stops immediatly the program in an insane manner. For example, -1 is a valid result for findchar(), so the program execution will continue, even if the kind is invalid. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 13:36:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 02 May 2012 11:36:11 +0000 Subject: [issue14706] Inconsistent os.access os.X_OK on Solaris and AIX when running as root In-Reply-To: <1335956245.89.0.218192392031.issue14706@psf.upfronthosting.co.za> Message-ID: <1335958571.24.0.00029287644392.issue14706@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is not a Python bug. os.access() is just a wrapper around the POSIX access() function: http://pubs.opengroup.org/onlinepubs/9699919799/functions/faccessat.html ?If any access permissions are checked, each shall be checked individually, as described in XBD File Access Permissions, except that where that description refers to execute permission for a process with appropriate privileges, an implementation may indicate success for X_OK even if execute permission is not granted to any user.? So this seems to be a well-known portability problem accross Unix implementations. If you want to test the executable bits, just use os.stat(). ---------- nosy: +pitrou resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 13:37:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 02 May 2012 11:37:46 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <1335217931.89.0.157136074708.issue14656@psf.upfronthosting.co.za> Message-ID: <1335958666.76.0.0147082110047.issue14656@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I really prefer to return something looking valid and continue the > execution of the program How would that be better? Should Python become more like PHP? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 13:50:06 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 May 2012 11:50:06 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <1335217931.89.0.157136074708.issue14656@psf.upfronthosting.co.za> Message-ID: <1335959406.76.0.4093392152.issue14656@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I read again the patch. There are two different cases: * The code is really unreachable. Ex: the loop of lookdict() does never stop, return is used in the loop. Py_UNREACHABLE can be used in this case *to avoid a compiler warning*. __builtin_unreachable() helps if you have GCC, but if you don't have GCC, using return with a dummy value would be better than a Py_FatalError(). I don't think that calling Py_FatalError() does make the warning quiet. * The code is reachable, but if it is reached, it's a bug. Ex: switch/case on the Unicode kinde of a string. I like the current solution: assert(0) + return a almost valid value, but Antoine and Benjamin don't like the "almost valid value" (and so prefer a fatal error?). We may issue a warning instead of a fatal error (e.g. write a message into stderr with fprintf ?) in release mode. -- Using return, it gives something like: +#ifdef NDEBUG +#ifdef __GNUC__ +#define Py_UNREACHABLE(value) __builtin_unreachable() +#else +#define Py_UNREACHABLE(value) return (value); +#endif +#else +#define Py_UNREACHABLE(value) do { assert(0); return (value); } while (0) +#endif It cannot be used if the function has no result value (void), but quite all Python functions have a result. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 13:53:38 2012 From: report at bugs.python.org (Adi Roiban) Date: Wed, 02 May 2012 11:53:38 +0000 Subject: [issue14706] Inconsistent os.access os.X_OK on Solaris and AIX when running as root In-Reply-To: <1335956245.89.0.218192392031.issue14706@psf.upfronthosting.co.za> Message-ID: <1335959618.89.0.393190378281.issue14706@psf.upfronthosting.co.za> Adi Roiban added the comment: Many thanks for your comment! Cheers, Adi ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 14:00:52 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 02 May 2012 12:00:52 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1335871412.52.0.659839765605.issue14082@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: I really like the idea of adding extended attributes copy to shutil.cop2(). However, I'm not convinced that exposing the raw copyxattr() is necessary (I can't really come up with a use case for this). So I'd suggest make copyxattr() private, and wait until someone asks for the functionality. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 14:07:40 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Wed, 02 May 2012 12:07:40 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: Message-ID: <4FA12389.9030405@ox.cx> Hynek Schlawack added the comment: > I really like the idea of adding extended attributes copy to shutil.cop2(). > However, I'm not convinced that exposing the raw copyxattr() is > necessary (I can't really come up with a use case for this). > > So I'd suggest make copyxattr() private, and wait until someone asks > for the functionality. I agree. If someone needs it, (s)he will be able to advice on useful semantics re replacement. For copy2() it?s a non-issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 14:41:21 2012 From: report at bugs.python.org (Christophe Benoit) Date: Wed, 02 May 2012 12:41:21 +0000 Subject: [issue14517] Recompilation of sources with Distutils In-Reply-To: <1335052176.77.0.973379319144.issue14517@psf.upfronthosting.co.za> Message-ID: Christophe Benoit added the comment: 2012/4/22 ?ric Araujo > > ?ric Araujo added the comment: > > Is it #5372? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > Yes, I think so. The problem is : For modules with a lot of .c, recompiling everything can take a very long time... In fact, it becomes very cumbersome for me and my co-workers... Is there a way to make the previous check on timestamps optional? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 15:26:31 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 02 May 2012 13:26:31 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <1335217931.89.0.157136074708.issue14656@psf.upfronthosting.co.za> Message-ID: <1335965191.17.0.734282170221.issue14656@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I like the current > solution: assert(0) + return a almost valid value, but Antoine and > Benjamin don't like the "almost valid value" (and so prefer a fatal > error?). We may issue a warning instead of a fatal error (e.g. write a > message into stderr with fprintf ?) in release mode. If there's a bug, either an exception should be raised, or a fatal error. We should discourage warnings on stderr (the PHP approach). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 15:30:34 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 02 May 2012 13:30:34 +0000 Subject: [issue14662] shutil.move doesn't handle ENOTSUP raised by chflags on OS X In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335965434.39.0.341699467474.issue14662@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The test fails here (Linux), since there's no os.chflags: ====================================================================== ERROR: test_copystat_handles_harmless_chflags_errors (test.test_shutil.TestShutil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/antoine/cpython/default/Lib/test/test_shutil.py", line 302, in test_copystat_handles_harmless_chflags_errors old_chflags = os.chflags AttributeError: 'module' object has no attribute 'chflags' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 17:27:52 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Wed, 02 May 2012 15:27:52 +0000 Subject: [issue14662] shutil.move doesn't handle ENOTSUP raised by chflags on OS X In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335972472.16.0.39015080742.issue14662@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Fixed for 2.7 ---------- Added file: http://bugs.python.org/file25434/expand-chflags-catch-2.7-v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 17:30:27 2012 From: report at bugs.python.org (Mike Gilbert) Date: Wed, 02 May 2012 15:30:27 +0000 Subject: [issue13032] h2py.py can fail with UnicodeDecodeError In-Reply-To: <1316767061.34.0.367682305149.issue13032@psf.upfronthosting.co.za> Message-ID: <1335972627.26.0.121603625734.issue13032@psf.upfronthosting.co.za> Changes by Mike Gilbert : ---------- nosy: +floppymaster _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 17:33:48 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 02 May 2012 15:33:48 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <1335217931.89.0.157136074708.issue14656@psf.upfronthosting.co.za> Message-ID: <1335972828.81.0.823193263592.issue14656@psf.upfronthosting.co.za> Georg Brandl added the comment: > If there's a bug, either an exception should be raised, or a fatal error. > We should discourage warnings on stderr (the PHP approach). Agreed. That said, I'm with Martin in that don't see how the patch in this issue helps. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 17:36:55 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Wed, 02 May 2012 15:36:55 +0000 Subject: [issue14662] shutil.move doesn't handle ENOTSUP raised by chflags on OS X In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335973015.54.0.561919006643.issue14662@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Fixed for 3.2. ---------- Added file: http://bugs.python.org/file25435/expand-chflags-catch-3.2-v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 17:39:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 May 2012 15:39:18 +0000 Subject: [issue9244] multiprocessing.pool: Worker crashes if result can't be encoded In-Reply-To: <1279021915.02.0.743108448879.issue9244@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 26bbff4562a7 by Richard Oudkerk in branch '2.7': Issue #9400: Partial backport of fix for #9244 http://hg.python.org/cpython/rev/26bbff4562a7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 17:39:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 May 2012 15:39:18 +0000 Subject: [issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions In-Reply-To: <1280333027.17.0.112361474517.issue9400@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 26bbff4562a7 by Richard Oudkerk in branch '2.7': Issue #9400: Partial backport of fix for #9244 http://hg.python.org/cpython/rev/26bbff4562a7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 17:39:51 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 02 May 2012 15:39:51 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <1335217931.89.0.157136074708.issue14656@psf.upfronthosting.co.za> Message-ID: <1335973191.26.0.456676831198.issue14656@psf.upfronthosting.co.za> Martin v. L?wis added the comment: > Py_UNREACHABLE can be used in this case *to avoid a compiler warning*. What is the specific warning that you want to avoid, and what specific compiler version produces it currently on what specific code? It's not "control reaches end of non-void function without return", is it? (since if the compiler correctly determines that the code is unreachable, it shouldn't complain that control reaches the end of the function, as it doesn't reach the end of the function). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 17:43:31 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 02 May 2012 15:43:31 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <1335217931.89.0.157136074708.issue14656@psf.upfronthosting.co.za> Message-ID: <1335973411.85.0.52692160216.issue14656@psf.upfronthosting.co.za> Benjamin Peterson added the comment: It does not avoid any warning because we have the "assert(0); return X" pattern. I was just attempting to provide a standard way of marking unreachable code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 17:47:02 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Wed, 02 May 2012 15:47:02 +0000 Subject: [issue14662] shutil.move doesn't handle ENOTSUP raised by chflags on OS X In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335973622.39.0.12899260516.issue14662@psf.upfronthosting.co.za> Hynek Schlawack added the comment: And finally tip. ---------- Added file: http://bugs.python.org/file25436/expand-chflags-catch-tip-v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 17:49:50 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 02 May 2012 15:49:50 +0000 Subject: [issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions In-Reply-To: <1280333027.17.0.112361474517.issue9400@psf.upfronthosting.co.za> Message-ID: <1335973790.95.0.00512713266932.issue9400@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I have backported the fix for issue #9244 to 2.7. This should fix the hang and produce a traceback containing a representation of the original error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 17:54:05 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 02 May 2012 15:54:05 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <1335217931.89.0.157136074708.issue14656@psf.upfronthosting.co.za> Message-ID: <1335974045.28.0.671054253737.issue14656@psf.upfronthosting.co.za> Martin v. L?wis added the comment: > I was just attempting to provide a standard way of marking unreachable code. I'm -1 for the proposed patch (and probably -0 on the general idea). I think the patch has the potential *introducing* new warnings, as compilers might warn that a return is lacking in these functions. I'm -0 on the general idea, as I think the status quo is just fine. As for Victor's second use case (run-time checking that supposedly-unreachable code is indeed not reached, in release mode), I'm -0 also: we check that in debug mode; this looks sufficient to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 18:04:41 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 02 May 2012 16:04:41 +0000 Subject: [issue14366] Supporting lzma compression in zip files In-Reply-To: <1332112236.1.0.964135054036.issue14366@psf.upfronthosting.co.za> Message-ID: <1335974681.89.0.617733717106.issue14366@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm not sure where the test run time actually comes from. It's certainly desirable to reduce the test run time, as long as all test purposes are preserved. It's not necessary to do redundant tests, e.g. if some test isn't about compression, there is no point in running it with all compressors (again, I'm not sure whether this actually happens). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 18:15:16 2012 From: report at bugs.python.org (Daniel543) Date: Wed, 02 May 2012 16:15:16 +0000 Subject: [issue14707] extend() puzzled me. Message-ID: <1335975316.5.0.356302155228.issue14707@psf.upfronthosting.co.za> New submission from Daniel543 : Python 2.7.3 (default, Apr 20 2012, 22:44:07) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = ['1'] >>> b = [] >>> c = a >>> b.append(a) >>> a ['1'] >>> b [['1']] >>> c ['1'] >>> a = ['2'] >>> c.extend(a) >>> b [['1', '2']] >>> c ['1', '2'] >>> a ['2'] >>> Is this wrong? I think the "b" should not change. ---------- components: None messages: 159807 nosy: Daniel543 priority: normal severity: normal status: open title: extend() puzzled me. type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 18:21:59 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 02 May 2012 16:21:59 +0000 Subject: [issue14707] extend() puzzled me. In-Reply-To: <1335975316.5.0.356302155228.issue14707@psf.upfronthosting.co.za> Message-ID: <1335975719.69.0.07355640762.issue14707@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is correct behavior, because: >>> b[0] is c True (read up on the meaning of the "is" operator, if this is not a convincing proof to you). ---------- nosy: +loewis resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 18:25:36 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 02 May 2012 16:25:36 +0000 Subject: [issue14707] extend() puzzled me. In-Reply-To: <1335975316.5.0.356302155228.issue14707@psf.upfronthosting.co.za> Message-ID: <1335975936.61.0.646052668213.issue14707@psf.upfronthosting.co.za> Ezio Melotti added the comment: >>> a = ['1'] >>> b = [] >>> c = a # now c and a refer to the same object >>> b.append(a) # this object is appended to b >>> a ['1'] >>> b [['1']] >>> c ['1'] # a and c refer to the same object you have in b # so all these ['1'] are actually the same object >>> a = ['2'] # now a refers to another object >>> c.extend(a) # and here you are extending the object referred by c # and the same object that you have in b >>> b [['1', '2']] >>> c ['1', '2'] # so this is correct >>> a ['2'] >>> You can use id() to verify the identity of the objects, and read http://python.net/crew/mwh/hacks/objectthink.html for more information. ---------- nosy: +ezio.melotti stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 18:56:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 02 May 2012 16:56:42 +0000 Subject: [issue14366] Supporting lzma compression in zip files In-Reply-To: <1332112236.1.0.964135054036.issue14366@psf.upfronthosting.co.za> Message-ID: <1335977802.45.0.0720314917795.issue14366@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Note that the supporting of bzip2 increases the time of testing > test_zipfile in 1.5x, and lzma -- 2x (total 3x). May be not all tests > are needed? I think it's ok. Some of our tests run quite longer than that; and better to be exhaustive than fast (even though exhaustive *and* fast is better, of course). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 19:09:35 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 02 May 2012 17:09:35 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1335978575.0.0.517218721426.issue13903@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 19:52:17 2012 From: report at bugs.python.org (Chris Rebert) Date: Wed, 02 May 2012 17:52:17 +0000 Subject: [issue9530] integer undefined behaviors In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za> Message-ID: <1335981137.54.0.710657957751.issue9530@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 20:05:34 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 May 2012 18:05:34 +0000 Subject: [issue14698] test_posix failures - getpwduid()/initgroups()/getgroups() In-Reply-To: <1335774640.36.0.246153891142.issue14698@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 45f0272f5296 by Charles-Fran?ois Natali in branch '2.7': Issue #14698: Make test_posix more robust when the current UID doesn't have an http://hg.python.org/cpython/rev/45f0272f5296 New changeset 93424b084d08 by Charles-Fran?ois Natali in branch '3.2': Issue #14698: Make test_posix more robust when the current UID doesn't have an http://hg.python.org/cpython/rev/93424b084d08 New changeset 982c30064bc9 by Charles-Fran?ois Natali in branch 'default': Issue #14698: Make test_posix more robust when the current UID doesn't have an http://hg.python.org/cpython/rev/982c30064bc9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 20:36:34 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 02 May 2012 18:36:34 +0000 Subject: [issue9530] integer undefined behaviors In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za> Message-ID: <1335983794.18.0.340068975481.issue9530@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Alternatively, I can re-run the Python test suite on a Python compiled > using our tool. Let me know if this would be helpful. Definitely helpful if you have the time! Yes, please. Though I do intend to try out the tool for myself at some point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 20:42:05 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 02 May 2012 18:42:05 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: <1335984125.14.0.903949834731.issue13183@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: All 3.2 and 2.7 buildbots are still broken: http://python.org/dev/buildbot/all/builders/x86 OpenIndiana 3.2/builds/1080 """ ====================================================================== FAIL: test_issue13183 (test.test_pdb.PdbTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/test/test_pdb.py", line 662, in test_issue13183 'Fail to step into the caller after a return') AssertionError: 'main.py(5)foo()->None' not found in '-> bar()' : Fail to step into the caller after a return ---------------------------------------------------------------------- Ran 2 tests in 0.558s """ ---------- nosy: +neologix status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 20:46:03 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 02 May 2012 18:46:03 +0000 Subject: [issue13032] h2py.py can fail with UnicodeDecodeError In-Reply-To: <1316767061.34.0.367682305149.issue13032@psf.upfronthosting.co.za> Message-ID: <1335984363.24.0.0271486124013.issue13032@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: UTF-8 is default encoding in Python 3, so statements with UTF-8 characters could be accepted. Any strings are very rare in these statements. On my system, only generated TYPES.py contains 2 strings: # Included from bits/select.h __FD_ZERO_STOS = "stosq" __FD_ZERO_STOS = "stosl" /usr/include/bits/select.h contains: # if __WORDSIZE == 64 # define __FD_ZERO_STOS "stosq" # else # define __FD_ZERO_STOS "stosl" # endif ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 21:29:40 2012 From: report at bugs.python.org (Colin Marc) Date: Wed, 02 May 2012 19:29:40 +0000 Subject: [issue14204] Support for the NPN extension to TLS/SSL In-Reply-To: <1330978861.96.0.148487272162.issue14204@psf.upfronthosting.co.za> Message-ID: <1335986980.15.0.747762379132.issue14204@psf.upfronthosting.co.za> Colin Marc added the comment: Just noticed this is missing from "What's new in Python 3.3": http://docs.python.org/dev/whatsnew/3.3.html. Should I submit a patch for that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 21:30:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 02 May 2012 19:30:27 +0000 Subject: [issue14204] Support for the NPN extension to TLS/SSL In-Reply-To: <1330978861.96.0.148487272162.issue14204@psf.upfronthosting.co.za> Message-ID: <1335987027.71.0.536757641882.issue14204@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Just noticed this is missing from "What's new in Python 3.3": http://docs.python.org/dev/whatsnew/3.3.html. > Should I submit a patch for that? No need for that, the What's New document usually gets filled later in the release cycle. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 21:31:37 2012 From: report at bugs.python.org (Colin Marc) Date: Wed, 02 May 2012 19:31:37 +0000 Subject: [issue14204] Support for the NPN extension to TLS/SSL In-Reply-To: <1330978861.96.0.148487272162.issue14204@psf.upfronthosting.co.za> Message-ID: <1335987097.58.0.329955658062.issue14204@psf.upfronthosting.co.za> Colin Marc added the comment: Ah ok, just curious. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 21:55:24 2012 From: report at bugs.python.org (Pierre Quentel) Date: Wed, 02 May 2012 19:55:24 +0000 Subject: [issue8077] cgi handling of POSTed files is broken In-Reply-To: <1267839820.97.0.586792235494.issue8077@psf.upfronthosting.co.za> Message-ID: <1335988524.12.0.507985620978.issue8077@psf.upfronthosting.co.za> Changes by Pierre Quentel : ---------- nosy: +quentel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 22:05:21 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 02 May 2012 20:05:21 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: <1335989121.97.0.598292788691.issue13183@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The test has been changed in the default branch by changeset 1b174a117e19. This change replaces the assertIn by a less restrictive assertTrue. These changes should also probably be made in 3.2 and 2.7 and hopefully this will fix the problem in 3.2 and 2.7. The changeset 1b174a117e19 in the default branch is: diff --git a/Lib/test/test_pdb.py b/Lib/test/test_pdb.py --- a/Lib/test/test_pdb.py +++ b/Lib/test/test_pdb.py @@ -604,6 +604,7 @@ filename = 'main.py' with open(filename, 'w') as f: f.write(textwrap.dedent(script)) + self.addCleanup(support.unlink, filename) cmd = [sys.executable, '-m', 'pdb', filename] stdout = stderr = None with subprocess.Popen(cmd, stdout=subprocess.PIPE, @@ -660,9 +661,11 @@ """ with open('bar.py', 'w') as f: f.write(textwrap.dedent(bar)) + self.addCleanup(support.unlink, 'bar.py') stdout, stderr = self.run_pdb(script, commands) - self.assertIn('main.py(5)foo()->None', stdout.split('\n')[-3], - 'Fail to step into the caller after a return') + self.assertTrue( + any('main.py(5)foo()->None' in l for l in stdout.splitlines()), + 'Fail to step into the caller after a return') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 22:12:40 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 02 May 2012 20:12:40 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1335989560.11.0.44744754529.issue11618@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Again, to clarify because this seems to have been put to sleep by Martin's unfortunate dismissal. A recap of the patch: 1) Extract the Contition Variable functions on windows out of ceval_gil.h and into thread_nt_cv.h, so that they can be used in more places. 2) Implement the "Lock" primitive in Python using CritialSection and condition variables, rather than windows Mutexes. This gives a large performance boost on uncontended locks. 3) Provide an alternate implementation of the Condition Variable for a build target of Vista/Server 2008, using the native contidion variable objects available for that platform. I think Martin got distraught by 3) and though that was the only thing this patch is about. The important part is 1) and 2) whereas 3) is provided as a bonus (and to make sure that 1) is future-safe) So, can we get this reviewed please? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 23:01:11 2012 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 02 May 2012 21:01:11 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> Message-ID: <1335992471.9.0.523296525575.issue14632@psf.upfronthosting.co.za> Vinay Sajip added the comment: Re. the error on open(), I have no idea why it's failing. That's just open, and it appears to be trying to open a file in a directory for which one would expect you to have write access. Re. the error on unlink(), could that be an older version of the code that you're running? There was a cleanup() function, but I have removed it (and re-tested) before closing the issue. The 3.x buildbots appear not to be showing this failure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 2 23:22:15 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 02 May 2012 21:22:15 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> Message-ID: <1335993735.14.0.289170877322.issue14632@psf.upfronthosting.co.za> Brian Curtin added the comment: I'm seeing this with the current tip 8635825b9734. I wouldn't trust the build slaves with a race condition test since they're incredibly slow machines, but this issue isn't about the race. That path really should be accessible so I'm not sure why it's failing. It's also failing for Richard (sbt) as noted while working on the VS2010 port. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 01:42:40 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 May 2012 23:42:40 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: <1336002160.81.0.443844484376.issue14687@psf.upfronthosting.co.za> STINNER Victor added the comment: pyunicode_format_writer.patch: a new completly different approach. It's an optimistic patch: start with a short ASCII buffer, and grows slowly the buffer, and convert to UCS2 and maybe to UCS4 if needed. The UTF-8 decoder is based on the same idea. The patch adds a "unicode writer", the optimistic writer. It overallocates the buffer by 50% to limit the number of calls to PyUnicode_Resize(). It may be reused by other functions. My dummy benchmark script: ------------ $ cat ~/bench.sh ./python -m timeit \ -s 'fmt="%s:"; arg="abc"' \ 'fmt % arg' ./python -m timeit \ -s 'N=200; L=3; fmt="%s"*N; args=("a"*L,)*N' \ 'fmt % args' ./python -m timeit \ -s 's="x=%s, y=%u, z=%x"; args=(123, 456, 789)' \ 's%args' ./python -m timeit \ -s 's="The %(k1)s is %(k2)s the %(k3)s."; args={"k1":"x","k2":"y","k3":"z",}' \ 's%args' ------------ Results. Python 3.2: 10000000 loops, best of 3: 0.0916 usec per loop 100000 loops, best of 3: 4.04 usec per loop 1000000 loops, best of 3: 0.492 usec per loop 1000000 loops, best of 3: 0.305 usec per loop Python 3.3: 10000000 loops, best of 3: 0.169 usec per loop 100000 loops, best of 3: 8.02 usec per loop 1000000 loops, best of 3: 0.648 usec per loop 1000000 loops, best of 3: 0.658 usec per loop Python 3.3 optimist (compared to 3.3): 10000000 loops, best of 3: 0.123 usec per loop (-27%) 100000 loops, best of 3: 5.73 usec per loop (-29%) 1000000 loops, best of 3: 0.466 usec per loop (-28%) 1000000 loops, best of 3: 0.454 usec per loop (-31%) Overhead of the PEP 393 (Python 3.2 => 3.3) without -> with the patch: * 85% -> 35% * 99% -> 41% * 31% -> -5% (Python 3.3 is *faster* on this specific case! maybe thanks to f4837725c50f) * 115% -> 49% -- "%(name)s" syntax is still *much* slower than Python 3.2, I don't understand why. Parameters of the Unicode writer (overallocation factor and initial size) may be adjusted (later?) for better performances. ---------- Added file: http://bugs.python.org/file25437/pyunicode_format_writer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 01:42:52 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 May 2012 23:42:52 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: <1336002172.57.0.520603842996.issue14687@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25388/pyunicode_format.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 01:44:02 2012 From: report at bugs.python.org (Roger Serwy) Date: Wed, 02 May 2012 23:44:02 +0000 Subject: [issue9925] Idle doesn't launch In-Reply-To: <1285249574.15.0.491090079116.issue9925@psf.upfronthosting.co.za> Message-ID: <1336002242.51.0.135376850656.issue9925@psf.upfronthosting.co.za> Roger Serwy added the comment: Closing this issue as a duplicate of #4625. ---------- resolution: -> duplicate status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 01:46:28 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 May 2012 23:46:28 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 90b4c2d7c90d by Victor Stinner in branch 'default': Issue #14687: Optimize str%tuple for the "%(name)s" syntax http://hg.python.org/cpython/rev/90b4c2d7c90d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 02:14:38 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 03 May 2012 00:14:38 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> Message-ID: <1336004078.94.0.675449426085.issue14632@psf.upfronthosting.co.za> Vinay Sajip added the comment: The only thing I can think of is that the file is kept open by something else (the other thread). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 03:07:49 2012 From: report at bugs.python.org (Mike Meyer) Date: Thu, 03 May 2012 01:07:49 +0000 Subject: [issue12776] argparse: type conversion function should be called only once In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za> Message-ID: <1336007269.63.0.255986518097.issue12776@psf.upfronthosting.co.za> Mike Meyer added the comment: I've just verified that this patch also fixes 13824 and 11839. The attached patchfile adds a test to verify that using a non-existent default file fails if you don't specify the argument, and succeeds if you do. Could someone please apply it? ---------- nosy: +Mike.Meyer Added file: http://bugs.python.org/file25438/fopatch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 03:14:12 2012 From: report at bugs.python.org (Mike Meyer) Date: Thu, 03 May 2012 01:14:12 +0000 Subject: [issue12776] argparse: type conversion function should be called only once In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za> Message-ID: <1336007652.8.0.754135764362.issue12776@psf.upfronthosting.co.za> Mike Meyer added the comment: Sorry - got ahead of myself. It doesn't fix 13824. A deeper reading reveals that the problem wasn't quite what I thought it on first glance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 03:16:46 2012 From: report at bugs.python.org (Mike Meyer) Date: Thu, 03 May 2012 01:16:46 +0000 Subject: [issue11839] argparse: unexpected behavior of default for FileType('w') In-Reply-To: <1302638190.31.0.523851627026.issue11839@psf.upfronthosting.co.za> Message-ID: <1336007806.83.0.857791444526.issue11839@psf.upfronthosting.co.za> Mike Meyer added the comment: Steven - 12776 indeed fixes this issue. I applied the patch from it to a build of todays checkout, verified that my simple test script worked, then wrote some test cases for test_argparse. I've uploaded the patch for that test to both issues. I can't close this as a duplicate, though. ---------- nosy: +Mike.Meyer Added file: http://bugs.python.org/file25439/fopatch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 03:19:24 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 03 May 2012 01:19:24 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> Message-ID: <1336007964.29.0.973709453184.issue14632@psf.upfronthosting.co.za> Vinay Sajip added the comment: The changeset you mentioned doesn't have a cleanup function in test_race (an older version used to) - so I'm not sure where that error is coming from. It's going to be hard for me to reproduce this - I was finding it pretty hard to throw up the original race condition which led to the test being added. If you are getting the error repeatably, it would be really handy if you could tweak the test to generate some more diagnostic information - e.g. if the file already exists when the open fails (=> it's held open by something else). Are you running indexing or anti-virus software on the machine where you get the failures? That can hold a file open when you're not expecting it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 03:22:52 2012 From: report at bugs.python.org (Brian Curtin) Date: Thu, 03 May 2012 01:22:52 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> Message-ID: <1336008172.99.0.761280112532.issue14632@psf.upfronthosting.co.za> Brian Curtin added the comment: I have exemptions set in AV for my dev folders for exactly that reason :) I'll try and poke around and get more info. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 03:41:25 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 May 2012 01:41:25 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: <1336009285.43.0.101825688909.issue14687@psf.upfronthosting.co.za> STINNER Victor added the comment: > Parameters of the Unicode writer (overallocation factor > and initial size) may be adjusted (later?) for better performances. I tried to compute the initial size from the args object. It is hard because we don't know how arguments are used. For example, an argument may not be a number formatted as decimal, but the width of an argument. Another example: "%.3s" may be used to only read the 3 first characters of a very long string. So I consider that it is *simpler and safer* to not guess anything from args, but only choose correctly the overallocation factor. I tried the following factors: 1 (no overallocation), 1.25, 1.5 and 2.0. It looks like 1.25 (pos*5/4) is the best compromise and offers the best performances. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 03:47:51 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 03 May 2012 01:47:51 +0000 Subject: [issue14618] remove modules_reloading from the interpreter state In-Reply-To: <1334799147.41.0.250628519615.issue14618@psf.upfronthosting.co.za> Message-ID: <1336009671.5.0.393951810077.issue14618@psf.upfronthosting.co.za> Eric Snow added the comment: from issue13959: New changeset eb68502731dd by Brett Cannon in branch 'default': Issues #13959, 14647: Re-implement imp.reload() in Lib/imp.py. http://hg.python.org/cpython/rev/eb68502731dd ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 05:10:44 2012 From: report at bugs.python.org (jamesf) Date: Thu, 03 May 2012 03:10:44 +0000 Subject: [issue14708] distutils's checking for MSVC compiler Message-ID: <1336014644.9.0.503289751284.issue14708@psf.upfronthosting.co.za> New submission from jamesf <54740235 at qq.com>: I am using python 2.7.2 installed via the pre-built installer package, and my SDK version is v7.1. 1) The MSSdk environment variable is not set by lastest SDK's SetEnv.cmd anymore, but distutils still check for it. 2) I have also install MSVC 2010 Express Edition, and its vcvarsall.bat can't be found. Off-side question: a) Can i use different version of MSVC from which python is built for extension development ? b) Can i use mingw compiler to develop extension for the pre-built windows binary python ? ---------- messages: 159833 nosy: jwfang priority: normal severity: normal status: open title: distutils's checking for MSVC compiler type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 08:40:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 03 May 2012 06:40:29 +0000 Subject: [issue14708] distutils's checking for MSVC compiler In-Reply-To: <1336014644.9.0.503289751284.issue14708@psf.upfronthosting.co.za> Message-ID: <1336027229.82.0.558626626313.issue14708@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 08:52:50 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 03 May 2012 06:52:50 +0000 Subject: [issue14708] distutils's checking for MSVC compiler In-Reply-To: <1336014644.9.0.503289751284.issue14708@psf.upfronthosting.co.za> Message-ID: <1336027970.17.0.913894971383.issue14708@psf.upfronthosting.co.za> Martin v. L?wis added the comment: > 1) The MSSdk environment variable is not set by lastest SDK's > SetEnv.cmd anymore, but distutils still check for it. This is intentional. Older SDKs still set the variable, so there is nothing wrong with checking it. > 2) I have also install MSVC 2010 Express Edition, and its > vcvarsall.bat can't be found. MSVC 2010 is not supported for building Python 2.7 extension modules. > a) Can i use different version of MSVC from which python is built for > extension development ? No. Because of the way the MSVCRT works, this can cause crashes. > b) Can i use mingw compiler to develop extension for the pre-built > windows binary python ? Yes, in principle. In practice, it may fail because of gcc limitations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 09:08:18 2012 From: report at bugs.python.org (jamesf) Date: Thu, 03 May 2012 07:08:18 +0000 Subject: [issue14708] distutils's checking for MSVC compiler In-Reply-To: <1336014644.9.0.503289751284.issue14708@psf.upfronthosting.co.za> Message-ID: <1336028898.18.0.85679869546.issue14708@psf.upfronthosting.co.za> jamesf <54740235 at qq.com> added the comment: Thanks for your replying. Here is my understanding of how the compiler chosen logic works, correct me if i am wrong: 1) If using MSVC, we should ALWAYS stick the compiler to the version which python was compiled with; 2) But we can change SDK version through DISTUTILS_USE_SDK with SetEnv.cmd already called. 3) It's the compiler version that matters, not SDK version. But from distutils source: if "DISTUTILS_USE_SDK" in os.environ and "MSSdk" in os.environ and ...: ^^^^^ does this mean i can not use lastest SDK since it does not set MSSdk variable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 09:31:06 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 May 2012 07:31:06 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset bba131e48852 by Larry Hastings in branch 'default': Issue #14127: Add ns= parameter to utime, futimes, and lutimes. http://hg.python.org/cpython/rev/bba131e48852 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 09:37:27 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 03 May 2012 07:37:27 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1336030648.0.0.698981414918.issue14127@psf.upfronthosting.co.za> Larry Hastings added the comment: @haypo: Thanks for pointing that out buildbot failure! The OpenIndiana buildbot was bit by a rounding error. I fixed it by adding in a fudge factor it--I snuck in one last change just now. I weakened the unit test as follows: - self.assertEqual(floaty, nanosecondy) + self.assertAlmostEqual(floaty, nanosecondy, delta=2) Also: I'm leaving this issue open for now, to remind myself to add ns= to utimensat and futimesat if they're still alive on June 15th. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 09:54:28 2012 From: report at bugs.python.org (Pierre Quentel) Date: Thu, 03 May 2012 07:54:28 +0000 Subject: [issue8077] cgi handling of POSTed files is broken In-Reply-To: <1267839820.97.0.586792235494.issue8077@psf.upfronthosting.co.za> Message-ID: <1336031668.17.0.111066920056.issue8077@psf.upfronthosting.co.za> Pierre Quentel added the comment: There are 2 different problems : - handling of data by cgi.FieldStorage (issue 4953) : fixed since version 3.2 - in http.server.CGIHTTPRequestHandler, for POST requests on Windows, before opening the subprocess in run_cgi() all data is read by a *single* call to self.rfile.read(). If not all bytes are read by this single call, which is the case for a large file upload, only the read data are processed The attached patch modifies http.server : - if all data are read in the first call to self.rfile.read() (that is, if its length is equal to the Content-length header), process them - if not, store all data in a temporary file (not in memory) and set the stdin argument of subprocess.Popen to this temporary file With this patch, the tests provided by Mitchell all work on my PC (Windows XP Pro SP3) ---------- keywords: +patch Added file: http://bugs.python.org/file25440/http-server.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 10:16:19 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 03 May 2012 08:16:19 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336032979.87.0.206340462195.issue14705@psf.upfronthosting.co.za> Larry Hastings added the comment: My first patch. Adds 'p' and 'P', along with documentation and unit tests. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file25441/larry.parse.tuple.p.and.P.1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 10:18:58 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 May 2012 08:18:58 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1336030648.0.0.698981414918.issue14127@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > The OpenIndiana buildbot was bit by a rounding error. How do we have rounding issue with only integers? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 10:24:23 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 03 May 2012 08:24:23 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1336033463.9.0.10579100182.issue14127@psf.upfronthosting.co.za> Larry Hastings added the comment: We don't! The test that failed compares the ns_[amc]time and ns_[amc]time_ns fields to ensure they're roughly equivalent. Note that the former fields are floats, which by now ought not to be news to you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 10:43:50 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 03 May 2012 08:43:50 +0000 Subject: [issue8077] cgi handling of POSTed files is broken In-Reply-To: <1267839820.97.0.586792235494.issue8077@psf.upfronthosting.co.za> Message-ID: <1336034630.39.0.0124441802882.issue8077@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- assignee: -> orsenthil nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 10:46:04 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 03 May 2012 08:46:04 +0000 Subject: [issue14708] distutils's checking for MSVC compiler In-Reply-To: <1336014644.9.0.503289751284.issue14708@psf.upfronthosting.co.za> Message-ID: <1336034764.74.0.066313597962.issue14708@psf.upfronthosting.co.za> Martin v. L?wis added the comment: DISTUTILS_USE_SDK really means "shut up, I know what I'm doing". So if this is the case (i.e. you *really* know what you are doing), just set MsSdk as well. I don't actually know whether the latest SDK is able to build correct extensions for Python 2.7 - I haven't looked at the latest SDK. It may be that MS stopped setting MsSdk for a reason. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 10:46:57 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 03 May 2012 08:46:57 +0000 Subject: [issue14708] distutils's checking for MSVC compiler In-Reply-To: <1336014644.9.0.503289751284.issue14708@psf.upfronthosting.co.za> Message-ID: <1336034817.98.0.372944535756.issue14708@psf.upfronthosting.co.za> Martin v. L?wis added the comment: In any case, it appears that there is no bug report in this issue, so I'm closing this as "works for me". ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 11:34:01 2012 From: report at bugs.python.org (Paolo Elvati) Date: Thu, 03 May 2012 09:34:01 +0000 Subject: [issue11839] argparse: unexpected behavior of default for FileType('w') In-Reply-To: <1302638190.31.0.523851627026.issue11839@psf.upfronthosting.co.za> Message-ID: <1336037641.93.0.60987648864.issue11839@psf.upfronthosting.co.za> Changes by Paolo Elvati : ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 11:36:13 2012 From: report at bugs.python.org (Paolo Elvati) Date: Thu, 03 May 2012 09:36:13 +0000 Subject: [issue11839] argparse: unexpected behavior of default for FileType('w') In-Reply-To: <1302638190.31.0.523851627026.issue11839@psf.upfronthosting.co.za> Message-ID: <1336037773.44.0.0993511758518.issue11839@psf.upfronthosting.co.za> Changes by Paolo Elvati : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 11:36:44 2012 From: report at bugs.python.org (Paolo Elvati) Date: Thu, 03 May 2012 09:36:44 +0000 Subject: [issue11839] argparse: unexpected behavior of default for FileType('w') In-Reply-To: <1302638190.31.0.523851627026.issue11839@psf.upfronthosting.co.za> Message-ID: <1336037804.09.0.564311137963.issue11839@psf.upfronthosting.co.za> Changes by Paolo Elvati : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 12:10:50 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 May 2012 10:10:50 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336039850.72.0.0405907906704.issue14705@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch looks good to me. I however prefer to use 'P'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 12:31:38 2012 From: report at bugs.python.org (=?utf-8?q?Tobias_Steinr=C3=BCcken?=) Date: Thu, 03 May 2012 10:31:38 +0000 Subject: [issue14709] http.client fails sending read()able Object Message-ID: <1336041098.08.0.116585068152.issue14709@psf.upfronthosting.co.za> New submission from Tobias Steinr?cken : It seems that http.client's send() function lacks an else/return statement in Line 772. If this method is called with an read()able Object, it jumps into L 750: if hasattr( data,"read"): processes this data correctly, but then falls through (due to missing else ) to L 773: try: L 774: self.socket.sendall(data) where finally an TypeError raises. ---------- components: None messages: 159845 nosy: Tobias.Steinr?cken priority: normal severity: normal status: open title: http.client fails sending read()able Object type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 12:34:08 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 May 2012 10:34:08 +0000 Subject: [issue14624] Faster utf-16 decoder In-Reply-To: <1334869141.17.0.802149162715.issue14624@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 830eeff4fe8f by Victor Stinner in branch 'default': Issue #14624, #14687: Optimize unicode_widen() http://hg.python.org/cpython/rev/830eeff4fe8f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 12:34:08 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 May 2012 10:34:08 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 830eeff4fe8f by Victor Stinner in branch 'default': Issue #14624, #14687: Optimize unicode_widen() http://hg.python.org/cpython/rev/830eeff4fe8f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 12:45:41 2012 From: report at bugs.python.org (Pavel Aslanov) Date: Thu, 03 May 2012 10:45:41 +0000 Subject: [issue14710] pkgutil.get_loader is broken Message-ID: <1336041941.32.0.315196686397.issue14710@psf.upfronthosting.co.za> New submission from Pavel Aslanov : if module was marked as not existing by setting sys.modules [fullname] to None, then pkgutil.get_loader (fullname) will throw AttributeError. Example: #! /usr/bin/evn python import unittest import pkgutil def main (): pkgutil.get_loader ('unittest.functools') if __name__ == '__main__': main () Patch is attached ---------- components: Library (Lib) files: python_pkgutil_bug.patch keywords: patch messages: 159848 nosy: Pavel.Aslanov priority: normal severity: normal status: open title: pkgutil.get_loader is broken type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file25442/python_pkgutil_bug.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 12:54:44 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 03 May 2012 10:54:44 +0000 Subject: [issue14710] pkgutil.get_loader is broken In-Reply-To: <1336041941.32.0.315196686397.issue14710@psf.upfronthosting.co.za> Message-ID: <1336042484.96.0.981380561655.issue14710@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brett.cannon, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 12:55:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 03 May 2012 10:55:03 +0000 Subject: [issue14709] http.client fails sending read()able Object In-Reply-To: <1336041098.08.0.116585068152.issue14709@psf.upfronthosting.co.za> Message-ID: <1336042503.94.0.744416396645.issue14709@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 13:12:19 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 May 2012 11:12:19 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: <1336043539.74.0.988825440924.issue14687@psf.upfronthosting.co.za> STINNER Victor added the comment: Results on 32 bits (Intel Core i5 CPU 661 @ 3.33GHz) on Linux 3.0 with a new patch. Python 3.2: 10000000 loops, best of 3: 0.133 usec per loop 100000 loops, best of 3: 4.64 usec per loop 1000000 loops, best of 3: 0.637 usec per loop 1000000 loops, best of 3: 0.364 usec per loop Python 3.3 @ 1439e2d1f490 (before my first optimization on str%tuple): 10000000 loops, best of 3: 0.193 usec per loop 100000 loops, best of 3: 10.1 usec per loop 1000000 loops, best of 3: 0.838 usec per loop 1000000 loops, best of 3: 0.825 usec per loop Python 3.3 + patch, overallocate 50%: 10000000 loops, best of 3: 0.15 usec per loop 100000 loops, best of 3: 8.27 usec per loop 1000000 loops, best of 3: 0.527 usec per loop 1000000 loops, best of 3: 0.566 usec per loop Python 3.3 + patch, overallocate 25%: 10000000 loops, best of 3: 0.142 usec per loop 100000 loops, best of 3: 7.93 usec per loop 1000000 loops, best of 3: 0.532 usec per loop 1000000 loops, best of 3: 0.546 usec per loop I'm going to commit the new patch with an overallocation of 25%. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 13:17:06 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 May 2012 11:17:06 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f1db931b93d3 by Victor Stinner in branch 'default': Issue #14687: str%tuple now uses an optimistic "unicode writer" instead of an http://hg.python.org/cpython/rev/f1db931b93d3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 13:17:57 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 May 2012 11:17:57 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: <1336043877.59.0.729165300079.issue14687@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 13:31:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 03 May 2012 11:31:20 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1336043539.74.0.988825440924.issue14687@psf.upfronthosting.co.za> Message-ID: <1336044573.3344.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > Results on 32 bits (Intel Core i5 CPU 661 @ 3.33GHz) on Linux 3.0 with > a new patch. It would be nice to have measurements under Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 13:43:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 May 2012 11:43:26 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 0a9143d7b097 by Victor Stinner in branch 'default': Issue #14687: Cleanup unicode_writer_prepare() http://hg.python.org/cpython/rev/0a9143d7b097 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 13:44:32 2012 From: report at bugs.python.org (Ultrasick) Date: Thu, 03 May 2012 11:44:32 +0000 Subject: [issue5118] '%.2f' % 2.545 doesn't round correctly In-Reply-To: <1233406671.56.0.693255150937.issue5118@psf.upfronthosting.co.za> Message-ID: <1336045472.89.0.585444637274.issue5118@psf.upfronthosting.co.za> Ultrasick added the comment: Ok, let's sum that up: There is a rounding problem. That's because Python uses floating point registers of the x86-CPU-architecture to store point values. This method is inaccurate and causes such problems. So Python inherits this bug from this value storing method. Even thou the origin of this bug is in the method which is beeing used, Python has inherited this bug and can't round correctly. If we would say that Python does not support point values but only floating point values of the x86-CPU-architecture (so not even floating point values in general) then we could admit that round(2.545, 2) has a bug because it "incorrectly" shows 2.55 as the result. But that wouldn't help us any further. One possible solution would be to use a different method to store point values. For exaple 2 integers could be used to store a point value lossless. The one integer stores whatever is left of the point and the other integer stores whatever is right of the point. Meaning: 25.0: -> integer #1: 0,000,000,025 -> integer #2: 0,000,000,000 25.99997: -> integer #1: 0,000,000,025 -> integer #2: 0,999,970,000 25.00001 -> integer #1: 0,000,000,025 -> integer #2: 0,000,010,000 As you can see, this method is lossless. As long as you don't try to store more than 32 significant bits in a register which is 32 bits in size. To be more accurate: you can't even use all 32 bits because the most significant digit can only be between 0 and 4 (4,294,967,295 barrier). Using this value storing method would mean quite some efforts for the developers. But then Python would be able to round correctly. So that's why I call it a "possible solution". I am not the one who is going to make the decision, whether a different value-storing-method is going to be implemented, indepentend how this value storing method may look like. But I am one of thouse who suffered from the method which is currently implemented. @Mark: And I am also one of thouse who lost a lot of interrest in helping out in the futher development of Python. It was because your haughtiness. You tried to show how perfect Python is and that there would be no bugs. But your last comment was a little more productive. Even thou you still haven't showed much interest in finding a solution to the problem. @Zeev: I already gave up. But you had more endurance. Thanks :-) Gary ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 14:15:57 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 May 2012 12:15:57 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1336044573.3344.0.camel@localhost.localdomain> Message-ID: <1336047510.2520.5.camel@raxxla> Serhiy Storchaka added the comment: > It would be nice to have measurements under Windows. The differences between 32-bit Linux and 32-bit Windows should not be. But 64-bit can be different, and 64-bit Linux and 64-bit Windows can vary from 32-bit, and from each other. There are also differences between high-end Intel Core and low-end Intel Atom, and AMD processors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 14:25:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 03 May 2012 12:25:20 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1336047510.2520.5.camel@raxxla> Message-ID: <1336047814.3344.4.camel@localhost.localdomain> Antoine Pitrou added the comment: > > It would be nice to have measurements under Windows. > > The differences between 32-bit Linux and 32-bit Windows should not be. The Windows memory allocator is quite different from the glibc's, so the overallocation / resizing approach may play differently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 14:26:26 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 May 2012 12:26:26 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1336043539.74.0.988825440924.issue14687@psf.upfronthosting.co.za> Message-ID: <1336048137.2520.15.camel@raxxla> Serhiy Storchaka added the comment: > Results on 32 bits (Intel Core i5 CPU 661 @ 3.33GHz) on Linux 3.0 with a new patch. Your tests only for ascii. You should also see some of corner cases -- a large format string and a few small arguments (templating), a small simple format string and one large argument (idiomatic `'[%s]' % ', '.join(long_list)`). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 14:57:16 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 May 2012 12:57:16 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1336033463.9.0.10579100182.issue14127@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.x/builds/3388/steps/test/logs/stdio ERROR: test_copy2_symlinks (test.test_shutil.TestShutil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_shutil.py", line 328, in test_copy2_symlinks shutil.copy2(src_link, dst, symlinks=True) File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/shutil.py", line 193, in copy2 copystat(src, dst, symlinks=symlinks) File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/shutil.py", line 157, in copystat utime_func(dst, ns=(st.st_atime_ns, st.st_mtime_ns)) TypeError: _nop() got an unexpected keyword argument 'ns' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 15:21:48 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 May 2012 13:21:48 +0000 Subject: [issue14624] Faster utf-16 decoder In-Reply-To: Message-ID: <1336051447.2520.30.camel@raxxla> Serhiy Storchaka added the comment: Here is updated patch, taking into account that unicode_widen is already optimized. ---------- Added file: http://bugs.python.org/file25443/decode_utf16_2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 0a9143d7b097 Objects/stringlib/asciilib.h --- a/Objects/stringlib/asciilib.h Thu May 03 13:43:07 2012 +0200 +++ b/Objects/stringlib/asciilib.h Thu May 03 15:50:11 2012 +0300 @@ -7,6 +7,7 @@ #define STRINGLIB(F) asciilib_##F #define STRINGLIB_OBJECT PyUnicodeObject #define STRINGLIB_SIZEOF_CHAR 1 +#define STRINGLIB_MAX_CHAR 0x7Fu #define STRINGLIB_CHAR Py_UCS1 #define STRINGLIB_TYPE_NAME "unicode" #define STRINGLIB_PARSE_CODE "U" diff -r 0a9143d7b097 Objects/stringlib/codecs.h --- a/Objects/stringlib/codecs.h Thu May 03 13:43:07 2012 +0200 +++ b/Objects/stringlib/codecs.h Thu May 03 15:50:11 2012 +0300 @@ -150,7 +150,6 @@ return ret; } -#undef LONG_PTR_MASK #undef ASCII_CHAR_MASK @@ -350,4 +349,153 @@ #undef MAX_SHORT_UNICHARS } +#define UCS2_REPEAT_MASK (~0ul / 0xFFFFul) + +/* The mask for fast checking of whether a C 'long' may contain + UTF16-encoded surrogate characters. This is an efficient heuristic, + assuming that non-surrogate characters with a code point >= 0x8000 are + rare in most input. +*/ +#if STRINGLIB_SIZEOF_CHAR == 1 +# define FAST_CHAR_MASK (UCS2_REPEAT_MASK * (0xFFFFu & ~STRINGLIB_MAX_CHAR)) +#else +# define FAST_CHAR_MASK (UCS2_REPEAT_MASK * 0x8000u) +#endif +/* The mask for fast byteswapping. */ +#define STRIPPED_MASK (UCS2_REPEAT_MASK * 0x00FFu) +/* Swap bytes. */ +#define SWAB(value) ((((value) >> 8) & STRIPPED_MASK) | \ + (((value) & STRIPPED_MASK) << 8)) + +Py_LOCAL_INLINE(Py_UCS4) +STRINGLIB(utf16_try_decode)(STRINGLIB_CHAR *dest, Py_ssize_t *outpos, + const unsigned char **inptr, + const unsigned char *e, + int native_ordering) +{ + const unsigned char *aligned_end = + (const unsigned char *) ((size_t) (e + 1) & ~LONG_PTR_MASK); + const unsigned char *q = *inptr; + STRINGLIB_CHAR *p = dest + *outpos; + /* Offsets from q for retrieving byte pairs in the right order. */ +#ifdef BYTEORDER_IS_LITTLE_ENDIAN + int ihi = !!native_ordering, ilo = !native_ordering; +#else + int ihi = !native_ordering, ilo = !!native_ordering; +#endif + + while (q < e) { + Py_UCS4 ch; + /* First check for possible aligned read of a C 'long'. Unaligned + reads are more expensive, better to defer to another iteration. */ + if (!((size_t) q & LONG_PTR_MASK)) { + /* Fast path for runs of non-surrogate chars. */ + register const unsigned char *_q = q; + while (_q < aligned_end) { + unsigned long block = * (unsigned long *) _q; + /* Fast checking of whether a C 'long' may contain + UTF16-encoded surrogate characters. This is an efficient + heuristic, assuming that non-surrogate characters with + a code point >= 0x8000 are rare in most input. + */ + if (native_ordering) { + /* Can use buffer directly */ + if (block & FAST_CHAR_MASK) + break; + } + else { + /* Need to byte-swap */ + if (block & SWAB(FAST_CHAR_MASK)) + break; +#if STRINGLIB_SIZEOF_CHAR == 1 + block >>= 8; +#else + block = SWAB(block); +#endif + } +#ifdef BYTEORDER_IS_LITTLE_ENDIAN +#if SIZEOF_LONG == 4 + *(p + 0) = (STRINGLIB_CHAR)(block & 0xFFFFu); + *(p + 1) = (STRINGLIB_CHAR)(block >> 16); +#endif +#if SIZEOF_LONG == 8 + *(p + 0) = (STRINGLIB_CHAR)(block & 0xFFFFu); + *(p + 1) = (STRINGLIB_CHAR)((block >> 16) & 0xFFFFu); + *(p + 2) = (STRINGLIB_CHAR)((block >> 32) & 0xFFFFu); + *(p + 3) = (STRINGLIB_CHAR)(block >> 48); +#endif +#else +#if SIZEOF_LONG == 4 + *(p + 0) = (STRINGLIB_CHAR)(block >> 16); + *(p + 1) = (STRINGLIB_CHAR)(block & 0xFFFFu); +#endif +#if SIZEOF_LONG == 8 + *(p + 0) = (STRINGLIB_CHAR)(block >> 48); + *(p + 1) = (STRINGLIB_CHAR)((block >> 32) & 0xFFFFu); + *(p + 2) = (STRINGLIB_CHAR)((block >> 16) & 0xFFFFu); + *(p + 3) = (STRINGLIB_CHAR)(block & 0xFFFFu); +#endif +#endif + _q += SIZEOF_LONG; + p += SIZEOF_LONG / 2; + } + q = _q; + if (q >= e) + break; + } + ch = (q[ihi] << 8) | q[ilo]; + q += 2; +#if STRINGLIB_SIZEOF_CHAR == 1 + if (ch <= STRINGLIB_MAX_CHAR) { + *p++ = (STRINGLIB_CHAR)ch; + continue; + } +#endif + if (!Py_UNICODE_IS_SURROGATE(ch)) { +#if STRINGLIB_SIZEOF_CHAR >= 2 + *p++ = (STRINGLIB_CHAR)ch; + continue; +#else + *inptr = q; + *outpos = p - dest; + return ch; +#endif + } + /* UTF-16 code pair: */ + if (q < e) { + if (Py_UNICODE_IS_HIGH_SURROGATE(ch)) { + Py_UCS4 ch2 = (q[ihi] << 8) | q[ilo]; + q += 2; + if (Py_UNICODE_IS_LOW_SURROGATE(ch2)) { + ch = Py_UNICODE_JOIN_SURROGATES(ch, ch2); +#if STRINGLIB_SIZEOF_CHAR == 4 + *p++ = (STRINGLIB_CHAR)ch; + continue; +#else + *inptr = q; + *outpos = p - dest; + return ch; +#endif + } + *inptr = q; + *outpos = p - dest; + return 3; /* illegal UTF-16 surrogate */ + } + *inptr = q; + *outpos = p - dest; + return 2; /* illegal encoding */ + } + *inptr = q; + *outpos = p - dest; + return 1; /* unexpected end of data */ + } + *inptr = q; + *outpos = p - dest; + return 0; +} +#undef UCS2_REPEAT_MASK +#undef FAST_CHAR_MASK +#undef STRIPPED_MASK +#undef SWAB +#undef LONG_PTR_MASK #endif /* STRINGLIB_IS_UNICODE */ diff -r 0a9143d7b097 Objects/stringlib/ucs1lib.h --- a/Objects/stringlib/ucs1lib.h Thu May 03 13:43:07 2012 +0200 +++ b/Objects/stringlib/ucs1lib.h Thu May 03 15:50:11 2012 +0300 @@ -7,6 +7,7 @@ #define STRINGLIB(F) ucs1lib_##F #define STRINGLIB_OBJECT PyUnicodeObject #define STRINGLIB_SIZEOF_CHAR 1 +#define STRINGLIB_MAX_CHAR 0xFFu #define STRINGLIB_CHAR Py_UCS1 #define STRINGLIB_TYPE_NAME "unicode" #define STRINGLIB_PARSE_CODE "U" diff -r 0a9143d7b097 Objects/stringlib/ucs2lib.h --- a/Objects/stringlib/ucs2lib.h Thu May 03 13:43:07 2012 +0200 +++ b/Objects/stringlib/ucs2lib.h Thu May 03 15:50:11 2012 +0300 @@ -7,6 +7,7 @@ #define STRINGLIB(F) ucs2lib_##F #define STRINGLIB_OBJECT PyUnicodeObject #define STRINGLIB_SIZEOF_CHAR 2 +#define STRINGLIB_MAX_CHAR 0xFFFFu #define STRINGLIB_CHAR Py_UCS2 #define STRINGLIB_TYPE_NAME "unicode" #define STRINGLIB_PARSE_CODE "U" diff -r 0a9143d7b097 Objects/stringlib/ucs4lib.h --- a/Objects/stringlib/ucs4lib.h Thu May 03 13:43:07 2012 +0200 +++ b/Objects/stringlib/ucs4lib.h Thu May 03 15:50:11 2012 +0300 @@ -7,6 +7,7 @@ #define STRINGLIB(F) ucs4lib_##F #define STRINGLIB_OBJECT PyUnicodeObject #define STRINGLIB_SIZEOF_CHAR 4 +#define STRINGLIB_MAX_CHAR 0x10FFFFu #define STRINGLIB_CHAR Py_UCS4 #define STRINGLIB_TYPE_NAME "unicode" #define STRINGLIB_PARSE_CODE "U" diff -r 0a9143d7b097 Objects/stringlib/undef.h --- a/Objects/stringlib/undef.h Thu May 03 13:43:07 2012 +0200 +++ b/Objects/stringlib/undef.h Thu May 03 15:50:11 2012 +0300 @@ -1,6 +1,7 @@ #undef FASTSEARCH #undef STRINGLIB #undef STRINGLIB_SIZEOF_CHAR +#undef STRINGLIB_MAX_CHAR #undef STRINGLIB_CHAR #undef STRINGLIB_STR #undef STRINGLIB_LEN diff -r 0a9143d7b097 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Thu May 03 13:43:07 2012 +0200 +++ b/Objects/unicodeobject.c Thu May 03 15:50:11 2012 +0300 @@ -4644,6 +4644,10 @@ return PyUnicode_DecodeUTF8Stateful(s, size, errors, NULL); } +#include "stringlib/asciilib.h" +#include "stringlib/codecs.h" +#include "stringlib/undef.h" + #include "stringlib/ucs1lib.h" #include "stringlib/codecs.h" #include "stringlib/undef.h" @@ -5472,25 +5476,6 @@ return PyUnicode_DecodeUTF16Stateful(s, size, errors, byteorder, NULL); } -/* Two masks for fast checking of whether a C 'long' may contain - UTF16-encoded surrogate characters. This is an efficient heuristic, - assuming that non-surrogate characters with a code point >= 0x8000 are - rare in most input. - FAST_CHAR_MASK is used when the input is in native byte ordering, - SWAPPED_FAST_CHAR_MASK when the input is in byteswapped ordering. -*/ -#if (SIZEOF_LONG == 8) -# define FAST_CHAR_MASK 0x8000800080008000L -# define SWAPPED_FAST_CHAR_MASK 0x0080008000800080L -# define STRIPPED_MASK 0x00FF00FF00FF00FFL -#elif (SIZEOF_LONG == 4) -# define FAST_CHAR_MASK 0x80008000L -# define SWAPPED_FAST_CHAR_MASK 0x00800080L -# define STRIPPED_MASK 0x00FF00FFL -#else -# error C 'long' size should be either 4 or 8! -#endif - PyObject * PyUnicode_DecodeUTF16Stateful(const char *s, Py_ssize_t size, @@ -5503,30 +5488,22 @@ Py_ssize_t endinpos; Py_ssize_t outpos; PyObject *unicode; - const unsigned char *q, *e, *aligned_end; + const unsigned char *q, *e; int bo = 0; /* assume native ordering by default */ - int native_ordering = 0; + int native_ordering; const char *errmsg = ""; - /* Offsets from q for retrieving byte pairs in the right order. */ -#ifdef BYTEORDER_IS_LITTLE_ENDIAN - int ihi = 1, ilo = 0; -#else - int ihi = 0, ilo = 1; -#endif PyObject *errorHandler = NULL; PyObject *exc = NULL; - /* Note: size will always be longer than the resulting Unicode - character count */ - unicode = PyUnicode_New(size, 127); - if (!unicode) - return NULL; - if (size == 0) - return unicode; - outpos = 0; + if (size == 0) { + if (consumed) + *consumed = 0; + Py_INCREF(unicode_empty); + return unicode_empty; + } q = (unsigned char *)s; - e = q + size - 1; + e = q + size; if (byteorder) bo = *byteorder; @@ -5537,8 +5514,7 @@ stream as-is (giving a ZWNBSP character). */ if (bo == 0) { if (size >= 2) { - const Py_UCS4 bom = (q[ihi] << 8) | q[ilo]; -#ifdef BYTEORDER_IS_LITTLE_ENDIAN + const Py_UCS4 bom = (q[1] << 8) | q[0]; if (bom == 0xFEFF) { q += 2; bo = -1; @@ -5547,143 +5523,80 @@ q += 2; bo = 1; } + } + } + +#ifdef BYTEORDER_IS_LITTLE_ENDIAN + native_ordering = bo <= 0; #else - if (bom == 0xFEFF) { - q += 2; - bo = 1; - } - else if (bom == 0xFFFE) { - q += 2; - bo = -1; - } -#endif - } - } - - if (bo == -1) { - /* force LE */ - ihi = 1; - ilo = 0; - } - else if (bo == 1) { - /* force BE */ - ihi = 0; - ilo = 1; - } -#ifdef BYTEORDER_IS_LITTLE_ENDIAN - native_ordering = ilo < ihi; -#else - native_ordering = ilo > ihi; -#endif - - aligned_end = (const unsigned char *) ((size_t) e & ~LONG_PTR_MASK); - while (q < e) { - Py_UCS4 ch; - /* First check for possible aligned read of a C 'long'. Unaligned - reads are more expensive, better to defer to another iteration. */ - if (!((size_t) q & LONG_PTR_MASK)) { - /* Fast path for runs of non-surrogate chars. */ - register const unsigned char *_q = q; + native_ordering = bo >= 0; +#endif + + /* Note: size will always be longer than the resulting Unicode + character count */ + unicode = PyUnicode_New(size, 127); + if (!unicode) + return NULL; + outpos = 0; + + while (1) { + Py_UCS4 ch = 0; + if (e - q > 1) { + const unsigned char *e2 = e - 1; int kind = PyUnicode_KIND(unicode); - void *data = PyUnicode_DATA(unicode); - while (_q < aligned_end) { - unsigned long block = * (unsigned long *) _q; - Py_UCS4 maxch; - if (native_ordering) { - /* Can use buffer directly */ - if (block & FAST_CHAR_MASK) - break; - } - else { - /* Need to byte-swap */ - if (block & SWAPPED_FAST_CHAR_MASK) - break; - block = ((block >> 8) & STRIPPED_MASK) | - ((block & STRIPPED_MASK) << 8); - } - maxch = (Py_UCS2)(block & 0xFFFF); -#if SIZEOF_LONG == 8 - ch = (Py_UCS2)((block >> 16) & 0xFFFF); - maxch = MAX_MAXCHAR(maxch, ch); - ch = (Py_UCS2)((block >> 32) & 0xFFFF); - maxch = MAX_MAXCHAR(maxch, ch); - ch = (Py_UCS2)(block >> 48); - maxch = MAX_MAXCHAR(maxch, ch); -#else - ch = (Py_UCS2)(block >> 16); - maxch = MAX_MAXCHAR(maxch, ch); -#endif - if (maxch > PyUnicode_MAX_CHAR_VALUE(unicode)) { - if (unicode_widen(&unicode, outpos, maxch) < 0) - goto onError; - kind = PyUnicode_KIND(unicode); - data = PyUnicode_DATA(unicode); - } -#ifdef BYTEORDER_IS_LITTLE_ENDIAN - PyUnicode_WRITE(kind, data, outpos++, (Py_UCS2)(block & 0xFFFF)); -#if SIZEOF_LONG == 8 - PyUnicode_WRITE(kind, data, outpos++, (Py_UCS2)((block >> 16) & 0xFFFF)); - PyUnicode_WRITE(kind, data, outpos++, (Py_UCS2)((block >> 32) & 0xFFFF)); - PyUnicode_WRITE(kind, data, outpos++, (Py_UCS2)((block >> 48))); -#else - PyUnicode_WRITE(kind, data, outpos++, (Py_UCS2)(block >> 16)); -#endif -#else -#if SIZEOF_LONG == 8 - PyUnicode_WRITE(kind, data, outpos++, (Py_UCS2)((block >> 48))); - PyUnicode_WRITE(kind, data, outpos++, (Py_UCS2)((block >> 32) & 0xFFFF)); - PyUnicode_WRITE(kind, data, outpos++, (Py_UCS2)((block >> 16) & 0xFFFF)); -#else - PyUnicode_WRITE(kind, data, outpos++, (Py_UCS2)(block >> 16)); -#endif - PyUnicode_WRITE(kind, data, outpos++, (Py_UCS2)(block & 0xFFFF)); -#endif - _q += SIZEOF_LONG; - } - q = _q; - if (q >= e) - break; - } - ch = (q[ihi] << 8) | q[ilo]; - - q += 2; - - if (!Py_UNICODE_IS_SURROGATE(ch)) { + if (kind == PyUnicode_1BYTE_KIND) { + if (PyUnicode_IS_ASCII(unicode)) + ch = asciilib_utf16_try_decode( + PyUnicode_1BYTE_DATA(unicode), &outpos, + &q, e2, native_ordering); + else + ch = ucs1lib_utf16_try_decode( + PyUnicode_1BYTE_DATA(unicode), &outpos, + &q, e2, native_ordering); + } else if (kind == PyUnicode_2BYTE_KIND) { + ch = ucs2lib_utf16_try_decode( + PyUnicode_2BYTE_DATA(unicode), &outpos, + &q, e2, native_ordering); + } else { + assert(kind == PyUnicode_4BYTE_KIND); + ch = ucs4lib_utf16_try_decode( + PyUnicode_4BYTE_DATA(unicode), &outpos, + &q, e2, native_ordering); + } + } + switch (ch) + { + case 0: + /* remaining byte at the end? (size should be even) */ + if (q == e || consumed) + goto End; + errmsg = "truncated data"; + startinpos = ((const char *)q) - starts; + endinpos = ((const char *)e) - starts; + break; + /* The remaining input chars are ignored if the callback + chooses to skip the input */ + case 1: + errmsg = "unexpected end of data"; + startinpos = ((const char *)q) - 2 - starts; + endinpos = ((const char *)e) - starts; + break; + case 2: + errmsg = "illegal encoding"; + startinpos = ((const char *)q) - 2 - starts; + endinpos = startinpos + 2; + break; + case 3: + errmsg = "illegal UTF-16 surrogate"; + startinpos = ((const char *)q) - 4 - starts; + endinpos = startinpos + 2; + break; + default: if (unicode_putchar(&unicode, &outpos, ch) < 0) goto onError; continue; } - /* UTF-16 code pair: */ - if (q > e) { - errmsg = "unexpected end of data"; - startinpos = (((const char *)q) - 2) - starts; - endinpos = ((const char *)e) + 1 - starts; - goto utf16Error; - } - if (Py_UNICODE_IS_HIGH_SURROGATE(ch)) { - Py_UCS4 ch2 = (q[ihi] << 8) | q[ilo]; - q += 2; - if (Py_UNICODE_IS_LOW_SURROGATE(ch2)) { - if (unicode_putchar(&unicode, &outpos, - Py_UNICODE_JOIN_SURROGATES(ch, ch2)) < 0) - goto onError; - continue; - } - else { - errmsg = "illegal UTF-16 surrogate"; - startinpos = (((const char *)q)-4)-starts; - endinpos = startinpos+2; - goto utf16Error; - } - - } - errmsg = "illegal encoding"; - startinpos = (((const char *)q)-2)-starts; - endinpos = startinpos+2; - /* Fall through to report the error */ - - utf16Error: if (unicode_decode_call_errorhandler( errors, &errorHandler, @@ -5698,30 +5611,8 @@ &outpos)) goto onError; } - /* remaining byte at the end? (size should be even) */ - if (e == q) { - if (!consumed) { - errmsg = "truncated data"; - startinpos = ((const char *)q) - starts; - endinpos = ((const char *)e) + 1 - starts; - if (unicode_decode_call_errorhandler( - errors, - &errorHandler, - "utf16", errmsg, - &starts, - (const char **)&e, - &startinpos, - &endinpos, - &exc, - (const char **)&q, - &unicode, - &outpos)) - goto onError; - /* The remaining input chars are ignored if the callback - chooses to skip the input */ - } - } - + +End: if (byteorder) *byteorder = bo; @@ -5743,9 +5634,6 @@ return NULL; } -#undef FAST_CHAR_MASK -#undef SWAPPED_FAST_CHAR_MASK - PyObject * _PyUnicode_EncodeUTF16(PyObject *str, const char *errors, From report at bugs.python.org Thu May 3 15:26:28 2012 From: report at bugs.python.org (Armin Ronacher) Date: Thu, 03 May 2012 13:26:28 +0000 Subject: [issue14711] Remove os.stat_float_times Message-ID: <1336051588.91.0.440090520788.issue14711@psf.upfronthosting.co.za> New submission from Armin Ronacher : Is there a specific reason this is still around? Originally that was to make it possible to upgrade to Python 2.3 or whenever that was introduced. I don't think anyone still uses that. ---------- messages: 159859 nosy: aronacher priority: normal severity: normal status: open title: Remove os.stat_float_times versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 16:20:32 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 May 2012 14:20:32 +0000 Subject: [issue14711] Remove os.stat_float_times In-Reply-To: <1336051588.91.0.440090520788.issue14711@psf.upfronthosting.co.za> Message-ID: <1336054832.98.0.838712437004.issue14711@psf.upfronthosting.co.za> R. David Murray added the comment: Victor proposed deprecating it as part of PEP 410 (see issue 13882), but the PEP was rejected for other reasons. ---------- nosy: +haypo, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 17:19:28 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 03 May 2012 15:19:28 +0000 Subject: [issue14710] pkgutil.get_loader is broken In-Reply-To: <1336041941.32.0.315196686397.issue14710@psf.upfronthosting.co.za> Message-ID: <1336058368.16.0.488016577295.issue14710@psf.upfronthosting.co.za> Brett Cannon added the comment: So I'm no pkgutil expert, but at least in the case of None in sys.modules, that triggers at least an ImportError in __import__ if that is come across. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 17:31:03 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 03 May 2012 15:31:03 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> Message-ID: <1336059063.89.0.591807238506.issue14632@psf.upfronthosting.co.za> Vinay Sajip added the comment: I noticed that in my cleanup code, I had the lines h.close() remover.join() but it makes more sense for these to be in the opposite order. I've made that changed and pushed it up (for 2.7, 3.2 and default). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 17:34:31 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 03 May 2012 15:34:31 +0000 Subject: [issue14712] Integrate PEP 405 Message-ID: <1336059271.86.0.0525487031192.issue14712@psf.upfronthosting.co.za> New submission from Vinay Sajip : This issue will track implementation of PEP 405 functionality. ---------- assignee: vinay.sajip messages: 159863 nosy: vinay.sajip priority: normal severity: normal status: open title: Integrate PEP 405 versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 17:35:38 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 03 May 2012 15:35:38 +0000 Subject: [issue14712] Integrate PEP 405 In-Reply-To: <1336059271.86.0.0525487031192.issue14712@psf.upfronthosting.co.za> Message-ID: <1336059338.66.0.51153942255.issue14712@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- hgrepos: +120 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 17:36:55 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 03 May 2012 15:36:55 +0000 Subject: [issue14712] Integrate PEP 405 In-Reply-To: <1336059271.86.0.0525487031192.issue14712@psf.upfronthosting.co.za> Message-ID: <1336059415.43.0.267041384609.issue14712@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- keywords: +patch Added file: http://bugs.python.org/file25444/c82881ad6b6f.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 17:42:21 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 03 May 2012 15:42:21 +0000 Subject: [issue14713] PEP 414 installation hook fails with an AssertionError Message-ID: <1336059741.48.0.751323304263.issue14713@psf.upfronthosting.co.za> New submission from Vinay Sajip : I'm not sure if I've done something wrong, but I get an AssertionError when trying to run the tokenizer on a Python file from the Django source. The gist at https://gist.github.com/1977558 has the files concerned: 1. test_tokenize.py - the script which fails 2. tokenize_example.py - the file being tokenized and untokenized. This is from the Django source: django/extras/csrf_migration_helper.py 3. tokenizer.py - your tokenize module, I renamed it because I was working in /tmp and didn't want to import the Python 3.2 stdlib's tokenize.py 4. The test output shows that the tokenize_example module imports OK in Python 2.7.2, but running the test_tokenize script on it with Python3.2 fails with an AssertionError. I did some more testing, there are 131 failures in the Django source tree (all look like the same AssertionError). N.B. I posted this to your GitHub repo where you published the hook. ---------- messages: 159864 nosy: aronacher, vinay.sajip priority: normal severity: normal status: open title: PEP 414 installation hook fails with an AssertionError _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 17:43:51 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 03 May 2012 15:43:51 +0000 Subject: [issue14714] PEp 414 tokenizing hook does not preserve tabs Message-ID: <1336059831.47.0.0507292871504.issue14714@psf.upfronthosting.co.za> New submission from Vinay Sajip : Tabs in Python source are a no-no for me and lots of other people, but some people do use them. The tokenizer seems to not preserve tabs in its output. There are some tabs in the Django source, for example tests/regressiontests/localflavor/pl/tests.py. N.B. I posted this to your GitHub repo where you published the hook. ---------- messages: 159865 nosy: aronacher, vinay.sajip priority: normal severity: normal status: open title: PEp 414 tokenizing hook does not preserve tabs type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 17:44:07 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 03 May 2012 15:44:07 +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: <1336059847.98.0.641030112975.issue14713@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 18:27:58 2012 From: report at bugs.python.org (Daniel543) Date: Thu, 03 May 2012 16:27:58 +0000 Subject: [issue14707] extend() puzzled me. In-Reply-To: <1335975316.5.0.356302155228.issue14707@psf.upfronthosting.co.za> Message-ID: <1336062478.32.0.396266865986.issue14707@psf.upfronthosting.co.za> Daniel543 added the comment: Thank u both. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 19:28:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 May 2012 17:28:27 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f58159e5d52f by Victor Stinner in branch 'default': Issue #14687: Remove redundant length attribute of unicode_write_t http://hg.python.org/cpython/rev/f58159e5d52f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 19:34:19 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 03 May 2012 17:34:19 +0000 Subject: [issue5118] '%.2f' % 2.545 doesn't round correctly In-Reply-To: <1233406671.56.0.693255150937.issue5118@psf.upfronthosting.co.za> Message-ID: <1336066459.1.0.765115327183.issue5118@psf.upfronthosting.co.za> Mark Dickinson added the comment: > That's because Python uses floating point registers of the x86-CPU- > architecture to store point values. This method is inaccurate and causes > such problems. Yes, exactly; this is the root cause. And as you suggest, Python *could* use a different numeric storage format that doesn't suffer from loss of information when initializing a number from a decimal string. There's an obvious candidate for that storage format, and that's the decimal.Decimal type. There are some issues, though: (1) decimal.Decimal operations are implemented in software (in pure Python for versions <= 3.2, and now in C in Python 3.3) and so are orders of magnitude slower than hardware-supported floats. That's one of the reasons that almost every mainstream programming language uses the binary-represented hardware floats as the main way of representing non-integral numbers. The need for those fast floats isn't going to go away in a hurry. The obvious solution here would be to for Python to support both binary floats and decimal floats, and perhaps to make numeric literals default to being decimal.Decimal instances. (2) Getting to the point where the Decimal type could be used for numeric literals will be a *long* road, full of backwards compatibility concerns, PEPs, and long and probably contentious python-dev discussions. Python's just taken the first step along that road by reimplementing the decimal module in C for Python 3.3; this improves the speed significantly (though floats are still significantly more efficient in both time and space, and likely will be for a long time), and also makes it easier to start using decimal more widely from within the core of Python. Reaching that point of having the Decimal type more fully integrated into Python is something that I know a good few of the Python developers are interested in (including me). But it's not going to be an easy or quick change. > @Mark: And I am also one of thouse who lost a lot of interrest in helping out in the futher development of > Python. It was because your haughtiness. I see how my earlier messages came across badly. I apologise for that, and I hope you won't let the poorly chosen words of just one Python developer out of many put you off future involvement in Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 21:30:22 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 03 May 2012 19:30:22 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: <1336073422.41.0.59860921545.issue14687@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Do you think that this optimization is relevant to 2.7? In that case, it might be worthwhile for me to backport it to our EVE branch... ---------- nosy: +kristjan.jonsson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 21:31:39 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 03 May 2012 19:31:39 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1336073499.71.0.30023719469.issue14684@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: A dictionary could be provided an init time. Then, the Z_NEED_DICT could be intercepted in the binding and automatically inject the dictionary provided in the init. Anyway, for a patch to be approved, we need a test too. PS: Why is this NOT targeted to 3.3?. We have time, yet. ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 21:57:41 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 May 2012 19:57:41 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset cdc4e0f8135d by Larry Hastings in branch 'default': Issue #14127: Fix no-op stub for platforms that lack some "os" functions. http://hg.python.org/cpython/rev/cdc4e0f8135d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 22:21:46 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 May 2012 20:21:46 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1336073422.41.0.59860921545.issue14687@psf.upfronthosting.co.za> Message-ID: <1336076656.10049.2.camel@raxxla> Serhiy Storchaka added the comment: > Do you think that this optimization is relevant to 2.7? No, this is just an attempt to deal with the shortcomings of PEP 393. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 23:04:29 2012 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 03 May 2012 21:04:29 +0000 Subject: [issue14715] test.support.DirsOnSysPath should be replaced by importlib.test.util.import_state Message-ID: <1336079069.84.0.625762752869.issue14715@psf.upfronthosting.co.za> New submission from Eric V. Smith : DirsOnSysPath doesn't clear sys.path_importer_cache, so it seems you'd always want to use import_state, which does clear it. We might also want to modify import_state to remember the original objects, not just their values. DirsOnSysPath does do this, for sys.path. If we do this, we should probably move import_state to test.support. Also, couldn't import_state do with sys.modules what DirsOnSysPath does with sys.path? It could restore both the object and its contents. ---------- messages: 159873 nosy: barry, brett.cannon, eric.smith, jason.coombs priority: normal severity: normal status: open title: test.support.DirsOnSysPath should be replaced by importlib.test.util.import_state versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 23:25:51 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 May 2012 21:25:51 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: <1336080351.54.0.727785033299.issue14687@psf.upfronthosting.co.za> STINNER Victor added the comment: Results on Windows Seven 64 bits, on Intel i7 2600 @ 3.4 GHz (8 cores), Windows running in a virtual machine (kvm) with hardware virtualization. Python 3.2.2: 10000000 loops, best of 3: 0.12 usec per loop 100000 loops, best of 3: 5.12 usec per loop 1000000 loops, best of 3: 0.581 usec per loop 1000000 loops, best of 3: 0.397 usec per loop Python 3.3 @ 1439e2d1f490: 1000000 loops, best of 3: 0.265 usec per loop 100000 loops, best of 3: 11 usec per loop 1000000 loops, best of 3: 0.961 usec per loop 1000000 loops, best of 3: 0.924 usec per loop Python 3.3 @ cdc4e0f8135d: 10000000 loops, best of 3: 0.154 usec per loop 100000 loops, best of 3: 7.85 usec per loop 1000000 loops, best of 3: 0.583 usec per loop 1000000 loops, best of 3: 0.535 usec per loop To be honest, I'm surprised that my work speeds up Python 3.3 on Windows, because I read that realloc() on Windows is not efficient. It is maybe no more true with Windows Seven? It would be interesting if someone could run the benchmark on Windows XP or 2000. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 23:33:58 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 03 May 2012 21:33:58 +0000 Subject: [issue8536] Support new features of ZLIB 1.2.7 In-Reply-To: <1272302591.08.0.11918516326.issue8536@psf.upfronthosting.co.za> Message-ID: <1336080838.4.0.2447487324.issue8536@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- title: Support new features of ZLIB 1.2.6 -> Support new features of ZLIB 1.2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 23:34:58 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 03 May 2012 21:34:58 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1336080351.54.0.727785033299.issue14687@psf.upfronthosting.co.za> Message-ID: <1336080789.3344.8.camel@localhost.localdomain> Antoine Pitrou added the comment: > Python 3.3 @ 1439e2d1f490: > > 1000000 loops, best of 3: 0.265 usec per loop > 100000 loops, best of 3: 11 usec per loop > 1000000 loops, best of 3: 0.961 usec per loop > 1000000 loops, best of 3: 0.924 usec per loop > > Python 3.3 @ cdc4e0f8135d: > > 10000000 loops, best of 3: 0.154 usec per loop > 100000 loops, best of 3: 7.85 usec per loop > 1000000 loops, best of 3: 0.583 usec per loop > 1000000 loops, best of 3: 0.535 usec per loop Very nice, thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 23:35:21 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 03 May 2012 21:35:21 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: <1336080921.35.0.778347516741.issue14687@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: > because I read that realloc() on Windows is not efficient. Efficiency is not a Boolean property, you know :) Anyway, I?d be surprised if it were very iniefficient, given that the heap allocators on Windows are quite mature by now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 23:36:17 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 03 May 2012 21:36:17 +0000 Subject: [issue14711] Remove os.stat_float_times In-Reply-To: <1336051588.91.0.440090520788.issue14711@psf.upfronthosting.co.za> Message-ID: <1336080977.28.0.538888952427.issue14711@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 23:36:50 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 03 May 2012 21:36:50 +0000 Subject: [issue14712] Integrate PEP 405 In-Reply-To: <1336059271.86.0.0525487031192.issue14712@psf.upfronthosting.co.za> Message-ID: <1336081010.15.0.488033914153.issue14712@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 23:42:48 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 May 2012 21:42:48 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: <1336081368.68.0.774804478777.issue14687@psf.upfronthosting.co.za> STINNER Victor added the comment: >> because I read that realloc() on Windows is not efficient. > Efficiency is not a Boolean property, you know :) Anyway, > I?d be surprised if it were very iniefficient, given that > the heap allocators on Windows are quite mature by now. My benchmark is more a *micro* benchmark on some very basic cases (short ASCII strings). But it looks like overallocating *helps*. In the following example, only two resize are needed: ./python -m timeit \ -s 'N=200; L=3; fmt="%s"*N; args=("a"*L,)*N' \ 'fmt % args' len(fmt)+100 = 500 characters are allocated for the initial buffer. Writing the 501st character enlarges the buffer to 626 characters: first resize. The output string is truncated to 600 characters: second and final resize. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 3 23:52:38 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 03 May 2012 21:52:38 +0000 Subject: [issue14715] test.support.DirsOnSysPath should be replaced by importlib.test.util.import_state In-Reply-To: <1336079069.84.0.625762752869.issue14715@psf.upfronthosting.co.za> Message-ID: <1336081958.94.0.920366838256.issue14715@psf.upfronthosting.co.za> Brett Cannon added the comment: Yes, it could do all of this. One possibility that I was thinking of, was this could be a setUp()/tearDown() thing as well instead of a context manager. Another option is a simple decorator. Either way it might be easier to have it just save state and then in the body of the code set everything as desired instead of in the context manager's init. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 00:08:17 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 May 2012 22:08:17 +0000 Subject: [issue14716] Use unicode_writer API for str.format() Message-ID: <1336082896.6.0.108889213788.issue14716@psf.upfronthosting.co.za> New submission from STINNER Victor : I just added a new "unicode_writer" API for the issue #14687 (Optimize str%tuple for the PEP 393) which helps to make "str%tuple" between 25% and 30% faster. Attached patch replaces PyAccu API with the unicode_writer API for str.format(). Python 3.2: 1000000 loops, best of 3: 0.198 usec per loop 100000 loops, best of 3: 11.3 usec per loop 10000000 loops, best of 3: 0.167 usec per loop 1000000 loops, best of 3: 0.494 usec per loop Python 3.3: 1000000 loops, best of 3: 0.293 usec per loop 10000 loops, best of 3: 20.2 usec per loop 1000000 loops, best of 3: 0.219 usec per loop 1000000 loops, best of 3: 0.909 usec per loop Python 3.3 + patch (speed up of the patch): 1000000 loops, best of 3: 0.226 usec per loop (-22%) 100000 loops, best of 3: 14.8 usec per loop (-26%) 1000000 loops, best of 3: 0.219 usec per loop (0%) 1000000 loops, best of 3: 0.658 usec per loop (-27%) ---------- components: Interpreter Core files: unicode_format_writer.patch keywords: patch messages: 159879 nosy: haypo, kristjan.jonsson, loewis, pitrou, python-dev, storchaka priority: normal severity: normal status: open title: Use unicode_writer API for str.format() type: performance versions: Python 3.3 Added file: http://bugs.python.org/file25445/unicode_format_writer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 00:11:50 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 May 2012 22:11:50 +0000 Subject: [issue14716] Use unicode_writer API for str.format() In-Reply-To: <1336082896.6.0.108889213788.issue14716@psf.upfronthosting.co.za> Message-ID: <1336083110.46.0.0901303946978.issue14716@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I forgot the benchmark script: ------------ $ cat ~/bench_format.sh ./python -m timeit \ -s 'fmt="{}:"; arg="abc"' \ 'fmt.format(arg)' ./python -m timeit \ -s 'N=200; L=3; fmt="{}"*N; args=("a"*L,)*N' \ 'fmt.format(*args)' ./python -m timeit \ -s 's="x=%s, y=%u, z=%x"; args=(123, 456, 789)' \ 's.format(*args)' ./python -m timeit \ -s 's="The {k1} is {k2} the {k3}."; args={"k1": "x", "k2": "y", "k3": "z"}' \ 's.format(**args)' ------------ (based on the one used for #14687, see msg159822) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 00:15:30 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 May 2012 22:15:30 +0000 Subject: [issue14711] Remove os.stat_float_times In-Reply-To: <1336051588.91.0.440090520788.issue14711@psf.upfronthosting.co.za> Message-ID: <1336083330.32.0.268868596118.issue14711@psf.upfronthosting.co.za> STINNER Victor added the comment: > Is there a specific reason this is still around? Not really, it just that nobody noticed it :-) We can deprecate it, but it is maybe safer to not remove it. Note: os.stat() has now new st_*time_ns fields with a nanosecond resolution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 00:18:35 2012 From: report at bugs.python.org (py.user) Date: Thu, 03 May 2012 22:18:35 +0000 Subject: [issue14717] In generator's .close() docstring there is one argument Message-ID: <1336083515.09.0.187983865633.issue14717@psf.upfronthosting.co.za> New submission from py.user : >>> g >>> print(g.close.__doc__) close(arg) -> raise GeneratorExit inside generator. >>> g.close(1) Traceback (most recent call last): File "", line 1, in TypeError: close() takes no arguments (1 given) >>> ---------- assignee: docs at python components: Documentation messages: 159882 nosy: docs at python, py.user priority: normal severity: normal status: open title: In generator's .close() docstring there is one argument versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 00:22:23 2012 From: report at bugs.python.org (py.user) Date: Thu, 03 May 2012 22:22:23 +0000 Subject: [issue14718] In the generator's try/finally statement a runtime error occurs when the generator is not exhausted Message-ID: <1336083743.08.0.117486073655.issue14718@psf.upfronthosting.co.za> New submission from py.user : http://www.python.org/dev/peps/pep-0342/ " 6. Allow "yield" to be used in try/finally blocks, since garbage collection or an explicit close() call would now allow the finally clause to execute." "New syntax: yield allowed inside try-finally The syntax for generator functions is extended to allow a yield-statement inside a try-finally statement." >>> def f(): ... try: ... yield 1 ... yield 2 ... yield 3 ... finally: ... yield 4 ... >>> g = f() >>> next(g) 1 >>> next(g) 2 >>> g = f() Exception RuntimeError: 'generator ignored GeneratorExit' in ignored >>> ---------- components: Interpreter Core messages: 159883 nosy: py.user priority: normal severity: normal status: open title: In the generator's try/finally statement a runtime error occurs when the generator is not exhausted type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 00:33:17 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 03 May 2012 22:33:17 +0000 Subject: [issue14718] In the generator's try/finally statement a runtime error occurs when the generator is not exhausted In-Reply-To: <1336083743.08.0.117486073655.issue14718@psf.upfronthosting.co.za> Message-ID: <1336084397.79.0.634122437478.issue14718@psf.upfronthosting.co.za> Benjamin Peterson added the comment: It means in the body of the try statement. ---------- nosy: +benjamin.peterson resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 00:35:02 2012 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 03 May 2012 22:35:02 +0000 Subject: [issue14716] Use unicode_writer API for str.format() In-Reply-To: <1336082896.6.0.108889213788.issue14716@psf.upfronthosting.co.za> Message-ID: <1336084502.21.0.617455149725.issue14716@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 00:44:40 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 May 2012 22:44:40 +0000 Subject: [issue14717] In generator's .close() docstring there is one argument In-Reply-To: <1336083515.09.0.187983865633.issue14717@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b8c1cabcd115 by Benjamin Peterson in branch '3.2': close() doesn't take any args (closes #14717) http://hg.python.org/cpython/rev/b8c1cabcd115 New changeset b2031eb95dd9 by Benjamin Peterson in branch '2.7': close() doesn't take any args (closes #14717) http://hg.python.org/cpython/rev/b2031eb95dd9 New changeset da12cb2461d1 by Benjamin Peterson in branch 'default': merge 3.2 (#14717) http://hg.python.org/cpython/rev/da12cb2461d1 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 01:04:17 2012 From: report at bugs.python.org (Sam Rushing) Date: Thu, 03 May 2012 23:04:17 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1336086257.1.0.0778324847886.issue14684@psf.upfronthosting.co.za> Sam Rushing added the comment: I'm currently reworking this so that the dictionaries are provided in the constructor, and inflateSetDictionary() is called automatically. I've gone over the zlib RFC's and zlibmodule.c, and I'm fairly certain that whatever usage mode might involve multiple calls to SetDictionary() couldn't be supported by the zlib object anyway. r.e. 3.3/3.4 - I merely chose the highest version number I saw, since this diff is against HEAD (as recommended by the docs). It's been quite a few years since I've submitted a patch to CPython! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 01:38:25 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 03 May 2012 23:38:25 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1336088305.14.0.251376010627.issue14684@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Retargetting to python 3.3. If you hurry a bit and I find your patch acceptable (remember the tests!), I will try to integrate it. ---------- assignee: -> serwy nosy: +serwy versions: +Python 3.3 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 01:39:10 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 03 May 2012 23:39:10 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1336088350.46.0.242541270305.issue14684@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- assignee: serwy -> nosy: -serwy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 01:48:10 2012 From: report at bugs.python.org (Sam Rushing) Date: Thu, 03 May 2012 23:48:10 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1336088890.72.0.0726101100258.issue14684@psf.upfronthosting.co.za> Sam Rushing added the comment: Ok, here's the patch. It has a single short test. For use with SPDY, it's necessary to test that the following stream data also correctly decompresses, I'll attach that to the next comment. ---------- Added file: http://bugs.python.org/file25446/zlib_set_dictionary_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 01:50:07 2012 From: report at bugs.python.org (Sam Rushing) Date: Thu, 03 May 2012 23:50:07 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1336089007.5.0.0536321349748.issue14684@psf.upfronthosting.co.za> Sam Rushing added the comment: This test is rather large, since it includes the predefined SPDY draft 2 dictionary, and some real-world data. Not sure what the policy is on including so much data in a test. If there's enough time I could make a smaller test that also verifies the correct behavior on a stream... ---------- Added file: http://bugs.python.org/file25447/tz2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 02:00:25 2012 From: report at bugs.python.org (Sam Rushing) Date: Fri, 04 May 2012 00:00:25 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1336089625.75.0.877613502412.issue14684@psf.upfronthosting.co.za> Sam Rushing added the comment: Argh, probably need to add the 'dict' field to the copy() method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 02:16:44 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 04 May 2012 00:16:44 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1336090604.12.0.704956764436.issue14127@psf.upfronthosting.co.za> Richard Oudkerk added the comment: bba131e48852 causes crashes on Windows. The attached patch fixes the crash and makes test_os pass for me. However, using "PyErr_ExceptionMatches(PyExc_RuntimeError)" to check whether to try again using narrow strings is ugly. Maybe utime_read_time_arguments() should be changed to have three possible return values. ---------- nosy: +sbt Added file: http://bugs.python.org/file25448/utime-hack.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 02:22:20 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 04 May 2012 00:22:20 +0000 Subject: [issue14711] Remove os.stat_float_times In-Reply-To: <1336051588.91.0.440090520788.issue14711@psf.upfronthosting.co.za> Message-ID: <1336090940.84.0.637511971018.issue14711@psf.upfronthosting.co.za> Martin v. L?wis added the comment: > Is there a specific reason this is still around? I forgot to remove it for Python 3, and now it can only be removed through a deprecation cycle. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 02:50:27 2012 From: report at bugs.python.org (Sam Rushing) Date: Fri, 04 May 2012 00:50:27 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1336092627.66.0.282180253641.issue14684@psf.upfronthosting.co.za> Sam Rushing added the comment: Updated version of the patch: extends the test, including a test of the streaming behavior needed for SPDY (both compression and decompression). Also wik: copy()/uncopy() are aware of the 'dict' attribute. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 02:51:05 2012 From: report at bugs.python.org (Sam Rushing) Date: Fri, 04 May 2012 00:51:05 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1336092665.62.0.656623164694.issue14684@psf.upfronthosting.co.za> Changes by Sam Rushing : Added file: http://bugs.python.org/file25449/zlib_set_dictionary_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 04:21:22 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 04 May 2012 02:21:22 +0000 Subject: [issue14654] Faster utf-8 decoding In-Reply-To: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za> Message-ID: <1336098082.53.0.105774514886.issue14654@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- title: More fast utf-8 decoding -> Faster utf-8 decoding _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 05:16:07 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 04 May 2012 03:16:07 +0000 Subject: [issue14517] distutils always recompiles all C source files In-Reply-To: <1333711497.18.0.995661570344.issue14517@psf.upfronthosting.co.za> Message-ID: <1336101367.99.0.944610251125.issue14517@psf.upfronthosting.co.za> ?ric Araujo added the comment: Hm, this change was done on purpose, because of the problems caused by stale object files (as explained on the other bug report), so it cannot just be reverted. distutils is also under a feature freeze, only clear bugs warrant a change, so a performance improvement request like this must target distutils2, if we could find a good way to do it. ---------- title: Recompilation of sources with Distutils -> distutils always recompiles all C source files _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 05:16:34 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 04 May 2012 03:16:34 +0000 Subject: [issue5372] Distutils inappropriately reuses .o files between extension modules In-Reply-To: <1235606727.67.0.443849487538.issue5372@psf.upfronthosting.co.za> Message-ID: <1336101394.48.0.0637984335702.issue5372@psf.upfronthosting.co.za> ?ric Araujo added the comment: See also #14517. ---------- nosy: +eric.araujo resolution: accepted -> fixed stage: patch review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 05:22:36 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 04 May 2012 03:22:36 +0000 Subject: [issue14712] Integrate PEP 405 In-Reply-To: <1336059271.86.0.0525487031192.issue14712@psf.upfronthosting.co.za> Message-ID: <1336101756.26.0.573241129294.issue14712@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 05:25:32 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 04 May 2012 03:25:32 +0000 Subject: [issue14715] test.support.DirsOnSysPath should be replaced by importlib.test.util.import_state In-Reply-To: <1336079069.84.0.625762752869.issue14715@psf.upfronthosting.co.za> Message-ID: <1336101932.54.0.866616266922.issue14715@psf.upfronthosting.co.za> ?ric Araujo added the comment: I tend to like context managers, or helpers that work with addCleanup, so that I keep the scaffolding next to the test code. setUp and tearDown are better in some cases, though. It is also possible to have an helper work as a decorator and a context manager and a setUp-tearDown thing with small effort. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 05:33:03 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 04 May 2012 03:33:03 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1336102383.2.0.514255173038.issue14684@psf.upfronthosting.co.za> ?ric Araujo added the comment: Added a few comments on Rietveld. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 05:33:41 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 04 May 2012 03:33:41 +0000 Subject: [issue14711] Remove os.stat_float_times In-Reply-To: <1336051588.91.0.440090520788.issue14711@psf.upfronthosting.co.za> Message-ID: <1336102421.02.0.0394519645091.issue14711@psf.upfronthosting.co.za> ?ric Araujo added the comment: Let?s deprecate it in 3.3 then. ---------- nosy: +eric.araujo versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 06:13:42 2012 From: report at bugs.python.org (Darrell Long) Date: Fri, 04 May 2012 04:13:42 +0000 Subject: [issue14719] Lists: [[0]*N]*N != [[0 for _ in range(N)] for __ in range(N)] Message-ID: <1336104822.52.0.958479666589.issue14719@psf.upfronthosting.co.za> New submission from Darrell Long : N = 5 board_1 = [[0 for _ in range(N)] for __ in range(N)] is not the same as: board_2= [[0]*N]*N One makes a proper list of lists (the first), the second makes a new kind of animal were board_2[1][1] = 99 changes a whole column. Oddly, testing board_1 == board_2 is True! I'm teaching Python to non-majors, and this is a tough one to explain. ---------- components: Interpreter Core files: Screen Shot 2012-05-03 at 9.05.59 PM.png messages: 159899 nosy: darrell priority: normal severity: normal status: open title: Lists: [[0]*N]*N != [[0 for _ in range(N)] for __ in range(N)] versions: Python 2.7 Added file: http://bugs.python.org/file25450/Screen Shot 2012-05-03 at 9.05.59 PM.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 06:15:56 2012 From: report at bugs.python.org (Darrell Long) Date: Fri, 04 May 2012 04:15:56 +0000 Subject: [issue14719] Lists: [[0]*N]*N != [[0 for _ in range(N)] for __ in range(N)] In-Reply-To: <1336104822.52.0.958479666589.issue14719@psf.upfronthosting.co.za> Message-ID: <1336104956.86.0.974813733754.issue14719@psf.upfronthosting.co.za> Changes by Darrell Long : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 06:17:18 2012 From: report at bugs.python.org (Pavel Aslanov) Date: Fri, 04 May 2012 04:17:18 +0000 Subject: [issue14710] pkgutil.get_loader is broken In-Reply-To: <1336041941.32.0.315196686397.issue14710@psf.upfronthosting.co.za> Message-ID: <1336105038.83.0.937688662697.issue14710@psf.upfronthosting.co.za> Pavel Aslanov added the comment: Main use case of pkgutil.get_loader is to determine if its possible to load module and either return loader or None. But it throws exception more over it is AttributeErrror exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 06:36:28 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 04 May 2012 04:36:28 +0000 Subject: [issue14710] pkgutil.get_loader is broken In-Reply-To: <1336041941.32.0.315196686397.issue14710@psf.upfronthosting.co.za> Message-ID: <1336106188.85.0.172642016617.issue14710@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm not yet sure the proposed fix in the patch is the right approach (I need to look at the surrounding code), but I believe Pavel's right that get_loader() should be returning None in this case instead of throwing an exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 06:39:17 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 04 May 2012 04:39:17 +0000 Subject: [issue14517] distutils always recompiles all C source files In-Reply-To: <1333711497.18.0.995661570344.issue14517@psf.upfronthosting.co.za> Message-ID: <1336106357.07.0.340717026668.issue14517@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 06:41:48 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 04 May 2012 04:41:48 +0000 Subject: [issue14710] pkgutil.get_loader is broken In-Reply-To: <1336041941.32.0.315196686397.issue14710@psf.upfronthosting.co.za> Message-ID: <1336106508.68.0.746539344304.issue14710@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 08:06:20 2012 From: report at bugs.python.org (Yuval Greenfield) Date: Fri, 04 May 2012 06:06:20 +0000 Subject: [issue14719] Lists: [[0]*N]*N != [[0 for _ in range(N)] for __ in range(N)] In-Reply-To: <1336104822.52.0.958479666589.issue14719@psf.upfronthosting.co.za> Message-ID: <1336111580.46.0.208810153379.issue14719@psf.upfronthosting.co.za> Yuval Greenfield added the comment: This isn't a bug and should be closed. It's more of a stack overflow question. If you'd like to change this fundamental behavior of a very common operation in python you should make a proposal to the python ideas mailing list at http://mail.python.org/mailman/listinfo/python-ideas In your example board_2 is equivalent to: row = [0] * N board_2 = row * N All the rows are the same initial row. As opposed to board_1 where each row is a new row. Try this: [id(i) for i in board_2] The initial equivalence is because they do represent the same values (NxN list of all zeroes). What should python compare if not by values? ---------- nosy: +ubershmekel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 08:18:54 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 04 May 2012 06:18:54 +0000 Subject: [issue14719] Lists: [[0]*N]*N != [[0 for _ in range(N)] for __ in range(N)] In-Reply-To: <1336104822.52.0.958479666589.issue14719@psf.upfronthosting.co.za> Message-ID: <1336112334.7.0.757896599485.issue14719@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It's actually fairly easy to explain. Just think about it harder (and consider Yuval's explanation). ---------- nosy: +loewis resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 08:22:22 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 May 2012 06:22:22 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1336112542.53.0.689787018919.issue14127@psf.upfronthosting.co.za> Larry Hastings added the comment: > bba131e48852 causes crashes on Windows. > > The attached patch fixes the crash and makes test_os pass for me. > > However, using "PyErr_ExceptionMatches(PyExc_RuntimeError)" to check > whether to try again using narrow strings is ugly. Maybe > utime_read_time_arguments() should be changed to have three possible > return values. I appreciate the feedback, and the patch. And I agree--we should be able to find a better fix than that particular band-aid. Can we hold off on checking in a patch for now? TBH I don't understand why it should crash, and therefore how your patch helps. Trying again using narrow strings should always work; indeed, the code did that before I touched it. Can you describe how it crashes? (p.s. Considering that I can't test on Windows myself, I'm pretty happy that the code works as well as it does!) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 08:31:06 2012 From: report at bugs.python.org (Frank Millman) Date: Fri, 04 May 2012 06:31:06 +0000 Subject: [issue14720] sqlite3 microseconds Message-ID: <1336113066.83.0.671734474285.issue14720@psf.upfronthosting.co.za> New submission from Frank Millman : sqlite3/dbapi2.py contains the following - def convert_timestamp(val): datepart, timepart = val.split(b" ") timepart_full = timepart.split(b".") [...] if len(timepart_full) == 2: microseconds = int(timepart_full[1]) else: microseconds = 0 It assumes that 'timepart_full[1]' is a string containing 6 digits. I have a situation where the string containing 3 digits, so it gives the wrong result. For example, if the string is '456', this represents 456000 microseconds, but sqlite3 returns 456 microseconds. I think that it should right-zero-fill the string to 6 digits before converting to an int, like this - microseconds = int('{:0<6}'.format(timepart_full[1])) ---------- components: Library (Lib) messages: 159905 nosy: frankmillman priority: normal severity: normal status: open title: sqlite3 microseconds type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 08:45:01 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 04 May 2012 06:45:01 +0000 Subject: [issue14719] Lists: [[0]*N]*N != [[0 for _ in range(N)] for __ in range(N)] In-Reply-To: <1336104822.52.0.958479666589.issue14719@psf.upfronthosting.co.za> Message-ID: <1336113901.19.0.545293971007.issue14719@psf.upfronthosting.co.za> Ezio Melotti added the comment: http://docs.python.org/faq/programming.html#how-do-i-create-a-multidimensional-list http://python.net/crew/mwh/hacks/objectthink.html ---------- nosy: +ezio.melotti stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 09:08:26 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 May 2012 07:08:26 +0000 Subject: [issue14654] Faster utf-8 decoding In-Reply-To: <1336098082.58.0.744922313654.issue14654@psf.upfronthosting.co.za> Message-ID: <1336115461.2329.6.camel@raxxla> Serhiy Storchaka added the comment: > title: More fast utf-8 decoding -> Faster utf-8 decoding ?ric, there is already an issue (#4868) with this title. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 09:24:17 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 04 May 2012 07:24:17 +0000 Subject: [issue14654] Faster utf-8 decoding In-Reply-To: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za> Message-ID: <1336116257.13.0.631331893395.issue14654@psf.upfronthosting.co.za> Martin v. L?wis added the comment: There is nothing wrong with two issues having the same title. Of course, it would be best if the title reflected the *actual* defect or change, such as "specialize UTF-8 decoding by character width", or some such. In any case, the title change is desirable since the original title was ungrammatical. If you wanted to point out that this really is an augmented, escalated rise, then "Even faster utf-8 decoded", "amazingly faster UTF-8 decoding", or "unbelievably faster utf-8 decoding" could have worked :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 09:51:55 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 04 May 2012 07:51:55 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1336117915.61.0.922507312184.issue14127@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > TBH I don't understand why it should crash, and therefore how your patch > helps. Trying again using narrow strings should always work; indeed, the > code did that before I touched it. Can you describe how it crashes? The important part of the patch is the removal of the "!" in if (!utime_read_time_arguments(&ua)) { Without that change, if utime_read_time_arguments(&ua) fails then the unicode path is wrongly chosen. Then PyUnicode_AsUnicode(upath) is called when upath has not been initialized. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 09:59:42 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 May 2012 07:59:42 +0000 Subject: [issue14654] Faster utf-8 decoding In-Reply-To: <1336116257.13.0.631331893395.issue14654@psf.upfronthosting.co.za> Message-ID: <1336118536.2329.8.camel@raxxla> Serhiy Storchaka added the comment: Thank you, Martin, this is what I had in mind. Lost in translation. ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 10:03:49 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 04 May 2012 08:03:49 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1336118629.66.0.608044868426.issue14127@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Without the check for RuntimeError os.utime("foo", times=(5,5), ns=(5,5)) raises TypeError("TypeError: 'str' does not support the buffer interface") because we have fallen through to the narrow path. The correct error is RuntimeError("utime: you may specify either 'times' or 'ns' but not both") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 11:17:10 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 May 2012 09:17:10 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1336123030.77.0.615817311375.issue14127@psf.upfronthosting.co.za> Larry Hastings added the comment: Let me recap, just to make sure I have it straight. There are two errors on Windows: * The ! on (what is currently) line 3770 is wrong: if (!utime_read_time_arguments(&ua)) { * If you pass in a Unicode string but also pass in both times and ns, you get the wrong error: effectively it's complaining that the string is not narrow, when it should be complaining about having both times and ns. For the former, obviously removing the ! is correct. But I like your idea of making the utime_read_time_argument() return value tell you what happened; that's what the Windows code needs to know. So here it is! Please see the attached patch. ---------- Added file: http://bugs.python.org/file25451/larry.utime.win32.bugfix.1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 11:30:48 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 04 May 2012 09:30:48 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1336123848.75.0.213616984722.issue14127@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > Let me recap, just to make sure I have it straight. There are two errors > on Windows: That's right. The patch looks good and passes for me on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 11:32:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 May 2012 09:32:57 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset fc5d2f4291ac by Larry Hastings in branch 'default': Issue #14127: Fix two bugs with the Windows implementation. http://hg.python.org/cpython/rev/fc5d2f4291ac ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 12:06:43 2012 From: report at bugs.python.org (Arve Knudsen) Date: Fri, 04 May 2012 10:06:43 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data Message-ID: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> New submission from Arve Knudsen : httplib doesn't specify the HTTP header 'content-length' for POST requests without data. Conceptually this makes sense, considering the empty content. However, IIS (7.5) servers don't accept such requests and respond with a 411 status code. See this question on StackOverflow for reference: http://stackoverflow.com/questions/5915131/can-i-send-an-empty-http-post-webrequest-object-from-c-sharp-to-iis. See also issue #223 of the Requests project, https://github.com/kennethreitz/requests/issues/223, which regards this problem in the context of the requests Python library. The following code makes a data-less POST request to the HTTP sniffer Fiddler running on localhost: import httplib conn = httplib.HTTPConnection("localhost", 8888) conn.request("POST", "/post", "", {}) conn.close() Fiddler reports that it receives the following headers for the POST request, as you can see 'content-length' is not included: POST http://localhost:8888/post HTTP/1.1 Host: localhost:8888 Accept-Encoding: identity ---------- components: Library (Lib) messages: 159915 nosy: Arve.Knudsen priority: normal severity: normal status: open title: httplib doesn't specify content-length header for POST requests without data versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 12:22:04 2012 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 04 May 2012 10:22:04 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336126924.77.0.597495751729.issue14705@psf.upfronthosting.co.za> Eric V. Smith added the comment: The patch looks good to me. Are there any places in the current code base that would use "P"? "p" seems the more useful case. Are you planning on changing existing code to use P or p, or just use it going forward? ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 12:29:26 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 04 May 2012 10:29:26 +0000 Subject: [issue14572] 2.7.3: sqlite module does not build on centos 5 and Mac OS X 10.4 In-Reply-To: <1334354952.88.0.487562486207.issue14572@psf.upfronthosting.co.za> Message-ID: <1336127366.81.0.152716756289.issue14572@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Mac OS X 10.4 is also affected and for the same reason. SQLite builds fine for Python 2.5 and 2.6, but not for 2.7. ---------- nosy: +lemburg title: 2.7.3: sqlite module does not build on centos 5 -> 2.7.3: sqlite module does not build on centos 5 and Mac OS X 10.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 12:38:23 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 04 May 2012 10:38:23 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336127903.09.0.138235110882.issue14705@psf.upfronthosting.co.za> Mark Dickinson added the comment: I also think that 'P' looks too strict to be really useful. I can't think of too many cases where I'd really want to insist on a boolean argument (and reject values of 0 or 1). Maybe implement just 'p' for now and consider 'P' later? ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 12:48:58 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 04 May 2012 10:48:58 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1336128538.63.0.788505490334.issue14127@psf.upfronthosting.co.za> Richard Oudkerk added the comment: There is another problem causing a fatal error in test_posix on Unix. The attached patch fixes it: *ua->path should be decrefed not ua->path. ---------- Added file: http://bugs.python.org/file25452/utime_read_time_arguments.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 12:52:13 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 May 2012 10:52:13 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1336128733.67.0.765378346076.issue14127@psf.upfronthosting.co.za> Larry Hastings added the comment: Looks good to me. You're a core contributor, yes? If not let me know and I'll commit it. Though I must admit I'm baffled how I haven't seen that crash. I've run the unit tests a zillion times on this patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 12:57:09 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 04 May 2012 10:57:09 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1336129029.02.0.986298290374.issue14127@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > Looks good to me. You're a core contributor, yes? If not let me know and > I'll commit it. I will commit. > Though I must admit I'm baffled how I haven't seen that crash. I've run > the unit tests a zillion times on this patch. Were you running test_posix or only test_os? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 13:00:20 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 May 2012 11:00:20 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1336129220.48.0.971129336764.issue14127@psf.upfronthosting.co.za> Larry Hastings added the comment: By "the unit tests" I meant I ran the whole suite: Lib/test/regrtest.py. I know that runs test_os, and I assume it runs test_posix too. I just ran test_posix by hand and it passed. I'm developing on Linux (64-bit) in case that helps. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 13:13:58 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 May 2012 11:13:58 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336130038.65.0.758967815908.issue14705@psf.upfronthosting.co.za> Larry Hastings added the comment: I looked through the Python sources and couldn't find any instances of a function or method with an argument that only allowed you to pass in either True or False. Serily already said he would use 'P' over 'p', although I too am unconvinced that's a good idea. Serily: why would you unhesitatingly prefer 'P' to 'p'? Certainly I see loads of uses for 'p'. For example, when converting code from Python to C that already relied on Python's standard definition of truthiness. I did find some spots that took an object and converted to bool with PyObject_IsTrue, like _json.Encoder(allow_nan) and pickle._Pickler(fix_imports). These too would be well-served by 'p'. I also found some funny in-between cases. For example, stat_float_times and the three-argument form of os.symlink both claim to take a boolean but actually take 'i' (integer). This is relying on bool.__int__(). We certainly couldn't use 'P' here. We could consider switching these to 'p', though in all likelyhood we'll just leave 'em alone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 13:15:54 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 04 May 2012 11:15:54 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1336130154.11.0.586587851353.issue14127@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > I'm developing on Linux (64-bit) in case that helps. I tested it on 32 bit Linux. I have committed it, but I forgot to put the issue number in the commit message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 13:22:40 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 04 May 2012 11:22:40 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1336130560.25.0.00701049830888.issue14127@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Revision 4deb7c1f49b9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 13:44:02 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 04 May 2012 11:44:02 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336131842.48.0.890677009883.issue14705@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think there should be a test case also where PyObject_IsTrue gives an exception (which I think can happen if __bool__ raises an exception). ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 13:45:54 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 May 2012 11:45:54 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336131954.9.0.584067080655.issue14705@psf.upfronthosting.co.za> Larry Hastings added the comment: > I think there should be a test case also where PyObject_IsTrue gives an > exception (which I think can happen if __bool__ raises an exception). I'd be happy to add such a test, but I don't know of any types like that. Can anyone suggest one? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 13:48:22 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 04 May 2012 11:48:22 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1336131954.9.0.584067080655.issue14705@psf.upfronthosting.co.za> Message-ID: <20120504134821.Horde.CNbZBElCcOxPo8IFokCU3JA@webmail.df.eu> Martin v. L?wis added the comment: >> I think there should be a test case also where PyObject_IsTrue gives an >> exception (which I think can happen if __bool__ raises an exception). > > I'd be happy to add such a test, but I don't know of any types like > that. Can anyone suggest one? class NotTrue: def __bool__(self): raise NotImplementedError ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 14:17:06 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 May 2012 12:17:06 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336133826.64.0.304064334823.issue14705@psf.upfronthosting.co.za> Larry Hastings added the comment: Added test forcing a failure for 'p' (and 'P'). This made me have to handle errors a little differently, so it was definitely good to test it. Thanks for the suggestion, Martin! Also changed wording in documentation ever-so-slightly. ---------- Added file: http://bugs.python.org/file25453/larry.parse.tuple.p.and.P.2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 14:28:34 2012 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 04 May 2012 12:28:34 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336134514.24.0.0752833566615.issue14705@psf.upfronthosting.co.za> Eric V. Smith added the comment: Now that I think about this some more, I think I'd structure the 'p' tests as: for expr in [False, None, True, 1, 0]: # add the rest self.assertEqual(bool(expr), getargs_p(expr)) Since the salient point is that 'p' returns the same value as bool(), right? And for the one that raises an exception, you'll have to check that bool and getargs_p both raise the same type of exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 14:48:56 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 May 2012 12:48:56 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1336130038.65.0.758967815908.issue14705@psf.upfronthosting.co.za> Message-ID: <1336135880.2329.32.camel@raxxla> Serhiy Storchaka added the comment: > Serily: why would you unhesitatingly prefer 'P' to 'p'? My name is Serhiy. :) 'P' has the advantage that you can safely backward-compatibly remove the restriction by replacing 'P' on 'p'. :) > I also found some funny in-between cases. This is historical legacy, some still use 1/0 instead True/False. In the end, bool subclasses int. But we have no middlecase for latin 'P'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 14:49:17 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 May 2012 12:49:17 +0000 Subject: [issue14720] sqlite3 microseconds In-Reply-To: <1336113066.83.0.671734474285.issue14720@psf.upfronthosting.co.za> Message-ID: <1336135757.12.0.768500277644.issue14720@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +ghaering versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 14:56:45 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 May 2012 12:56:45 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1336134514.24.0.0752833566615.issue14705@psf.upfronthosting.co.za> Message-ID: <1336136358.2329.36.camel@raxxla> Serhiy Storchaka added the comment: > Since the salient point is that 'p' returns the same value as bool(), right? Yes, and bool_new() is a candidate number one for using new feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 15:00:43 2012 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 04 May 2012 13:00:43 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336136443.69.0.126045561447.issue14705@psf.upfronthosting.co.za> Eric V. Smith added the comment: If bool_new() is going to use 'p', then my suggestion shouldn't be the only test of 'p'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 15:43:18 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 04 May 2012 13:43:18 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336138998.81.0.962683617344.issue14705@psf.upfronthosting.co.za> Mark Dickinson added the comment: In this line in the patch (Python/getargs.c): + if (val == -1 || PyErr_Occurred()) { Isn't that call to PyErr_Occurred() redundant? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 16:21:21 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 04 May 2012 14:21:21 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data In-Reply-To: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> Message-ID: <1336141281.04.0.406091802204.issue14721@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Could you provide a patch? Does this affect 3.x too? ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 16:24:48 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 04 May 2012 14:24:48 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data In-Reply-To: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> Message-ID: <1336141488.88.0.128459390756.issue14721@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> test needed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 16:35:52 2012 From: report at bugs.python.org (Arve Knudsen) Date: Fri, 04 May 2012 14:35:52 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data In-Reply-To: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> Message-ID: <1336142152.08.0.606413968782.issue14721@psf.upfronthosting.co.za> Arve Knudsen added the comment: I can look into patch and 3.x tonight I think. Should I provide a test with an eventual patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 16:37:17 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 May 2012 14:37:17 +0000 Subject: [issue14722] Overflow in parsing 'float' parameters in PyArg_ParseTuple* Message-ID: <1336142237.23.0.0183531993231.issue14722@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : In function convertsimple() in Python/getargs.c possible converting out of float range value from double to float. Fortunately, 'f' format character is not used in CPython source code. But it can be used in the extensions. Tests will be later. ---------- components: Interpreter Core files: getargs_float_overflow.patch keywords: patch messages: 159937 nosy: storchaka priority: normal severity: normal status: open title: Overflow in parsing 'float' parameters in PyArg_ParseTuple* versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25454/getargs_float_overflow.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 16:42:16 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 04 May 2012 14:42:16 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data In-Reply-To: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> Message-ID: <1336142536.98.0.500527818552.issue14721@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Patch with test, please :-). I know it is a pain in the ass, but the result is having a higher quality python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 16:50:01 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 04 May 2012 14:50:01 +0000 Subject: [issue14722] Overflow in parsing 'float' parameters in PyArg_ParseTuple* In-Reply-To: <1336142237.23.0.0183531993231.issue14722@psf.upfronthosting.co.za> Message-ID: <1336143001.99.0.907372219017.issue14722@psf.upfronthosting.co.za> Mark Dickinson added the comment: I don't think this change should be made for 2.7 or 3.2, since it has potential to break existing code. Though technically, conversion of an out-of-range double to a float gives undefined behaviour (C99 6.3.1.5p2), I'm willing to bet that most current compilers just happily return +-infinity in these cases, and there's probably code out there that would break if we changed this. So for 2.7 or 3.2, we could just return +-inf here instead. Though even that isn't quite right if you're picky about corner cases, since there are some values *just* outside [-FLOAT_MAX, FLOAT_MAX] that should still round to +-FLOAT_MAX under round-to-nearest. I suggest leaving this alone for 2.7 and 3.2 For 3.3, it's not clear to me whether it's better to return +-inf or to raise here. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 16:50:17 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 04 May 2012 14:50:17 +0000 Subject: [issue14722] Overflow in parsing 'float' parameters in PyArg_ParseTuple* In-Reply-To: <1336142237.23.0.0183531993231.issue14722@psf.upfronthosting.co.za> Message-ID: <1336143017.99.0.788494432679.issue14722@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 17:04:11 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 04 May 2012 15:04:11 +0000 Subject: [issue14722] Overflow in parsing 'float' parameters in PyArg_ParseTuple* In-Reply-To: <1336142237.23.0.0183531993231.issue14722@psf.upfronthosting.co.za> Message-ID: <1336143851.2.0.825459106529.issue14722@psf.upfronthosting.co.za> Mark Dickinson added the comment: I was just remembering that I was *sure* I'd seen the double->float avoiding undefined behaviour issue mentioned on a C mailing list not so long ago. Turns out that there was a good reason for me remembering that... https://groups.google.com/group/comp.lang.c/browse_thread/thread/5d93cc742025b298 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 17:09:40 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 04 May 2012 15:09:40 +0000 Subject: [issue14722] Overflow in parsing 'float' parameters in PyArg_ParseTuple* In-Reply-To: <1336142237.23.0.0183531993231.issue14722@psf.upfronthosting.co.za> Message-ID: <1336144180.55.0.941278422655.issue14722@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 17:20:49 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 May 2012 15:20:49 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data In-Reply-To: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> Message-ID: <1336144849.97.0.48120408146.issue14721@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +orsenthil stage: test needed -> needs patch versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 17:46:55 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 May 2012 15:46:55 +0000 Subject: [issue14720] sqlite3 microseconds In-Reply-To: <1336113066.83.0.671734474285.issue14720@psf.upfronthosting.co.za> Message-ID: <1336146415.0.0.654301844153.issue14720@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Can be reproduced with: >>> con = sqlite3.connect(":memory:", detect_types=sqlite3.PARSE_DECLTYPES) >>> cur = con.cursor() >>> cur.execute("CREATE TABLE t (x TIMESTAMP)") >>> cur.execute("INSERT INTO t (x) VALUES ('2012-04-04 15:06:00.456')") >>> cur.execute("SELECT * FROM t") >>> cur.fetchall() [(datetime.datetime(2012, 4, 4, 15, 6, 0, 456),)] ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 18:01:07 2012 From: report at bugs.python.org (Piotr Dobrogost) Date: Fri, 04 May 2012 16:01:07 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data In-Reply-To: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> Message-ID: <1336147267.48.0.334200351691.issue14721@psf.upfronthosting.co.za> Piotr Dobrogost added the comment: > Fiddler reports that it receives the following headers for the POST request Python 3.2.3 on Windows Vista 64bit gives the same output for import http.client conn = http.client.HTTPConnection('localhost',8888) conn.request("POST", "/post", "", {}) conn.close() ---------- nosy: +piotr.dobrogost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 18:37:23 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 04 May 2012 16:37:23 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data In-Reply-To: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> Message-ID: <1336149443.0.0.470804686812.issue14721@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 18:38:04 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 04 May 2012 16:38:04 +0000 Subject: [issue14710] pkgutil.get_loader is broken In-Reply-To: <1336041941.32.0.315196686397.issue14710@psf.upfronthosting.co.za> Message-ID: <1336149484.75.0.649852847109.issue14710@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 18:48:11 2012 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 04 May 2012 16:48:11 +0000 Subject: [issue14093] Mercurial version information not appearing in Windows builds In-Reply-To: <1329953826.97.0.233883201006.issue14093@psf.upfronthosting.co.za> Message-ID: <1336150091.09.0.599294017295.issue14093@psf.upfronthosting.co.za> Vinay Sajip added the comment: I'd like to commit this soon. Any chance of a review? It's a very small patch, so it shouldn't need much time. ---------- keywords: +needs review -patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 18:49:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 May 2012 16:49:54 +0000 Subject: [issue14654] Faster utf-8 decoding In-Reply-To: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za> Message-ID: <1336150194.74.0.952631879863.issue14654@psf.upfronthosting.co.za> Antoine Pitrou added the comment: 64-bit Linux, Intel Core i5-2500K CPU @ 3.30GHz: vanilla 3.3 patch 2 patch 3 utf-8 'A'*10000 6931 (+3%) 7115 (+0%) 7117 utf-8 'A'*9999+'\x80' 2347 (+1%) 2410 (-2%) 2360 utf-8 'A'*9999+'\u0100' 2279 (+1%) 2282 (+1%) 2310 utf-8 'A'*9999+'\u8000' 2264 (+2%) 2275 (+1%) 2300 utf-8 'A'*9999+'\U00010000' 2351 (+0%) 2283 (+3%) 2359 utf-8 '\x80'*10000 516 (+8%) 558 (+0%) 559 utf-8 '\x80'+'A'*9999 859 (+0%) 868 (-1%) 860 utf-8 '\x80'*9999+'\u0100' 526 (+6%) 558 (+0%) 558 utf-8 '\x80'*9999+'\u8000' 535 (+4%) 558 (+0%) 558 utf-8 '\x80'*9999+'\U00010000' 525 (+6%) 559 (-0%) 558 utf-8 '\u0100'*10000 517 (+6%) 548 (+0%) 548 utf-8 '\u0100'+'A'*9999 818 (+0%) 820 (+0%) 821 utf-8 '\u0100'+'\x80'*9999 517 (+6%) 548 (+0%) 548 utf-8 '\u0100'*9999+'\u8000' 525 (+4%) 548 (+0%) 548 utf-8 '\u0100'*9999+'\U00010000' 517 (+6%) 549 (+0%) 549 utf-8 '\u8000'*10000 490 (-8%) 433 (+4%) 451 utf-8 '\u8000'+'A'*9999 818 (+0%) 819 (+0%) 821 utf-8 '\u8000'+'\x80'*9999 529 (+4%) 548 (+0%) 548 utf-8 '\u8000'+'\u0100'*9999 529 (+4%) 548 (+0%) 548 utf-8 '\u8000'*9999+'\U00010000' 470 (-4%) 451 (+0%) 451 utf-8 '\U00010000'*10000 554 (-18%) 427 (+6%) 453 utf-8 '\U00010000'+'A'*9999 938 (+0%) 927 (+2%) 941 utf-8 '\U00010000'+'\x80'*9999 572 (+4%) 595 (+0%) 595 utf-8 '\U00010000'+'\u0100'*9999 571 (+4%) 595 (+0%) 595 utf-8 '\U00010000'+'\u8000'*9999 503 (-4%) 481 (+0%) 482 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 18:51:39 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 04 May 2012 16:51:39 +0000 Subject: [issue14703] Update PEP metaprocesses to describe PEP czar role In-Reply-To: <1335836124.46.0.0512543168568.issue14703@psf.upfronthosting.co.za> Message-ID: <1336150299.3.0.336914441152.issue14703@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 18:54:10 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 04 May 2012 16:54:10 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time In-Reply-To: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za> Message-ID: <1336150450.91.0.0723518198003.issue14693@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 18:55:14 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 04 May 2012 16:55:14 +0000 Subject: [issue14093] Mercurial version information not appearing in Windows builds In-Reply-To: <1329953826.97.0.233883201006.issue14093@psf.upfronthosting.co.za> Message-ID: <1336150514.06.0.84839070728.issue14093@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Please go ahead and apply it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 19:23:53 2012 From: report at bugs.python.org (Arve Knudsen) Date: Fri, 04 May 2012 17:23:53 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data In-Reply-To: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> Message-ID: <1336152233.29.0.982685669666.issue14721@psf.upfronthosting.co.za> Arve Knudsen added the comment: Which HTTP methods should we auto-define content-length for? POST and PUT? I noticed that my first attempt at a patch would define content-length also for GET requests, which broke a unit test (test_ipv6host_header). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 19:29:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 May 2012 17:29:13 +0000 Subject: [issue14662] shutil.move doesn't handle ENOTSUP raised by chflags on OS X In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1336152553.9.0.212467045371.issue14662@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looks ok to me, but I don't have a system with os.chflags to test on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 19:34:37 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 May 2012 17:34:37 +0000 Subject: [issue14678] Update zipimport to support importlib.invalidate_caches() In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za> Message-ID: <1336152877.16.0.348012317964.issue14678@psf.upfronthosting.co.za> Brett Cannon added the comment: I should mention I have a version from importers that is probably out-of-date: http://code.google.com/p/importers/source/browse/importers/zip.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 19:34:37 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 May 2012 17:34:37 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1336152877.43.0.0458180409788.issue11618@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I agree that Martin that it's not a good idea to add "dead" code. Furthermore, you patch has: +#ifndef _PY_EMULATED_WIN_CV +#define _PY_EMULATED_WIN_CV 0 /* use emulated condition variables */ +#endif + +#if !defined NTDDI_VISTA || NTDDI_VERSION < NTDDI_VISTA +#undef _PY_EMULATED_WIN_CV +#define _PY_EMULATED_WIN_CV 1 +#endif so am I right to understand that when compiled under Vista or later, it will produce an XP-incompatible binary? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 19:37:16 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 May 2012 17:37:16 +0000 Subject: [issue14711] Remove os.stat_float_times In-Reply-To: <1336051588.91.0.440090520788.issue14711@psf.upfronthosting.co.za> Message-ID: <1336153036.06.0.592136807817.issue14711@psf.upfronthosting.co.za> Antoine Pitrou added the comment: +1 for deprecating. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 19:44:03 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 May 2012 17:44:03 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1336153443.29.0.788203462725.issue2377@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 19:53:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 May 2012 17:53:33 +0000 Subject: [issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http, and urllib In-Reply-To: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za> Message-ID: <1336154013.7.0.481553729541.issue11943@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Quinn, are you planning to work on an updated patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 19:56:09 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 May 2012 17:56:09 +0000 Subject: [issue14722] Overflow in parsing 'float' parameters in PyArg_ParseTuple* In-Reply-To: <1336143001.99.0.907372219017.issue14722@psf.upfronthosting.co.za> Message-ID: <1336154314.2329.57.camel@raxxla> Serhiy Storchaka added the comment: I also thought about ??. But PyLong_AsDouble() raises OverflowError for out-of-range value. And it checks strictly out of ?DBL_MAX. Because float(10**1000) returns no float('inf'), but raises an exception, I think that returning ?? will be wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 20:06:52 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 May 2012 18:06:52 +0000 Subject: [issue14692] json.loads parse_constant callback not working anymore In-Reply-To: <1335695665.87.0.370023915793.issue14692@psf.upfronthosting.co.za> Message-ID: <1336154812.74.0.693435709685.issue14692@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: json.joads parse_constant callback not working anymore -> json.loads parse_constant callback not working anymore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 20:12:08 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 04 May 2012 18:12:08 +0000 Subject: [issue14722] Overflow in parsing 'float' parameters in PyArg_ParseTuple* In-Reply-To: <1336142237.23.0.0183531993231.issue14722@psf.upfronthosting.co.za> Message-ID: <1336155128.66.0.312689622467.issue14722@psf.upfronthosting.co.za> Mark Dickinson added the comment: > And it checks strictly out of ?DBL_MAX. Nope. Values just larger than DBL_MAX won't raise OverflowError here. > Because float(10**1000) returns no float('inf'), but raises an > exception, I think that returning ?? will be wrong. Possibly. But there's also the fact that 3.2 already returns inf here; we'd need a pretty good reason to break that. Like I said, I'm not sure which the right way to go here is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 20:12:09 2012 From: report at bugs.python.org (Arve Knudsen) Date: Fri, 04 May 2012 18:12:09 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data In-Reply-To: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> Message-ID: <1336155129.44.0.547785359326.issue14721@psf.upfronthosting.co.za> Arve Knudsen added the comment: Actually, when inspecting the HTTP requests sent by Chrome for the different methods (a great little Chrome app called Postman let me fire requests manually), I found that content-length would be set for most methods. I could confirm that 'content-length: 0' would be set for the following methods: POST, PUT, PATCH, DELETE and HEAD. I guess it should be good enough to model that behaviour in httplib? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 20:21:12 2012 From: report at bugs.python.org (Mark Theisen) Date: Fri, 04 May 2012 18:21:12 +0000 Subject: [issue14723] Misleading error message for str.format() Message-ID: <1336155672.66.0.579561581196.issue14723@psf.upfronthosting.co.za> New submission from Mark Theisen : When I run this code: '{0:i}'.format(None) I get this error: ValueError: Unknown format code 'i' for object of type 'str' This seems misleading because None is of Type 'NoneType'. I was expecting the error to say something to the effect of: Unknown format code 'i' for object of type 'NoneType' ---------- components: Interpreter Core messages: 159955 nosy: theisenm priority: normal severity: normal status: open title: Misleading error message for str.format() type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 20:22:00 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 May 2012 18:22:00 +0000 Subject: [issue14701] parser module doesn't support 'raise ... from' In-Reply-To: <1335812123.91.0.810471517196.issue14701@psf.upfronthosting.co.za> Message-ID: <1336155720.62.0.718622000943.issue14701@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Just curious, should "The parser module provides an interface to Python?s internal parser and byte-code compiler." say "CPython's"? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 20:25:14 2012 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 04 May 2012 18:25:14 +0000 Subject: [issue14723] Misleading error message for str.format() In-Reply-To: <1336155672.66.0.579561581196.issue14723@psf.upfronthosting.co.za> Message-ID: <1336155914.93.0.35029148165.issue14723@psf.upfronthosting.co.za> Eric V. Smith added the comment: This is a duplicate of issue 13790. See the comments there for why it works this way. ---------- nosy: +eric.smith resolution: -> duplicate status: open -> closed superseder: -> In str.format an incorrect error message for list, tuple, dict, set _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 20:25:57 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 04 May 2012 18:25:57 +0000 Subject: [issue14701] parser module doesn't support 'raise ... from' In-Reply-To: <1335812123.91.0.810471517196.issue14701@psf.upfronthosting.co.za> Message-ID: <1336155957.35.0.869281729011.issue14701@psf.upfronthosting.co.za> Mark Dickinson added the comment: Hmm. Possibly, yes. At least, it should be clear somehow from the docs that the parser, symbol, token and ast modules are CPython specific. (And possibly tokenize, too.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 20:29:11 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 04 May 2012 18:29:11 +0000 Subject: [issue13790] In str.format an incorrect error message for list, tuple, dict, set In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za> Message-ID: <1336156151.0.0.844115462287.issue13790@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 21:12:29 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 04 May 2012 19:12:29 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data In-Reply-To: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> Message-ID: <1336158749.61.0.941509945857.issue14721@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: HEAD?. It doesn't make sense in HEAD if it doesn't make sense in GET. Looking around, I found this, to mud the water a little bit more: . Not being explicit about this is a "bug" in the specification, I think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 21:20:49 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 May 2012 19:20:49 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 257cbd2fac38 by Brett Cannon in branch 'default': Issue #13959: Re-implement imp.get_suffixes() in Lib/imp.py. http://hg.python.org/cpython/rev/257cbd2fac38 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 21:20:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 May 2012 19:20:50 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 257cbd2fac38 by Brett Cannon in branch 'default': Issue #13959: Re-implement imp.get_suffixes() in Lib/imp.py. http://hg.python.org/cpython/rev/257cbd2fac38 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 21:23:40 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 May 2012 19:23:40 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1336159420.67.0.942088110266.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, I'm waiting on issue #14657 (avoiding the _frozen_importlib/importlib dichotomy) is resolved before I document the new imp.extension_suffixes() as it would be good to know where I should pull in the source and bytecode suffixes. I think this only leaves get_magic() and get_tag() as the only things to move + trying to figure out how to handle PyImport_ExecCodeModuleObject() and its grip on various bits of C code. ---------- dependencies: +Avoid two importlib copies _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 21:29:50 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 May 2012 19:29:50 +0000 Subject: [issue14722] Overflow in parsing 'float' parameters in PyArg_ParseTuple* In-Reply-To: <1336155128.66.0.312689622467.issue14722@psf.upfronthosting.co.za> Message-ID: <1336159938.2329.69.camel@raxxla> Serhiy Storchaka added the comment: Here is a patch with tests. > Nope. Values just larger than DBL_MAX won't raise OverflowError here. Isn't that a little bit. But values that rounded to DBL_MAX can raise OverflowError. In any case it's too difficult to achieve strict behavior in this corner case. > Possibly. But there's also the fact that 3.2 already returns inf here; we'd need a pretty good reason to break that. In the end, we may add the environment variable PYTHONDONTRAISEEXCEPTIONIFFLOATOVERFLOWS to control this behaviour. > Like I said, I'm not sure which the right way to go here is. Take a look at the tests and may be you'll see the system. ---------- Added file: http://bugs.python.org/file25455/getargs_float_overflow_2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 01824bf55376 Lib/test/test_getargs2.py --- a/Lib/test/test_getargs2.py Fri May 04 11:06:09 2012 -0400 +++ b/Lib/test/test_getargs2.py Fri May 04 22:07:37 2012 +0300 @@ -1,4 +1,5 @@ import unittest +import math from test import support from _testcapi import getargs_keywords, getargs_keyword_only @@ -22,6 +23,9 @@ > K * unsigned long long none > L long long LLONG_MIN..LLONG_MAX +> f float -FLT_MAX..FLT_MAX +> d double -DBL_MAX..DBL_MAX + > Notes: > > * New format codes. @@ -39,17 +43,25 @@ from _testcapi import UCHAR_MAX, USHRT_MAX, UINT_MAX, ULONG_MAX, INT_MAX, \ INT_MIN, LONG_MIN, LONG_MAX, PY_SSIZE_T_MIN, PY_SSIZE_T_MAX, \ - SHRT_MIN, SHRT_MAX + SHRT_MIN, SHRT_MAX, \ + FLT_MAX, FLT_EPSILON, DBL_MAX, DBL_EPSILON # fake, they are not defined in Python's header files LLONG_MAX = 2**63-1 LLONG_MIN = -2**63 ULLONG_MAX = 2**64-1 +INF = float('inf') +NAN = float('nan') + class Int: def __int__(self): return 99 +class Float: + def __float__(self): + return 34.125 + class Unsigned_TestCase(unittest.TestCase): def test_b(self): from _testcapi import getargs_b @@ -215,6 +227,50 @@ self.assertEqual(VERY_LARGE & ULLONG_MAX, getargs_K(VERY_LARGE)) +class Float_TestCase(unittest.TestCase): + def test_f(self): + from _testcapi import getargs_f + # f returns 'float', and does range checking (-FLT_MAX ... FLT_MAX) + self.assertRaises(TypeError, getargs_f, "Hello") + self.assertEqual(34.125, getargs_f(Float())) + + self.assertRaises(OverflowError, getargs_f, -int(FLT_MAX) - int(FLT_MAX*FLT_EPSILON)) + self.assertEqual(FLT_MAX, getargs_f(FLT_MAX)) + self.assertEqual(-FLT_MAX, getargs_f(-FLT_MAX)) + self.assertRaises(OverflowError, getargs_f, int(FLT_MAX) + int(FLT_MAX*FLT_EPSILON)) + if -FLT_MAX != -FLT_MAX - FLT_MAX*FLT_EPSILON: + self.assertRaises(OverflowError, getargs_f, -FLT_MAX - FLT_MAX*FLT_EPSILON) + if FLT_MAX != FLT_MAX + FLT_MAX*FLT_EPSILON: + self.assertRaises(OverflowError, getargs_f, FLT_MAX + FLT_MAX*FLT_EPSILON) + + self.assertEqual(0, getargs_f(0)) + self.assertEqual(34.125, getargs_f(34.125)) + self.assertRaises(OverflowError, getargs_f, 10**1000) + + self.assertEqual(INF, getargs_f(INF)) + self.assertEqual(-INF, getargs_f(-INF)) + self.assertTrue(math.isnan(getargs_f(NAN))) + + def test_d(self): + from _testcapi import getargs_d + # d returns 'double', and does range checking (-DBL_MAX ... DBL_MAX) + self.assertRaises(TypeError, getargs_d, "Hello") + self.assertEqual(34.125, getargs_d(Float())) + + self.assertRaises(OverflowError, getargs_d, -int(DBL_MAX) - int(DBL_MAX*DBL_EPSILON)) + self.assertEqual(DBL_MAX, getargs_d(DBL_MAX)) + self.assertEqual(-DBL_MAX, getargs_d(-DBL_MAX)) + self.assertRaises(OverflowError, getargs_d, int(DBL_MAX) + int(DBL_MAX*DBL_EPSILON)) + + self.assertEqual(0, getargs_d(0)) + self.assertEqual(34.125, getargs_d(34.125)) + self.assertRaises(OverflowError, getargs_d, 10**1000) + + self.assertEqual(INF, getargs_d(INF)) + self.assertEqual(-INF, getargs_d(-INF)) + self.assertTrue(math.isnan(getargs_d(NAN))) + + class Tuple_TestCase(unittest.TestCase): def test_tuple(self): from _testcapi import getargs_tuple @@ -510,6 +566,7 @@ tests = [ Signed_TestCase, Unsigned_TestCase, + Float_TestCase, Tuple_TestCase, Keywords_TestCase, KeywordOnly_TestCase, diff -r 01824bf55376 Modules/_testcapimodule.c --- a/Modules/_testcapimodule.c Fri May 04 11:06:09 2012 -0400 +++ b/Modules/_testcapimodule.c Fri May 04 22:07:37 2012 +0300 @@ -992,6 +992,24 @@ } static PyObject * +getargs_f(PyObject *self, PyObject *args) +{ + float value; + if (!PyArg_ParseTuple(args, "f", &value)) + return NULL; + return PyFloat_FromDouble(value); +} + +static PyObject * +getargs_d(PyObject *self, PyObject *args) +{ + double value; + if (!PyArg_ParseTuple(args, "d", &value)) + return NULL; + return PyFloat_FromDouble(value); +} + +static PyObject * getargs_c(PyObject *self, PyObject *args) { char c; @@ -2447,6 +2465,8 @@ (PyCFunction)test_long_long_and_overflow, METH_NOARGS}, {"test_L_code", (PyCFunction)test_L_code, METH_NOARGS}, #endif + {"getargs_f", getargs_f, METH_VARARGS}, + {"getargs_d", getargs_d, METH_VARARGS}, {"getargs_c", getargs_c, METH_VARARGS}, {"getargs_s", getargs_s, METH_VARARGS}, {"getargs_s_star", getargs_s_star, METH_VARARGS}, @@ -2698,8 +2718,10 @@ PyModule_AddObject(m, "ULONG_MAX", PyLong_FromUnsignedLong(ULONG_MAX)); PyModule_AddObject(m, "FLT_MAX", PyFloat_FromDouble(FLT_MAX)); PyModule_AddObject(m, "FLT_MIN", PyFloat_FromDouble(FLT_MIN)); + PyModule_AddObject(m, "FLT_EPSILON", PyFloat_FromDouble(FLT_EPSILON)); PyModule_AddObject(m, "DBL_MAX", PyFloat_FromDouble(DBL_MAX)); PyModule_AddObject(m, "DBL_MIN", PyFloat_FromDouble(DBL_MIN)); + PyModule_AddObject(m, "DBL_EPSILON", PyFloat_FromDouble(DBL_EPSILON)); PyModule_AddObject(m, "LLONG_MAX", PyLong_FromLongLong(PY_LLONG_MAX)); PyModule_AddObject(m, "LLONG_MIN", PyLong_FromLongLong(PY_LLONG_MIN)); PyModule_AddObject(m, "ULLONG_MAX", PyLong_FromUnsignedLongLong(PY_ULLONG_MAX)); diff -r 01824bf55376 Python/getargs.c --- a/Python/getargs.c Fri May 04 11:06:09 2012 -0400 +++ b/Python/getargs.c Fri May 04 22:07:37 2012 +0300 @@ -4,6 +4,7 @@ #include "Python.h" #include +#include #ifdef __cplusplus @@ -757,8 +758,19 @@ double dval = PyFloat_AsDouble(arg); if (PyErr_Occurred()) RETURN_ERR_OCCURRED; - else - *p = (float) dval; + if (Py_IS_FINITE(dval)) { + if (dval < -FLT_MAX) { + PyErr_SetString(PyExc_OverflowError, + "float is less than minimum"); + RETURN_ERR_OCCURRED; + } + else if (dval > FLT_MAX) { + PyErr_SetString(PyExc_OverflowError, + "float is greater than maximum"); + RETURN_ERR_OCCURRED; + } + } + *p = (float) dval; break; } From report at bugs.python.org Fri May 4 21:31:07 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 May 2012 19:31:07 +0000 Subject: [issue14722] Overflow in parsing 'float' parameters in PyArg_ParseTuple* In-Reply-To: <1336142237.23.0.0183531993231.issue14722@psf.upfronthosting.co.za> Message-ID: <1336159867.26.0.266797295812.issue14722@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- type: -> enhancement versions: -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 21:34:10 2012 From: report at bugs.python.org (Arve Knudsen) Date: Fri, 04 May 2012 19:34:10 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data In-Reply-To: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> Message-ID: <1336160050.09.0.527178059591.issue14721@psf.upfronthosting.co.za> Arve Knudsen added the comment: Here's my initial proposal for a patch against httplib, based on the 2.7 branch of cpython repository. I've included a couple of tests, which check that when content is empty, content-length is set to 0 for certain methods (POST/PUT etc) and not specified for others. ---------- keywords: +patch Added file: http://bugs.python.org/file25456/httplib-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 21:34:55 2012 From: report at bugs.python.org (Arve Knudsen) Date: Fri, 04 May 2012 19:34:55 +0000 Subject: [issue14721] httplib doesn't specify content-length header for POST requests without data In-Reply-To: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za> Message-ID: <1336160095.3.0.401759257464.issue14721@psf.upfronthosting.co.za> Arve Knudsen added the comment: Yes, I agree it doesn't make much sense for HEAD AFAICT, but Chrome does it. Maybe there's a reason? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 21:39:34 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 04 May 2012 19:39:34 +0000 Subject: [issue14722] Overflow in parsing 'float' parameters in PyArg_ParseTuple* In-Reply-To: <1336142237.23.0.0183531993231.issue14722@psf.upfronthosting.co.za> Message-ID: <1336160374.25.0.0230621275131.issue14722@psf.upfronthosting.co.za> Mark Dickinson added the comment: > But values that rounded to DBL_MAX can raise > OverflowError. In any case it's too difficult to achieve strict behavior > in this corner case. Well, PyLong_AsDouble *does* achieve strict behaviour in this corner case :-). Integers less than 0.5 * (sys.float_info.max + 2**1024) in absolute value give finite results; integers greater than or equal to that bound produce an OverflowError. > Take a look at the tests and may be you'll see the system. I don't see how looking at the tests helps with making a decision about breaking backwards compatibility or not. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 21:52:07 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 May 2012 19:52:07 +0000 Subject: [issue14093] Mercurial version information not appearing in Windows builds In-Reply-To: <1329953826.97.0.233883201006.issue14093@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 4459d82ff127 by Vinay Sajip in branch 'default': Closes #14093: Added Mercurial version information to Windows builds. http://hg.python.org/cpython/rev/4459d82ff127 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 22:07:33 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 May 2012 20:07:33 +0000 Subject: [issue14578] importlib doesn't check Windows registry for paths In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za> Message-ID: <1336162053.74.0.608588914076.issue14578@psf.upfronthosting.co.za> Brett Cannon added the comment: FYI, I just deleted PC/import_nt.c as it stopped compiling after my removal of _imp.get_suffixes(). Obviously hg has the history of the file so if someone needs to resurrect it there shouldn't be much issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 22:13:36 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 May 2012 20:13:36 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 22b0689346f9 by Brett Cannon in branch 'default': Issue #13959: Move module type constants to Lib/imp.py. http://hg.python.org/cpython/rev/22b0689346f9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 22:17:39 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 04 May 2012 20:17:39 +0000 Subject: [issue14662] shutil.move doesn't handle ENOTSUP raised by chflags on OS X In-Reply-To: <1336152553.9.0.212467045371.issue14662@psf.upfronthosting.co.za> Message-ID: <801F69F2-84A2-4FC1-80EE-48DC814048C8@acm.org> Ned Deily added the comment: I will test and check it in next week if still open. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 22:48:31 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 May 2012 20:48:31 +0000 Subject: [issue14724] kill imp.load_dynamic's third argument Message-ID: <1336164511.78.0.519044801225.issue14724@psf.upfronthosting.co.za> New submission from Antoine Pitrou : imp.load_dynamic's third optional argument doesn't seem used in the wild, and I don't think it's correctly implemented by the current code. It would seem reasonable to kill it. ---------- components: Interpreter Core, Library (Lib) messages: 159971 nosy: brett.cannon, eric.smith, ncoghlan, pitrou priority: normal severity: normal status: open title: kill imp.load_dynamic's third argument versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 4 22:49:42 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 May 2012 20:49:42 +0000 Subject: [issue14724] kill imp.load_dynamic's third argument In-Reply-To: <1336164511.78.0.519044801225.issue14724@psf.upfronthosting.co.za> Message-ID: <1336164582.35.0.223921721003.issue14724@psf.upfronthosting.co.za> Brett Cannon added the comment: +1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 00:54:01 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 04 May 2012 22:54:01 +0000 Subject: [issue14725] test_multiprocessing failure under Windows Message-ID: <1336172041.91.0.79006187387.issue14725@psf.upfronthosting.co.za> New submission from Antoine Pitrou : There was this failure on one of the XP buildbots: Process Process-269: Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\process.py", line 258, in _bootstrap self.run() File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\process.py", line 95, in run self._target(*self._args, **self._kwargs) File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_multiprocessing.py", line 1980, in _listener new_conn = l.accept() File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 444, in accept c = self._listener.accept() File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 624, in accept ov = _winapi.ConnectNamedPipe(handle, overlapped=True) BrokenPipeError: [Error 232] The pipe is being closed ====================================================================== ERROR: test_pickling (test.test_multiprocessing.WithProcessesTestPicklingConnections) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 308, in _recv_bytes nread, err = ov.GetOverlappedResult(True) BrokenPipeError: [Error 109] The pipe has been ended During handling of the above exception, another exception occurred: Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_multiprocessing.py", line 2030, in test_pickling new_conn = lconn.recv() File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 252, in recv buf = self._recv_bytes() File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 317, in _recv_bytes raise EOFError EOFError (http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6534/steps/test/logs/stdio) ---------- components: Library (Lib), Tests, Windows messages: 159973 nosy: pitrou, sbt priority: normal severity: normal status: open title: test_multiprocessing failure under Windows type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 03:14:08 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 05 May 2012 01:14:08 +0000 Subject: [issue14726] Lib/email/*.py use an EMPTYSTRING global instead of '' Message-ID: <1336180448.33.0.0155133571187.issue14726@psf.upfronthosting.co.za> New submission from Gregory P. Smith : Lib/email/*.py are fond of using EMPTYSTRING = '' and within the code: EMPTYSTRING.join(...) instead of just writing: ''.join(...) They should just do the latter. It'll avoid a name lookup and look less silly to people reading the code. ;) ---------- messages: 159974 nosy: gregory.p.smith priority: low severity: normal status: open title: Lib/email/*.py use an EMPTYSTRING global instead of '' versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 03:25:42 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 05 May 2012 01:25:42 +0000 Subject: [issue14726] Lib/email/*.py use an EMPTYSTRING global instead of '' In-Reply-To: <1336180448.33.0.0155133571187.issue14726@psf.upfronthosting.co.za> Message-ID: <1336181142.04.0.0638412772012.issue14726@psf.upfronthosting.co.za> R. David Murray added the comment: I've always wondered why the code did that. If Barry doesn't have a good reason for it, I'll refactor it at some point. ---------- assignee: -> r.david.murray nosy: +barry, r.david.murray type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 03:41:05 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 05 May 2012 01:41:05 +0000 Subject: [issue14695] Tools/parser/unparse.py is out of date. In-Reply-To: <1335728674.11.0.179577366721.issue14695@psf.upfronthosting.co.za> Message-ID: <1336182065.5.0.0370804375657.issue14695@psf.upfronthosting.co.za> R. David Murray added the comment: There is a test_tools file now. test_unparse could be called from it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 03:45:53 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 05 May 2012 01:45:53 +0000 Subject: [issue14702] os.makedirs breaks under autofs directories In-Reply-To: <1335813257.88.0.458381281199.issue14702@psf.upfronthosting.co.za> Message-ID: <1336182353.87.0.608182579305.issue14702@psf.upfronthosting.co.za> R. David Murray added the comment: Hynek: it doesn't seem like that would work, since legitimate EPERM errors are much more likely. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 07:15:54 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 05 May 2012 05:15:54 +0000 Subject: [issue14726] Lib/email/*.py use an EMPTYSTRING global instead of '' In-Reply-To: <1336181142.04.0.0638412772012.issue14726@psf.upfronthosting.co.za> Message-ID: <20120505011542.781c9608@resist.wooz.org> Barry A. Warsaw added the comment: On May 05, 2012, at 01:25 AM, R. David Murray wrote: >I've always wondered why the code did that. If Barry doesn't have a good >reason for it, I'll refactor it at some point. A long time ago, Tim (IIRC) expressed an opinion that using the variable makes the code more readable. After having seen so much code that uses the string literals over the years, I wholeheartedly agree with that opinion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 08:51:02 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 05 May 2012 06:51:02 +0000 Subject: [issue14678] Update zipimport to support importlib.invalidate_caches() In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za> Message-ID: <1336200662.56.0.74624572612.issue14678@psf.upfronthosting.co.za> Nick Coghlan added the comment: Moving zipimporter to Python code is harder than it sounds: we don't want to break the ability to ship the standard library itself inside a zipfile. If you try to move zipimporter to pure Python, you could easily end up with a *very* ugly bootstrapping problem, on par with that already encountered when hacking on importlib._bootstrap. In fact, the path of least resistance here might actually be to implement zipimporter directly *in* importlib._bootstrap. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 10:23:50 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 05 May 2012 08:23:50 +0000 Subject: [issue14702] os.makedirs breaks under autofs directories In-Reply-To: <1335813257.88.0.458381281199.issue14702@psf.upfronthosting.co.za> Message-ID: <1336206230.75.0.644098873528.issue14702@psf.upfronthosting.co.za> Hynek Schlawack added the comment: David: What do you mean? I'd just catch EPERM and look whether the directory "appeared" in the meantime. If it exists, continue. If not: re-raise. Am I missing something? I may have a look at GNU mkdir if it doesn't help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 11:13:35 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 05 May 2012 09:13:35 +0000 Subject: [issue14727] test_multiprocessing failure under Linux Message-ID: <1336209215.05.0.989780505108.issue14727@psf.upfronthosting.co.za> New submission from Vinay Sajip : I've recently started seeing this failure repeatably on Linux (Ubuntu Jaunty): [195/364] test_multiprocessing Process Process-133: Traceback (most recent call last): File "/home/vinay/projects/python/default/Lib/multiprocessing/process.py", line 258, in _bootstrap self.run() File "/home/vinay/projects/python/default/Lib/multiprocessing/process.py", line 95, in run self._target(*self._args, **self._kwargs) File "/home/vinay/projects/python/default/Lib/test/test_multiprocessing.py", line 2005, in _remote client.connect(address) ConnectionRefusedError: [Errno 111] Connection refused /home/vinay/projects/python/default/Lib/multiprocessing/process.py:274: ResourceWarning: unclosed traceback.print_exc() ---------- components: Tests messages: 159981 nosy: sbt, vinay.sajip priority: normal severity: normal status: open title: test_multiprocessing failure under Linux type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 11:35:44 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 05 May 2012 09:35:44 +0000 Subject: [issue9116] test_capi.test_no_FatalError_infinite_loop crash on Windows In-Reply-To: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za> Message-ID: <1336210544.81.0.912722118226.issue9116@psf.upfronthosting.co.za> Vinay Sajip added the comment: The AssertionError in Brian's initial post indicates that the test is too restrictive. Though the discussion here has talked about removing the popups altogether, the test passes on Windows with a small change: instead of assertEqual(), I used self.assertTrue(err.rstrip().startswith( b'Fatal Python error:' b' PyThreadState_Get: no current thread')) Patch attached. As this seems to be a sufficiently specific test, but not too specific, I'd like to apply this patch soon, unless someone thinks the test needs to stay exactly like it is. ---------- nosy: +vinay.sajip Added file: http://bugs.python.org/file25457/test_capi.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 12:01:11 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sat, 05 May 2012 10:01:11 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1336212071.37.0.312595087068.issue14684@psf.upfronthosting.co.za> Changes by Nadeem Vawda : ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 12:05:14 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 05 May 2012 10:05:14 +0000 Subject: [issue14702] os.makedirs breaks under autofs directories In-Reply-To: <1335813257.88.0.458381281199.issue14702@psf.upfronthosting.co.za> Message-ID: <1336212314.44.0.796951663159.issue14702@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: To me, this doesn't look like a os.makedirs() bug, but rather an autofs one (didn't know it was still in use). I don't like the idea of adding such a kludge (i.e. catching EPERM and checking whether the directory appeared in between). Could you please provide an strace output of both "os.makedirs()" and "mkdir -p"? Thanks. ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 12:30:57 2012 From: report at bugs.python.org (Sandro Tosi) Date: Sat, 05 May 2012 10:30:57 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1336213857.01.0.889835731026.issue14468@psf.upfronthosting.co.za> Sandro Tosi added the comment: Here's the proposed patch. I'm sorry but probably 'hg diff' went too wild, and since I moved the "Using several working copies" as the first sub-paragraph of "Forward-Porting" it seems it got confused, so the diff is not so clean. I've also changed quite some part of "Porting Within *" sections - please look at them carefully since it's not that evident. A brief list is: - change in commands to reflect the multi-clone setup - add of "Assuming all your clones are in the same directory" - add of "The import is possible..." sentence ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file25458/issue14468.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 12:43:45 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 05 May 2012 10:43:45 +0000 Subject: [issue14728] trace function not set, causing some Pdb commands to fail Message-ID: <1336214625.48.0.950841547459.issue14728@psf.upfronthosting.co.za> New submission from Xavier de Gaye : The issue 13183 raises the problem that when the trace function is not set in the caller frame, the step command fails at a return statement. This new issue raises the point that, for the same reason: * the next, until and return statements fail also at a return statement when the caller frame does not have a trace function * when the user runs the up and down commands at any line in a frame to select a new frame, then the next, until or return commands fail when the selected frame does not have a trace function The attached patch fixes all those problems (by first removing the changes made in bdb.py at issue 13183). After the patch, the implementation ensures now that self.stopframe is either None, or belongs to the stack frame in the interval [self.botframe, self._curframe] and that it is set to self.botframe when the debugging session terminates. This allows removing the while loop in stop_here with an improvement in the performance of Pdb (since stop_here may be called at each line, even when no breakpoint is set in the function). The patch applies to the default branch and includes 5 new test cases. A patch for 2.7 will be submitted later. ---------- components: Library (Lib) files: pdb.patch keywords: patch messages: 159985 nosy: xdegaye priority: normal severity: normal status: open title: trace function not set, causing some Pdb commands to fail type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25459/pdb.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 12:44:35 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 05 May 2012 10:44:35 +0000 Subject: [issue14729] test_faulthandler test is too specific to work on Windows Message-ID: <1336214675.26.0.0531566496861.issue14729@psf.upfronthosting.co.za> New submission from Vinay Sajip : In test_faulthandler.test_check_fatal_error, the test expects a response which matches """ ^Fatal Python error: {name} {header}: File "", line {lineno} in $ """.strip() On Windows, some more information is appended to the end of the message, so the match fails because of the trailing $. I propose to remove this $, so that the match succeeds just on the basis of the prefix. Patch attached; I'll apply it soon, assuming you don't object. ---------- components: Tests files: test_faulthandler.diff keywords: patch messages: 159986 nosy: haypo, vinay.sajip priority: normal severity: normal status: open title: test_faulthandler test is too specific to work on Windows versions: Python 3.3 Added file: http://bugs.python.org/file25460/test_faulthandler.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 12:50:26 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 05 May 2012 10:50:26 +0000 Subject: [issue14727] test_multiprocessing failure under Linux In-Reply-To: <1336209215.05.0.989780505108.issue14727@psf.upfronthosting.co.za> Message-ID: <1336215026.48.0.444758388163.issue14727@psf.upfronthosting.co.za> Vinay Sajip added the comment: Some more information: after the above-described appears, the test hangs. When interrupted with a Ctrl+C, this is displayed: ^CProcess PoolWorker-104: Process PoolWorker-102: Process PoolWorker-105:1: Process PoolWorker-101: Process PoolWorker-105:4: Process PoolWorker-105:3: Process PoolWorker-105:2: Process PoolWorker-103: Traceback (most recent call last): File "/home/vinay/projects/python/default/Lib/multiprocessing/process.py", line 258, in _bootstrap Traceback (most recent call last): File "/home/vinay/projects/python/default/Lib/multiprocessing/process.py", line 258, in _bootstrap Traceback (most recent call last): File "/home/vinay/projects/python/default/Lib/multiprocessing/process.py", line 258, in _bootstrap Traceback (most recent call last): File "/home/vinay/projects/python/default/Lib/multiprocessing/process.py", line 258, in _bootstrap Traceback (most recent call last): File "/home/vinay/projects/python/default/Lib/multiprocessing/process.py", line 258, in _bootstrap Traceback (most recent call last): File "/home/vinay/projects/python/default/Lib/multiprocessing/process.py", line 258, in _bootstrap Traceback (most recent call last): File "/home/vinay/projects/python/default/Lib/multiprocessing/process.py", line 258, in _bootstrap Traceback (most recent call last): File "/home/vinay/projects/python/default/Lib/multiprocessing/process.py", line 258, in _bootstrap Process Process-132: Traceback (most recent call last): File "/home/vinay/projects/python/default/Lib/multiprocessing/process.py", line 258, in _bootstrap Warning -- threading._dangling was modified by test_multiprocessing Warning -- multiprocessing.process._dangling was modified by test_multiprocessing self.run() File "/home/vinay/projects/python/default/Lib/multiprocessing/process.py", line 95, in run self._target(*self._args, **self._kwargs) File "/home/vinay/projects/python/default/Lib/test/test_multiprocessing.py", line 1989, in _listener new_conn, addr = l.accept() File "/home/vinay/projects/python/default/Lib/socket.py", line 135, in accept fd, addr = self._accept() KeyboardInterrupt /home/vinay/projects/python/default/Lib/multiprocessing/process.py:274: ResourceWarning: unclosed traceback.print_exc() test test_multiprocessing crashed -- Traceback (most recent call last): File "/home/vinay/projects/python/default/Lib/test/test_multiprocessing.py", line 2825, in test_main run(suite) File "/home/vinay/projects/python/default/Lib/test/support.py", line 1407, in run_unittest _run_suite(suite) File "/home/vinay/projects/python/default/Lib/test/support.py", line 1373, in _run_suite result = runner.run(suite) File "/home/vinay/projects/python/default/Lib/test/support.py", line 1272, in run test(result) File "/home/vinay/projects/python/default/Lib/unittest/suite.py", line 67, in __call__ return self.run(*args, **kwds) File "/home/vinay/projects/python/default/Lib/unittest/suite.py", line 105, in run test(result) File "/home/vinay/projects/python/default/Lib/unittest/suite.py", line 67, in __call__ return self.run(*args, **kwds) File "/home/vinay/projects/python/default/Lib/unittest/suite.py", line 105, in run test(result) File "/home/vinay/projects/python/default/Lib/unittest/suite.py", line 67, in __call__ return self.run(*args, **kwds) File "/home/vinay/projects/python/default/Lib/unittest/suite.py", line 105, in run test(result) File "/home/vinay/projects/python/default/Lib/unittest/case.py", line 492, in __call__ return self.run(*args, **kwds) File "/home/vinay/projects/python/default/Lib/unittest/case.py", line 440, in run self._executeTestPart(testMethod, outcome, isTest=True) File "/home/vinay/projects/python/default/Lib/unittest/case.py", line 385, in _executeTestPart function() File "/home/vinay/projects/python/default/Lib/test/test_multiprocessing.py", line 2038, in test_pickling new_conn = lconn.recv() File "/home/vinay/projects/python/default/Lib/multiprocessing/connection.py", line 252, in recv buf = self._recv_bytes() File "/home/vinay/projects/python/default/Lib/multiprocessing/connection.py", line 398, in _recv_bytes buf = self._recv(4) File "/home/vinay/projects/python/default/Lib/multiprocessing/connection.py", line 377, in _recv chunk = read(handle, remaining) KeyboardInterrupt During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/vinay/projects/python/default/Lib/multiprocessing/managers.py", line 729, in _callmethod conn = self._tls.connection AttributeError: 'ForkAwareLocal' object has no attribute 'connection' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "Lib/test/regrtest.py", line 1237, in runtest_inner File "/home/vinay/projects/python/default/Lib/test/test_multiprocessing.py", line 2829, in test_main ManagerMixin.pool.terminate() File "", line 2, in terminate File "/home/vinay/projects/python/default/Lib/multiprocessing/managers.py", line 733, in _callmethod self._connect() File "/home/vinay/projects/python/default/Lib/multiprocessing/managers.py", line 720, in _connect conn = self._Client(self._token.address, authkey=self._authkey) File "/home/vinay/projects/python/default/Lib/multiprocessing/connection.py", line 469, in Client c = SocketClient(address) File "/home/vinay/projects/python/default/Lib/multiprocessing/connection.py", line 585, in SocketClient s.connect(address) FileNotFoundError: [Errno 2] No such file or directory ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 13:37:24 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 05 May 2012 11:37:24 +0000 Subject: [issue14702] os.makedirs breaks under autofs directories In-Reply-To: <1335813257.88.0.458381281199.issue14702@psf.upfronthosting.co.za> Message-ID: <1336217844.67.0.859101600566.issue14702@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Charles, I don't think you can blame autofs here. The problem at hand is that makedirs() never checks whether the directory exists (that would trigger the mount too I presume). Instead, it tries a mkdir and looks if it gets an EEXIST. If you try that approach in this case where /net is non-writable and /net/prodigy appears only on demand, it fails with an EPERM instead. Have a look at http://hg.python.org/cpython/file/8215aaccc9dd/Lib/os.py#l136 especially line 151. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 15:24:31 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 05 May 2012 13:24:31 +0000 Subject: [issue14726] Lib/email/*.py use an EMPTYSTRING global instead of '' In-Reply-To: <1336180448.33.0.0155133571187.issue14726@psf.upfronthosting.co.za> Message-ID: <1336224271.06.0.97643988319.issue14726@psf.upfronthosting.co.za> R. David Murray added the comment: Good enough for me. I personally don't find it to be easier or harder to read with the names, so let's keep them. ---------- resolution: -> works for me stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 15:27:30 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 05 May 2012 13:27:30 +0000 Subject: [issue14702] os.makedirs breaks under autofs directories In-Reply-To: <1336217844.67.0.859101600566.issue14702@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Charles, I don't think you can blame autofs here. The problem at hand is that makedirs() never checks whether the directory exists (that would trigger the mount too I presume). Yes, it does. Have a look at line 148: """ if head and tail and not path.exists(head): """ > Instead, it tries a mkdir and looks if it gets an EEXIST. Actually, EEXIST is just caught to cope with race conditions (i.e. the directory got created in between, TOCTTOU race). > If you try that approach in this case where /net is non-writable and /net/prodigy appears only on demand, it fails with an EPERM instead. Actually, no. makedirs() does a recursive depth-first traversal: makedirs('/net/prodigy/foo') will actually do something like: """ stat('/net/prodigy/foo') == ENOENT stat('/net/prodigy') == ENONENT mkdir('/net/prodigy') == EPERM """ The NFS mount should appear upon the first - or second - stat() call, before mkdir(). But I'd like to be sure about that, that's why I think an strace() output would be useful ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 15:30:33 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 05 May 2012 13:30:33 +0000 Subject: [issue14702] os.makedirs breaks under autofs directories In-Reply-To: <1335813257.88.0.458381281199.issue14702@psf.upfronthosting.co.za> Message-ID: <1336224633.25.0.680353197279.issue14702@psf.upfronthosting.co.za> R. David Murray added the comment: Hynek: you said "just like EEXIST", which doesn't check to see if the directory exists before continuing, thus my confusion. If mkdir -p does a stat first, then changing the makedirs algorithm to match is probably not a bad idea for OS compatibility reasons, with autofs just being an example of why. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 15:48:39 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 05 May 2012 13:48:39 +0000 Subject: [issue14729] test_faulthandler test is too specific to work on Windows In-Reply-To: <1336214675.26.0.0531566496861.issue14729@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > On Windows, some more information is appended to the end of the message (...) Which information? What do write these information? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 16:08:57 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 05 May 2012 14:08:57 +0000 Subject: [issue14702] os.makedirs breaks under autofs directories In-Reply-To: <1335813257.88.0.458381281199.issue14702@psf.upfronthosting.co.za> Message-ID: <1336226937.74.0.0593423359181.issue14702@psf.upfronthosting.co.za> Hynek Schlawack added the comment: >> Charles, I don't think you can blame autofs here. The problem at hand is that makedirs() never checks whether the directory exists (that would trigger the mount too I presume). > > Yes, it does. Have a look at line 148: > """ > if head and tail and not path.exists(head): > """ Now that's embarrassing. I take everything back and claim the opposite. >> If you try that approach in this case where /net is non-writable and /net/prodigy appears only on demand, it fails with an EPERM instead. > > Actually, no. > makedirs() does a recursive depth-first traversal: > makedirs('/net/prodigy/foo') will actually do something like: > """ > stat('/net/prodigy/foo') == ENOENT > stat('/net/prodigy') == ENONENT > mkdir('/net/prodigy') == EPERM > """ > The NFS mount should appear upon the first - or second - stat() call, > before mkdir(). > > But I'd like to be sure about that, that's why I think an strace() > output would be useful ;-) I glanced over coreutil's mkdir code and it seems that it changes the directory while creating the directories. I suspect it's related to that. At least it does no fstab parsing. ;) The code is wayyy too intricate to be grokable at glancing though. mkdir -p seems to be quite a can of worms. Andrew, please send straces. :) ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 16:31:46 2012 From: report at bugs.python.org (Paul Colomiets) Date: Sat, 05 May 2012 14:31:46 +0000 Subject: [issue14730] Implementation of the PEP 419 Message-ID: <1336228306.65.0.183212928475.issue14730@psf.upfronthosting.co.za> New submission from Paul Colomiets : Attached patch is a partial implementation of PEP 419, it lacks inspect module functions and requires more unit tests. ---------- components: Interpreter Core files: cleanuphook.patch keywords: patch messages: 159994 nosy: tailhook priority: normal severity: normal status: open title: Implementation of the PEP 419 type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25461/cleanuphook.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 17:45:10 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 05 May 2012 15:45:10 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za> Message-ID: <1336232710.84.0.275426384225.issue14082@psf.upfronthosting.co.za> Hynek Schlawack added the comment: So here's an updated patch. I've stripped everything away we don't need for copy2 integration. It catches EPERM, ENOTSUP and ENODATA (for race conditions). Happy reviewing. :) ---------- Added file: http://bugs.python.org/file25462/copy2-xattr.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 17:52:06 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 05 May 2012 15:52:06 +0000 Subject: [issue14729] test_faulthandler test is too specific to work on Windows In-Reply-To: <1336214675.26.0.0531566496861.issue14729@psf.upfronthosting.co.za> Message-ID: <1336233126.53.0.306681913779.issue14729@psf.upfronthosting.co.za> Vinay Sajip added the comment: > Which information? What do write these information? The Windows error message has the same beginning, but an additional "This application has requested the Runtime to terminate it in an unusual way.\nPlease contact the application's support team for more information." I believe this is added by Microsoft libraries - it's doesn't come from Python AFAIK. See #9116 for a similar problem (look only at the initial report - most of the following comments go off at a tangent about preventing debugger popups). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 18:00:44 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 05 May 2012 16:00:44 +0000 Subject: [issue14728] trace function not set, causing some Pdb commands to fail In-Reply-To: <1336214625.48.0.950841547459.issue14728@psf.upfronthosting.co.za> Message-ID: <1336233644.52.0.40577787442.issue14728@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Uploaded pdb_default.patch that applies on the default branch with minor changes to the initial pdb.patch. ---------- Added file: http://bugs.python.org/file25463/pdb_default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 18:01:13 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 05 May 2012 16:01:13 +0000 Subject: [issue14728] trace function not set, causing some Pdb commands to fail In-Reply-To: <1336214625.48.0.950841547459.issue14728@psf.upfronthosting.co.za> Message-ID: <1336233673.09.0.494121763903.issue14728@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Uploaded pdb_2.7.patch that applies on the 2.7 branch. ---------- Added file: http://bugs.python.org/file25464/pdb_2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 18:16:19 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 05 May 2012 16:16:19 +0000 Subject: [issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper In-Reply-To: <1326892577.13.0.456815776311.issue13815@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 254cb4f5d0ff by Lars Gust?bel in branch 'default': Issue #13815: TarFile.extractfile() now returns io.BufferedReader objects. http://hg.python.org/cpython/rev/254cb4f5d0ff ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 18:20:40 2012 From: report at bugs.python.org (Larry Hastings) Date: Sat, 05 May 2012 16:20:40 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336234840.08.0.314625865379.issue14705@psf.upfronthosting.co.za> Larry Hastings added the comment: Attached is rev 3 of my patch, incorporating mainly backing out of dumb ideas. Thanks for the feedback, Serhiy and Mark! > My name is Serhiy. :) My genuine apologies! In my defense it was rather late. > 'P' has the advantage that you can safely backward-compatibly > remove the restriction by replacing 'P' on 'p'. :) That's not a reason to use 'P'. Why you should use 'P' in the first place? > In this line in the patch (Python/getargs.c): > + if (val == -1 || PyErr_Occurred()) { > Isn't that call to PyErr_Occurred() redundant? Certainly one of the two expressions is! My thinking was: if the call fails, then the val == -1 will be an early-exit and we can save the call to PyErr_Occurred. This was always a dumb idea, as the 99.999999% case is that PyObject_IsTrue succeeds, in which case we would have called PyErr_Occured anyway. Some savings! I can't find any documentation on permitted return values from nb_bool. However, PyObject_IsTrue itself says about its own return value: /* if it is negative, it should be either -1 or -2 */ So I definitely shouldn't check specifically for -1. Having meditated on it, I think either I should either just call PyErr_Occured, check for explicit failure (val < 0), or explicit success (val >= 0). I've opted for the last of those. I considered briefly trying to make 'P' handle subclasses of bool. But then I hit the problem of: okay, what now? Call nb_bool? I note that bool itself doesn't define nb_bool. Anyway, what lunatic would subclass bool? I'm really on the fence about 'P'. Serhiy is definitely pro-, everyone else seems to think it shouldn't be used. However nobody has argued against its inclusion. At the moment I'm -0 on it myself, but since the code is written... Do we have an anti-champion? ---------- Added file: http://bugs.python.org/file25465/larry.parse.tuple.p.and.P.3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 18:24:58 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 05 May 2012 16:24:58 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336235098.83.0.557741547247.issue14705@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Since no one has produced a good example needing "P", I say drop it. At any rate, it can be almost trivially imitated with "O!". ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 18:29:44 2012 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Sat, 05 May 2012 16:29:44 +0000 Subject: [issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper In-Reply-To: <1326892577.13.0.456815776311.issue13815@psf.upfronthosting.co.za> Message-ID: <1336235384.43.0.461657496127.issue13815@psf.upfronthosting.co.za> Lars Gust?bel added the comment: I did some tarfile spring cleaning: I removed the ExFileObject class completely as it was more or less a leftover from the old days. io.BufferedReader now does the job. So, as a side-effect, I close this issue as fixed. (BTW, this makes tarfile.py smaller by about 100 lines.) ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 18:37:28 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 05 May 2012 16:37:28 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336235848.64.0.944824219896.issue14705@psf.upfronthosting.co.za> Georg Brandl added the comment: Indeed, "because the code is written" is not a good argument if even you yourself are -0. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 18:43:07 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sat, 05 May 2012 16:43:07 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1336236187.69.0.255847797168.issue14684@psf.upfronthosting.co.za> Nadeem Vawda added the comment: I've posted a review on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 18:45:37 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 05 May 2012 16:45:37 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336236337.7.0.345494296829.issue14705@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Having meditated on it, I think either I should either just call > PyErr_Occured, check for explicit failure (val < 0), or explicit success > (val >= 0). I've opted for the last of those. Yes, I think that works; it avoids a relatively expensive PyErr_Occurred() call in the non-failure case. The new code looks fine to me! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 18:50:51 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 05 May 2012 16:50:51 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336236651.24.0.890567968969.issue14705@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I considered briefly trying to make 'P' handle subclasses of bool. Not an issue: bool can't be subclassed. :-) Python 3.2.3 (default, Apr 13 2012, 00:15:25) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class MyBool(bool): ... pass ... Traceback (most recent call last): File "", line 1, in TypeError: type 'bool' is not an acceptable base type ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 19:12:48 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 May 2012 17:12:48 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1336234840.08.0.314625865379.issue14705@psf.upfronthosting.co.za> Message-ID: <1336238118.2345.37.camel@raxxla> Serhiy Storchaka added the comment: > That's not a reason to use 'P'. Why you should use 'P' in the first place? I just guided by the principle "Explicit is better than implicit". Statements 'if' and 'while' I consider explicit and expect cast to bool. Implicit cast to bool in the transfer of parameter causes discomfort (no one (no one Pythonist) expects the implicit cast to str). Unfortunately, for historical reasons, there is a lot of code, where the parameters are casted to bool or int is used instead of bool. Therefore, we cannot simply enter the restrictions. Well, I was certainly wrong. Don't let me mislead you. > Anyway, what lunatic would subclass bool? Class bool cannot be subclassed further. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 19:19:38 2012 From: report at bugs.python.org (Larry Hastings) Date: Sat, 05 May 2012 17:19:38 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336238378.62.0.844870270133.issue14705@psf.upfronthosting.co.za> Larry Hastings added the comment: Serhiy, I'm having a little trouble with your English. (But I'm sure your English is far better than my... uh, anything besides English.) So let me ask a question with a clear yes/no answer: Do you still think 'P' is better than 'p'? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 19:38:05 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 05 May 2012 17:38:05 +0000 Subject: [issue14725] test_multiprocessing failure under Windows In-Reply-To: <1336172041.91.0.79006187387.issue14725@psf.upfronthosting.co.za> Message-ID: <1336239485.69.0.802465792516.issue14725@psf.upfronthosting.co.za> Richard Oudkerk added the comment: The documentation page for ConnectNamedPipe (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365146(v=vs.85).aspx) has a "community addition" which says that ConnectNamedPipe will appear to fail with ERROR_NO_DATA (232) if a client has previously connected, written some data and disconnected. That seems to be what is happening. For example Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import multiprocessing.connection as con >>> l = con.Listener() >>> c = con.Client(l.address) >>> c.send("hello") >>> c.close() >>> l.accept() Traceback (most recent call last): File "", line 1, in File "c:\Python27\lib\multiprocessing\connection.py", line 145, in accept c = self._listener.accept() File "c:\Python27\lib\multiprocessing\connection.py", line 345, in accept win32.ConnectNamedPipe(handle, win32.NULL) WindowsError: [Error 232] The pipe is being closed I will look in to it. The community addition says to just treat ERROR_NO_DATA as success. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 19:41:08 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 May 2012 17:41:08 +0000 Subject: [issue14722] Overflow in parsing 'float' parameters in PyArg_ParseTuple* In-Reply-To: <1336160374.25.0.0230621275131.issue14722@psf.upfronthosting.co.za> Message-ID: <1336239810.2345.55.camel@raxxla> Serhiy Storchaka added the comment: No one integer produces infinity in 'double' parameter parsing. But the 'float' parameter parsing can produce infinity, and it can raise an exception. To be consistent, we need or produce infinity on double overflow (in this case, we must explicitly produce infinity on float overflow), or to raise an exception on float overflow. There is also a third option -- deprecate the 'float' parameter parsing. Leave the responsibility for the proper overflow handling on the user. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 19:46:11 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 05 May 2012 17:46:11 +0000 Subject: [issue14730] Implementation of the PEP 419: Protecting cleanup statements from interruptions In-Reply-To: <1336228306.65.0.183212928475.issue14730@psf.upfronthosting.co.za> Message-ID: <1336239971.42.0.453125793716.issue14730@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: Implementation of the PEP 419 -> Implementation of the PEP 419: Protecting cleanup statements from interruptions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 19:50:48 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 May 2012 17:50:48 +0000 Subject: [issue14654] Faster utf-8 decoding In-Reply-To: <1336150194.74.0.952631879863.issue14654@psf.upfronthosting.co.za> Message-ID: <1336240399.2345.65.camel@raxxla> Serhiy Storchaka added the comment: Well, it seems, 64-bit processors are smart enough to not feel the need for this optimization. On 32-bit platforms I see a noticeable increase in speed. I am now working on a more advanced optimization, which now shows a gain of +20-60% compared with the previous patches, but I hope to increase a gain by +50%-100%. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 19:51:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 May 2012 17:51:25 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za> Message-ID: <1336240285.82.0.747530639477.issue14082@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The copyxattr() function should be private (_copyxattr()). For some reason the tests are failing here: ====================================================================== ERROR: test_copy2_xattr (test.test_shutil.TestShutil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/antoine/cpython/default/Lib/test/test_shutil.py", line 410, in test_copy2_xattr os.setxattr(src, 'user.foo', b'42') OSError: [Errno 95] Operation not supported ====================================================================== ERROR: test_copyxattr (test.test_shutil.TestShutil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/antoine/cpython/default/Lib/test/test_shutil.py", line 296, in test_copyxattr os.setxattr(src, 'user.foo', b'42') OSError: [Errno 95] Operation not supported ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 19:55:22 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 May 2012 17:55:22 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1336238378.62.0.844870270133.issue14705@psf.upfronthosting.co.za> Message-ID: <1336240674.2345.69.camel@raxxla> Serhiy Storchaka added the comment: > Do you still think 'P' is better than 'p'? No. I hope I haven't made a lot of mistakes in the previous sentence. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 20:08:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 May 2012 18:08:40 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1336241320.78.0.752674984479.issue9260@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch also makes PyImport_ImportModuleNoBlock a simple alias of PyImport_ImportModule. ---------- Added file: http://bugs.python.org/file25466/module_locks4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 20:14:47 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 05 May 2012 18:14:47 +0000 Subject: [issue14731] Enhance Policy framework in preparation for adding "eamil6" policy as provisional Message-ID: <1336241687.85.0.143639170714.issue14731@psf.upfronthosting.co.za> New submission from R. David Murray : As discussed in my email to python-dev, I'm planning to add the new header parsing to Python 3.3 as a provisional extension, by adding a (set) of policies that are clearly marked provisional in the documentation. In order for this to work, I first need to make certain enhancements to the Policy framework that I previously committed to default. When reviewing the patch, please start with the 'architecture.rst' file in the Lib/email directory, which provides an overview of the changes and the plan. The primary changes are to add some new policy hooks that feedparser, message, and generator call. These hooks are then implemented on the renamed default policy (now called 'compat32') in such a way as to replicate the behavior of Python 3.2. The other significant change is that Message objects now have a policy. In order to accommodate this, this patch adds 'policy propagation' logic. That is, if you pass a policy to feedparser, then all the Message objects it creates get that policy. And when you flatten a message with a Generator, it uses the policy attached to the message unless you explicitly override it. I also factored policy into _basepolicy.py and policy.py. This doesn't mean much for this patch, but when the new policies land they go in policy.py, while the default policy is imported from _policybase. This means that if a Python 3.3 program does not explicitly use a policy, it will not import any of the new code. The remaining changes in the patch are some test reorganization. Since the goal is now 100% backward compatibility with Python 3.2 (including bugs in some cases), the patch removes some tests that were previously added to test.test_email.test_email and puts them into module specific test files (test_generator, test_parser, test_policy). Additional tests are also added. The end result of the test refactoring is that if you diff test_email.py after this patch against the 3.2 test_email.py, you should find a few places where the scaffolding is changed and the addition of some tests for bug fixes in the 3.2 code. Otherwise the tests should be identical to 3.2, with all the policy related tests moving into test_policy. The longer term plan for this is to replicate all of the test_email.py tests in appropriate module-specific test files (I've already marked a few such tests that got replicated in test_policy). By the time we get to Python4 the plan is for all the tests to be replicated, so that we can at that point drop compat32 by removing the policy and the test_email.py test file, as well as the code that will be at that point obsolete. The primary review here should be to make sure I am in fact producing 100% backward compatibility. Any other review comments will be welcome, of course. PS: I also changed the 'must_be_7bit' policy control, whose name I never liked, to be 'cte_type', which can be '7bit' or '8bit'. As noted in the architecture.rst file, the extra motivation for this is that there will eventually be a 'cte_type=unicode' which will support unicode display of formatted messages and, perhaps even more important, rfc 5335. ---------- hgrepos: 121 messages: 160015 nosy: barry, r.david.murray priority: normal severity: normal stage: patch review status: open title: Enhance Policy framework in preparation for adding "eamil6" policy as provisional type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 20:16:43 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 05 May 2012 18:16:43 +0000 Subject: [issue14731] Enhance Policy framework in preparation for adding "eamil6" policy as provisional In-Reply-To: <1336241687.85.0.143639170714.issue14731@psf.upfronthosting.co.za> Message-ID: <1336241803.88.0.0742614625795.issue14731@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- keywords: +patch Added file: http://bugs.python.org/file25467/676f9c8c28c6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 20:17:00 2012 From: report at bugs.python.org (Larry Hastings) Date: Sat, 05 May 2012 18:17:00 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336241820.28.0.0696211129512.issue14705@psf.upfronthosting.co.za> Larry Hastings added the comment: > I hope I haven't made a lot of mistakes in the previous sentence. It depends, do you consider three "a lot"? ;-) Attached is a new patch removing 'P'. (The regrtest is still running but I don't expect any failures.) I'm guessing I won't get any further feedback. So unless I hear otherwise I'll check it in tomorrow. ---------- Added file: http://bugs.python.org/file25468/larry.parse.tuple.p.4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 20:18:53 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 05 May 2012 18:18:53 +0000 Subject: [issue14731] Enhance Policy framework in preparation for adding email6 policies as provisional In-Reply-To: <1336241687.85.0.143639170714.issue14731@psf.upfronthosting.co.za> Message-ID: <1336241933.71.0.33882310063.issue14731@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: Enhance Policy framework in preparation for adding "eamil6" policy as provisional -> Enhance Policy framework in preparation for adding email6 policies as provisional _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 20:20:57 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 May 2012 18:20:57 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1336242057.46.0.921047176666.issue9260@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file25466/module_locks4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 20:21:07 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 May 2012 18:21:07 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1336242067.07.0.510712815271.issue9260@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Added file: http://bugs.python.org/file25469/module_locks4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 20:36:06 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 05 May 2012 18:36:06 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1336242966.18.0.891159014279.issue9260@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 20:48:22 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 05 May 2012 18:48:22 +0000 Subject: [issue14725] test_multiprocessing failure under Windows In-Reply-To: <1336172041.91.0.79006187387.issue14725@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 44f078ea05f3 by Richard Oudkerk in branch 'default': Fix for Issue 14725 for 3.3 branch. http://hg.python.org/cpython/rev/44f078ea05f3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 20:54:12 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 05 May 2012 18:54:12 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1336240285.82.0.747530639477.issue14082@psf.upfronthosting.co.za> Message-ID: <4FA57749.1000602@ox.cx> Hynek Schlawack added the comment: > The copyxattr() function should be private (_copyxattr()). Ok. I presumed that not adding it to __all__ is "private enough". > For some reason the tests are failing here: > > ====================================================================== > ERROR: test_copy2_xattr (test.test_shutil.TestShutil) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/home/antoine/cpython/default/Lib/test/test_shutil.py", line 410, in test_copy2_xattr > os.setxattr(src, 'user.foo', b'42') > OSError: [Errno 95] Operation not supported > > ====================================================================== > ERROR: test_copyxattr (test.test_shutil.TestShutil) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/home/antoine/cpython/default/Lib/test/test_shutil.py", line 296, in test_copyxattr > os.setxattr(src, 'user.foo', b'42') > OSError: [Errno 95] Operation not supported Looks like your file system Python uses for tmp files doesn't support xattr. That's bad because you can't verify. How should I cope with that? try/catch on the first setxattr() and skip the test if it fails? Is the an official way to do that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 20:55:22 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 05 May 2012 18:55:22 +0000 Subject: [issue14731] Enhance Policy framework in preparation for adding email6 policies as provisional In-Reply-To: <1336241687.85.0.143639170714.issue14731@psf.upfronthosting.co.za> Message-ID: <1336244122.48.0.86336203016.issue14731@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:00:17 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 05 May 2012 19:00:17 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336244417.66.0.71686082687.issue14705@psf.upfronthosting.co.za> Mark Dickinson added the comment: Latest patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:02:14 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 05 May 2012 19:02:14 +0000 Subject: [issue14654] Faster utf-8 decoding In-Reply-To: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za> Message-ID: <1336244534.29.0.188785865082.issue14654@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'll be closing this issue at this point. Serhiy: I don't think the bug tracker should be used to evolve work in progress (except when responding to reviews received). Use a Mercurial clone for that instead. By posting a patch here, you are requesting that it be reviewed and considered - please understand that you consume a lot of people's time by such a posting. At this point, it appears that you don't intend to submit any of these patches for inclusion into Python. If you ever do want to contribute something in this area, please create a new issue. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:03:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 May 2012 19:03:33 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1336244613.61.0.0741244969448.issue9260@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch also adds unit tests for the module locks and the deadlock avoidance algorithm. ---------- Added file: http://bugs.python.org/file25470/module_locks5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:06:50 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 05 May 2012 19:06:50 +0000 Subject: [issue14678] Update zipimport to support importlib.invalidate_caches() In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za> Message-ID: <1336244810.08.0.880561793444.issue14678@psf.upfronthosting.co.za> Brett Cannon added the comment: The real problem becomes the issue of what zipfile depends on, which complicates bootstrapping. I mean things could go as far as to write a script that takes in anchor points in the stdlib and freezes all code they depend on, but that seems like potential overkill and executable bloat. But something needs to happen as zipimporter has major shortcomings thanks to to its re-implementation of zip handling (e.g. no ZIP64 support, etc.). Plus no one ever wants to touch that code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:16:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 May 2012 19:16:10 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1336245370.22.0.105758419193.issue9260@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch with a couple new tests. ---------- stage: -> patch review Added file: http://bugs.python.org/file25471/module_locks6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:19:12 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 05 May 2012 19:19:12 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1336245552.85.0.336438703697.issue9260@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I still wonder whether Graham Dumpleton's observation has merits. Suppose we have these modules # a.py time.sleep(10) import b # b.py time.sleep(10) import a # main.py def x(): import a def y(): import b Now, if x and y are executed in separate threads - won't it deadlock? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:19:42 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 05 May 2012 19:19:42 +0000 Subject: [issue14678] Update zipimport to support importlib.invalidate_caches() In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za> Message-ID: <1336245582.73.0.296092805576.issue14678@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:19:55 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 May 2012 19:19:55 +0000 Subject: [issue14654] Faster utf-8 decoding In-Reply-To: <1336244534.29.0.188785865082.issue14654@psf.upfronthosting.co.za> Message-ID: <1336245483.3368.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > I'll be closing this issue at this point. Serhiy: I don't think the > bug tracker should be used to evolve work in progress (except when > responding to reviews received). Use a Mercurial clone for that > instead. By posting a patch here, you are requesting that it be > reviewed and considered - please understand that you consume a lot of > people's time by such a posting. That's not very nice. If Serhiy wants feedback on his work, he definitely has to post *somewhere*. The bug tracker sounds like a reasonable place (certainly more reasonable than python-dev). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:21:00 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 May 2012 19:21:00 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1336245552.85.0.336438703697.issue9260@psf.upfronthosting.co.za> Message-ID: <1336245549.3368.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > Now, if x and y are executed in separate threads - won't it deadlock? Well, the patch has a deadlock avoidance mechanism, and it includes unit tests for precisely this situation. I cannot promise the algorithm is perfect (although there *are* a bunch of tests), but it looks correct from here. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:24:49 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 May 2012 19:24:49 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <4FA57749.1000602@ox.cx> Message-ID: <1336245778.3368.2.camel@localhost.localdomain> Antoine Pitrou added the comment: > Looks like your file system Python uses for tmp files doesn't support > xattr. That's bad because you can't verify. How should I cope with that? > try/catch on the first setxattr() and skip the test if it fails? Is the > an official way to do that? Well, apparently the extended attributes tests in test_os get skipped with the following message: "no non-broken extended attribute support". Perhaps you need the same condition somewhere. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:33:32 2012 From: report at bugs.python.org (Sam Rushing) Date: Sat, 05 May 2012 19:33:32 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary In-Reply-To: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> Message-ID: <1336246412.11.0.71264622476.issue14684@psf.upfronthosting.co.za> Sam Rushing added the comment: renames dict->zdict, splits the test, adds BEGIN/END around inflate call. ---------- Added file: http://bugs.python.org/file25472/zlib_set_dictionary_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:33:34 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 05 May 2012 19:33:34 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1336246414.35.0.323464527445.issue9260@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you please elaborate in the patch what the deadlock avoidance does? AFAICT, the comment explains that it is able to detect deadlocks, but nowhere says what it does when it has detected a deadlock. Also, please submit patches against default's head, or stop using git-style diffs, to enable Rietveld review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:38:28 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 05 May 2012 19:38:28 +0000 Subject: [issue14729] test_faulthandler test is too specific to work on Windows In-Reply-To: <1336214675.26.0.0531566496861.issue14729@psf.upfronthosting.co.za> Message-ID: <1336246708.52.0.229418674023.issue14729@psf.upfronthosting.co.za> Stefan Krah added the comment: Vinay's patch solves the problem. +1 for committing. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:46:23 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 05 May 2012 19:46:23 +0000 Subject: [issue9116] test_capi.test_no_FatalError_infinite_loop crash on Windows In-Reply-To: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za> Message-ID: <1336247183.04.0.546396835439.issue9116@psf.upfronthosting.co.za> Stefan Krah added the comment: I tested the patch, it works fine. I can't test the popup situation since I currently only have ssh access. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:47:19 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sat, 05 May 2012 19:47:19 +0000 Subject: [issue14732] PEP 3121 Refactoring applied to _csv module Message-ID: <1336247238.98.0.79082288942.issue14732@psf.upfronthosting.co.za> New submission from Robin Schreiber : This patch presents my first try to apply the proposed Refactoring of PEP3121 to the csv module. I have identified three mutable global variables inside the module, two of which are references to PyObjects. I have wrapped all of them inside a dedicated struct, which is traversed by the gc after "freeing" the module. I also defined some macros, to hide functions calls that are now needed because of the newly introduced indirections. ---------- components: Extension Modules files: csv_pep3121.patch keywords: patch messages: 160032 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121 Refactoring applied to _csv module type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25473/csv_pep3121.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:49:44 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sat, 05 May 2012 19:49:44 +0000 Subject: [issue14732] PEP 3121 Refactoring applied to _csv module In-Reply-To: <1336247238.98.0.79082288942.issue14732@psf.upfronthosting.co.za> Message-ID: <1336247384.45.0.721494332512.issue14732@psf.upfronthosting.co.za> Robin Schreiber added the comment: The following script should fail before you have applied the bespoken patch: It basically checks wether one of the global PyObjects inside the csv module is being deleted after freeing the csv module. ---------- Added file: http://bugs.python.org/file25474/refactoring_test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:50:32 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 May 2012 19:50:32 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1336247432.01.0.237074518576.issue9260@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch against tip, and with a comment of what deadlock avoidance does (in _ModuleLock.acquire's docstring). ---------- Added file: http://bugs.python.org/file25475/module_locks7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:54:58 2012 From: report at bugs.python.org (Janusz Lewandowski) Date: Sat, 05 May 2012 19:54:58 +0000 Subject: [issue14733] Custom commands don't work Message-ID: <1336247698.3.0.601415993059.issue14733@psf.upfronthosting.co.za> New submission from Janusz Lewandowski : Running (by pysetup run cmdname) custom commands doesn't work, because setup.cfg is parsed after command handling. I've attached a patch to fix this behavior. ---------- assignee: eric.araujo components: Distutils2 files: fix-custom-commands.patch keywords: patch messages: 160035 nosy: LEW21, alexis, eric.araujo, tarek priority: normal severity: normal status: open title: Custom commands don't work type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file25476/fix-custom-commands.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 21:59:39 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 05 May 2012 19:59:39 +0000 Subject: [issue14725] test_multiprocessing failure under Windows In-Reply-To: <1336172041.91.0.79006187387.issue14725@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 35ef949e85d7 by Richard Oudkerk in branch '2.7': Fix for issue 14725 for 2.7 branch http://hg.python.org/cpython/rev/35ef949e85d7 New changeset afab4d14d5e7 by Richard Oudkerk in branch '3.2': Fix for issue 14725 for 3.2 branch http://hg.python.org/cpython/rev/afab4d14d5e7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 22:12:46 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 05 May 2012 20:12:46 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1336248766.32.0.876784401461.issue9260@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The patch parser of Rietveld actually choked on the git binary diff. It now skips over these chunks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 22:17:42 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 05 May 2012 20:17:42 +0000 Subject: [issue14734] Use binascii.b2a_qp/a2b_qp in email package header handling? Message-ID: <1336249062.57.0.661119787724.issue14734@psf.upfronthosting.co.za> New submission from R. David Murray : Currently the email package uses its own custom quoted printable encode/decode implementation for handling header quoted printable CTE encoding and decoding. It could be that using binascii would work, and be more performant. Or it might not be, but it seems like it might be worth investigating. ---------- assignee: r.david.murray messages: 160038 nosy: r.david.murray priority: low severity: normal status: open title: Use binascii.b2a_qp/a2b_qp in email package header handling? type: performance versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 22:21:35 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 05 May 2012 20:21:35 +0000 Subject: [issue14732] PEP 3121 Refactoring applied to _csv module In-Reply-To: <1336247238.98.0.79082288942.issue14732@psf.upfronthosting.co.za> Message-ID: <1336249295.09.0.0237777687731.issue14732@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 22:25:39 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 05 May 2012 20:25:39 +0000 Subject: [issue14722] Overflow in parsing 'float' parameters in PyArg_ParseTuple* In-Reply-To: <1336142237.23.0.0183531993231.issue14722@psf.upfronthosting.co.za> Message-ID: <1336249539.16.0.910746617763.issue14722@psf.upfronthosting.co.za> Stefan Krah added the comment: The proposal makes sense at first glance, but I agree with Mark that it is not clear what should be done. For example, all arrays in Python silently convert to inf: >>> from numpy import array >>> x = array([1,2,3], 'f') >>> x array([ 1., 2., 3.], dtype=float32) >>> x[0] = 10**100 >>> x array([ inf, 2., 3.], dtype=float32) Same for array.array and memoryview. I would not be surprised if users rely on this behavior. Anyway, silently converting to infinity is exactly what I'd expect (also for double BTW). Regarding undefined behavior: I only know compilers that convert to infinity without signaling overflow. The tests for the new memoryview implementation should include this case (I think!), and I ran the tests with all compilers that I've access to. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 22:34:59 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 05 May 2012 20:34:59 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za> Message-ID: <1336250099.64.0.915643514538.issue14082@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Ok, I've extracted the xattr checker from test_os.py and transformed it into a caching decorator like skip_unless_symlinks. _copyxattr rename is also done. ---------- Added file: http://bugs.python.org/file25477/copy2-xattr-with-better-protection.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 23:08:35 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 05 May 2012 21:08:35 +0000 Subject: [issue14733] Custom commands don't work In-Reply-To: <1336247698.3.0.601415993059.issue14733@psf.upfronthosting.co.za> Message-ID: <1336252115.88.0.181242439939.issue14733@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the report and patch. I discovered the same thing a few weeks ago when working on a bug with a contributor; I thought there was already a bug opened for that but apparently not. The fix I had in mind is the same as your patch, and I also have a test for this. This was not caught before because our tests use internal objects directly (i.e. the Distribution class), so the run function is not exercised by the test suite. Some of the tests are starting to use subprocess instead so that we can really test the script. ---------- versions: +3rd party, Python 3.3 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 23:15:01 2012 From: report at bugs.python.org (Ed Wodrich) Date: Sat, 05 May 2012 21:15:01 +0000 Subject: [issue14735] Version 3.2.3 IDLE CTRL-Z plus Carriage Return to end does not work Message-ID: <1336252501.23.0.54042826511.issue14735@psf.upfronthosting.co.za> New submission from Ed Wodrich : Greetings, I am a brand new user attempting to learn Python. I downloaded and installed the .msi installer version 3.2.3 on May 5, 2012. I am running Windows XP SP2 32-bit on a Pentium 4. I opted to load all features of the program. Installation finished without any errors. Admittedly, despite previous programming experience with other languages, I have a lot to learn. What I saw when I tried using the IDLE was that it would not end with ctrl-Z followed by carriage return. Using either quit() and replying to the dialog or using ctrl-d followed by carriage return worked. I am submitting this because the GUI interface and what documentation I have seen so far states that ctrl-z followed by carriage return is the method to use in Windows. IMHO possible fix options (presuming this is not something weird because I don't know what I am doing yet) would be to update the documentation for consistency or to change the behavior of the IDLE? Thank you, in advance, for your efforts with regard to this issue. Best Regards, Ed ---------- components: IDLE messages: 160042 nosy: ewodrich priority: normal severity: normal status: open title: Version 3.2.3 IDLE CTRL-Z plus Carriage Return to end does not work type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 5 23:32:33 2012 From: report at bugs.python.org (Ed Wodrich) Date: Sat, 05 May 2012 21:32:33 +0000 Subject: [issue14735] Version 3.2.3 IDLE CTRL-Z plus Carriage Return to end does not work In-Reply-To: <1336252501.23.0.54042826511.issue14735@psf.upfronthosting.co.za> Message-ID: <1336253553.14.0.812534313699.issue14735@psf.upfronthosting.co.za> Changes by Ed Wodrich : ---------- nosy: -ewodrich _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 00:06:18 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 05 May 2012 22:06:18 +0000 Subject: [issue14654] Faster utf-8 decoding In-Reply-To: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za> Message-ID: <20120506000608.Horde.zfgkf8L8999PpaRQSquHWOA@webmail.df.eu> Martin v. L?wis added the comment: > That's not very nice. If Serhiy wants feedback on his work, he > definitely has to post *somewhere*. The bug tracker sounds like a > reasonable place (certainly more reasonable than python-dev). I completely disagree (and I really tried to be nice). It is my utmost belief that the tracker must not be used for work-in-progress. For any open issue, numerous people review the issue, and even if they spend only a few minutes, this easily adds up to a lot of wasted time if there isn't anything to be done about an issue. OTOH, discussing it on python-dev indeed seems more appropriate: even though the readership is larger, people know that they can safely skip over messages that clearly don't need their attention. So if Serhiy posts a message titled "UTF-8 performance", people will hit the delete button very quickly if they are not interested. However, it would really be best in this case if Serhiy takes a step back, and analyzes the performance of the current decoder carefully, then proposes a patch which undoubtedly improves the performance and is meanwhile also maintainable. He may come to the conclusion that further improvement isn't really possible or reasonable, in which case it would be good if he posted his findings to python-dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 01:55:40 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 05 May 2012 23:55:40 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset bc6d28e726d8 by Larry Hastings in branch 'default': Issue #14705: Add 'p' format character to PyArg_ParseTuple* for bool support. http://hg.python.org/cpython/rev/bc6d28e726d8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 01:56:30 2012 From: report at bugs.python.org (Larry Hastings) Date: Sat, 05 May 2012 23:56:30 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336262190.32.0.704142483623.issue14705@psf.upfronthosting.co.za> Larry Hastings added the comment: Eh, it was ready, why wait? Thanks everybody for your feedback! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 02:15:35 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 06 May 2012 00:15:35 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336263335.26.0.11458004972.issue14705@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I would have expected a bool parse code to insist on a boolean, so that: int x; PyArg_ParseTupleAndKeywords(args, kwds, "p:func", &x); would behave the same as: PyObject *o; int x; PyArg_ParseTupleAndKeywords(args, kwds, "O!:func", &PyBool_Type, &o); x = o == Py_True; ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 02:21:18 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 May 2012 00:21:18 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336263678.6.0.489823199008.issue14705@psf.upfronthosting.co.za> Larry Hastings added the comment: > I would have expected a bool parse code to insist on a boolean, I originally had a second form ('P') that insisted on a boolean as you suggest. But nobody could come up with a use case. So I removed it in the final patch. Please see this issue for the discussion. If you have a use case for it I'd be happy to revive it and check it in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 02:40:17 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 May 2012 00:40:17 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 709850f1ec67 by Larry Hastings in branch 'default': Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.) http://hg.python.org/cpython/rev/709850f1ec67 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 02:40:17 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 May 2012 00:40:17 +0000 Subject: [issue10148] st_mtime differs after shutil.copy2 In-Reply-To: <1287530071.19.0.608159353416.issue10148@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 709850f1ec67 by Larry Hastings in branch 'default': Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.) http://hg.python.org/cpython/rev/709850f1ec67 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 02:40:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 May 2012 00:40:18 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 709850f1ec67 by Larry Hastings in branch 'default': Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.) http://hg.python.org/cpython/rev/709850f1ec67 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 03:08:03 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 06 May 2012 01:08:03 +0000 Subject: [issue14736] Add {encode, decode}_filter_properties() functions to lzma module Message-ID: <1336266483.84.0.291030499892.issue14736@psf.upfronthosting.co.za> New submission from Nadeem Vawda : Patch attached. Reviews welcome. ---------- components: Extension Modules files: lzma-properties.diff keywords: patch messages: 160051 nosy: nadeem.vawda priority: normal severity: normal stage: patch review status: open title: Add {encode,decode}_filter_properties() functions to lzma module type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25478/lzma-properties.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 03:09:58 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 May 2012 01:09:58 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336266598.44.0.959487661475.issue14705@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- resolution: -> fixed stage: patch review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 03:11:32 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 06 May 2012 01:11:32 +0000 Subject: [issue14366] Supporting lzma compression in zip files In-Reply-To: <1332112236.1.0.964135054036.issue14366@psf.upfronthosting.co.za> Message-ID: <1336266692.91.0.28053257937.issue14366@psf.upfronthosting.co.za> Nadeem Vawda added the comment: I've put together a patch for the lzma module adding functions for encoding and decoding filter properties (see issue 14736). It's a bit bulky, though, so I'd like to get a review before committing it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 06:50:12 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 06 May 2012 04:50:12 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1336279812.3.0.555803193885.issue14657@psf.upfronthosting.co.za> Eric Snow added the comment: Here's my take. No one will care about _frozen_importlib vs. importlib._bootstrap normally, right? If __module__/__file__ says _frozen_importlib, it's no big deal. The only time you care about the distiction for importlib._bootstrap is when you're hacking on _bootstrap.py. So let's keep the common case in sight and go from there. There are two sides to the uncommon case: 1. making sure importlib still works after hacking on _bootstrap.py (test_imp, test_import, test_importlib using your new _bootstrap.py). 2. making sure everything still works after hacking on _bootstrap.py (the whole test suite with a new importlib.h?). For the first part, let's simply ignore the pure Python importlib._bootstrap by default? Then we stick a context manager in importlib.test.util that enables it. When you're hacking on _bootstrap.py, you switch it over. The common path stays pretty clean. I've attached a patch for the first part which has similarities to Antoine's. (I didn't apply the context manager to the importlib test cases though.) For that second part, something along the lines of what Nick has posted would be pretty close, but I'm not sure it's worth it. From what I understand, Nick's patch would add yet another import (importlib) to startup to cover a situation that happens very infrequently (hacking _bootstrap.py). However, I'm torn because... ...dealing with a busted importlib.h is not fun. Is there a different approach we could take for that second part? Perhaps something like this: 1. python starts up normally. 2. we clear out all the entire import state except for builtins. 3. we stick importlib._bootstrap in place. 4. we set builtins.__import__ to importlib.__import__. 5. we re-populate sys.modules by reloading all the modules that were in there before (?). 6. we run the test suite against this new import state. 7. ... 8. profit! I'm probably missing something here, but I expect we could stick something like that in some place like importlib.test.util. Would that be sufficient to mitigate the chance of breaking importlib.h? ------------------------------------ Example of using my patch: >>> import sys >>> import importlib.test.util as util >>> importlib._bootstrap '> >>> sys.modules['importlib._bootstrap'] '> >>> with util.bootstrap_context(importlib, importlib._pure_bootstrap): ... importlib._bootstrap ... sys.modules['importlib._bootstrap'] ... >>> importlib._bootstrap '> >>> sys.modules['importlib._bootstrap'] '> ---------- Added file: http://bugs.python.org/file25479/issue14657_safe_bootstrap.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 06:58:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 May 2012 04:58:45 +0000 Subject: [issue10148] st_mtime differs after shutil.copy2 In-Reply-To: <1287530071.19.0.608159353416.issue10148@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 05274ab06182 by Larry Hastings in branch 'default': Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.) http://hg.python.org/cpython/rev/05274ab06182 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 06:58:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 May 2012 04:58:45 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 05274ab06182 by Larry Hastings in branch 'default': Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.) http://hg.python.org/cpython/rev/05274ab06182 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 06:58:46 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 May 2012 04:58:46 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 05274ab06182 by Larry Hastings in branch 'default': Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.) http://hg.python.org/cpython/rev/05274ab06182 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 08:03:22 2012 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 May 2012 06:03:22 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: <1336284202.07.0.228226370587.issue14705@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 08:21:28 2012 From: report at bugs.python.org (Yuval Greenfield) Date: Sun, 06 May 2012 06:21:28 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1336285288.9.0.329620864924.issue13968@psf.upfronthosting.co.za> Yuval Greenfield added the comment: So, anybody for or against this patch? I'd really like to see this feature make its way in... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 09:04:57 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 06 May 2012 07:04:57 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1336287897.81.0.0688531045234.issue14657@psf.upfronthosting.co.za> Nick Coghlan added the comment: The piece you're missing is that the interpreter state holds a direct reference to the import machinery in interp->importlib, and *that's* what gets used by the builtin __import__ implementation. I'm beginning to think the thing to do is to simply say "yes, there are two copies of importlib._bootstrap". By default, the compiled in one is used, but you can replace it with the on-disk one by appropriately editing sys.meta_path and sys.path_hooks. Trying to hide it isn't going to eliminate the potential problems - it's just going to move the problems around (and likely make them even more confusing in the process). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 09:06:58 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 06 May 2012 07:06:58 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1336288018.04.0.37266869019.issue14657@psf.upfronthosting.co.za> Nick Coghlan added the comment: Forgot to add: in our own tests, we should ensure that both the frozen and on-disk versions get executed. I believe that's already the case, since I don't recall anyone removing the test infrastructure that ensured both import.c and importlib are tested for correct behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 09:23:58 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 07:23:58 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1336288018.04.0.37266869019.issue14657@psf.upfronthosting.co.za> Message-ID: <1336288921.3336.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > I believe that's already the case, since I don't recall anyone > removing the test infrastructure that ensured both import.c and > importlib are tested for correct behaviour. What do you mean? I think test_importlib only tests the on-disk version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 09:28:34 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 07:28:34 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1336279812.3.0.555803193885.issue14657@psf.upfronthosting.co.za> Message-ID: <1336289200.3336.4.camel@localhost.localdomain> Antoine Pitrou added the comment: > Here's my take. No one will care about _frozen_importlib vs. > importlib._bootstrap normally, right? If __module__/__file__ says > _frozen_importlib, it's no big deal. The reason I'd prefer __file__ to point to the actual Python file is so that people reading a traceback can find the source code. Of course that's a bit minor. (and, incidentally, the traceback itself will display the source code lines) > The only time you care about the distiction for importlib._bootstrap > is when you're hacking on _bootstrap.py. So let's keep the common > case in sight and go from there. Agreed. > For the first part, let's simply ignore the pure Python > importlib._bootstrap by default? Then we stick a context manager in > importlib.test.util that enables it. When you're hacking on > _bootstrap.py, you switch it over. The common path stays pretty > clean. Looks good to me. > I've attached a patch for the first part which has similarities to > Antoine's. (I didn't apply the context manager to the importlib test > cases though.) I think set_bootstrap() looks a bit fragile, since we have to manually add any importlib attributes that are exported in importlib/__init__.py. Perhaps we could detect them automatically? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 09:46:12 2012 From: report at bugs.python.org (Pierre Quentel) Date: Sun, 06 May 2012 07:46:12 +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: <1336290372.38.0.224098415237.issue14565@psf.upfronthosting.co.za> Pierre Quentel added the comment: Hi Glenn, good to hear from you ;-) I think the fix can be simplified replacing dir_sep = collapsed_path.find('/', 1) by dir_sep = collapsed_path.rfind('/', 1) ---------- nosy: +quentel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 10:21:52 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 08:21:52 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1336292512.22.0.228686582974.issue13968@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 10:27:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 08:27:46 +0000 Subject: [issue14736] Add {encode, decode}_filter_properties() functions to lzma module In-Reply-To: <1336266483.84.0.291030499892.issue14736@psf.upfronthosting.co.za> Message-ID: <1336292866.56.0.441077339936.issue14736@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The functionality looks a bit cryptic to me. What is the use case? I wonder if Py_LONG_LONG is always defined (although it certainly is on major platforms). Other than that, the patch looks technically correct, though I'm not an lzma expert. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 11:16:28 2012 From: report at bugs.python.org (Trent Nelson) Date: Sun, 06 May 2012 09:16:28 +0000 Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za> Message-ID: <1336295788.09.0.320236357956.issue13241@psf.upfronthosting.co.za> Trent Nelson added the comment: Hi Ned, On a brand new OS X Lion install with the latest XCode (4.3.2) and command line tools*, the following worked: ./configure --with-pydebug CC=clang MACOSX_DEPLOYMENT_TARGET=10.7 That is, everything built cleanly, and all tests ran without failures: 336 tests OK. 2 tests altered the execution environment: test_packaging test_site 26 tests skipped: test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu test_devpoll test_epoll test_gdb test_largefile test_lzma test_msilib test_ossaudiodev test_smtpnet test_socketserver test_startfile test_timeout test_tk test_ttk_guionly test_urllib2net test_urllibnet test_winreg test_winsound test_xmlrpc_net test_zipfile64 3 skips unexpected on darwin: test_lzma test_tk test_ttk_guionly I presume the aim is to be able to build correctly (on all UNIX platforms) with just ./configure --with-pydebug, right? How's your configure*-toolchain-fu? Once we fix this I can add the build slave. Side bar: note that this was a vanilla 10.6->10.7 install. The XCode 4.3.2 install on 10.7 was the first XCode ever installed on the box; there's no /Developer or any of the old gcc* cruft. [*]: Went to https://developer.apple.com/downloads/index.action, logged in with my Apple ID, then downloaded 'Commandline Tools for XCode - Late March 2012' -- dmg was 'cltools_lion_latemarch12.dmg'. ---------- nosy: +trent _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 11:32:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 09:32:05 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: <1336296725.66.0.568845265507.issue13183@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If the failures don't get fixed, the offending commit should be reverted. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 11:47:24 2012 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Sun, 06 May 2012 09:47:24 +0000 Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za> Message-ID: <1336297644.64.0.82802146801.issue13241@psf.upfronthosting.co.za> Michele Orr? added the comment: >./configure --with-pydebug CC=clang MACOSX_DEPLOYMENT_TARGET=10.7 Works on my machine too. ---------- nosy: +maker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 11:50:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 May 2012 09:50:26 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e275a9f7daa9 by Georg Brandl in branch '3.2': #13183: backport fixes to test_pdb to 3.2 branch http://hg.python.org/cpython/rev/e275a9f7daa9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 11:54:06 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 May 2012 09:54:06 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2644e4ea02d3 by Georg Brandl in branch '2.7': #13183: backport fixes to test_pdb to 2.7 branch http://hg.python.org/cpython/rev/2644e4ea02d3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 11:54:33 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 06 May 2012 09:54:33 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: <1336298073.94.0.0389544352013.issue13183@psf.upfronthosting.co.za> Georg Brandl added the comment: Should be fixed now. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 12:28:54 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 May 2012 10:28:54 +0000 Subject: [issue14729] test_faulthandler test is too specific to work on Windows In-Reply-To: <1336214675.26.0.0531566496861.issue14729@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2e71f25912d4 by Vinay Sajip in branch 'default': Closes #14729: Allowed test to pass on Windows by adjusting the test condition slightly to allow for a Windows-specific error message. http://hg.python.org/cpython/rev/2e71f25912d4 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 12:34:48 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 06 May 2012 10:34:48 +0000 Subject: [issue14736] Add {encode, decode}_filter_properties() functions to lzma module In-Reply-To: <1336266483.84.0.291030499892.issue14736@psf.upfronthosting.co.za> Message-ID: <1336300488.71.0.263355095308.issue14736@psf.upfronthosting.co.za> Nadeem Vawda added the comment: > The functionality looks a bit cryptic to me. What is the use case? Serializing filter specifiers for custom file formats. The particular case that prompted adding the code is zipfile (issue 14366). I've added a note to the docs and docstrings explaining this. > I wonder if Py_LONG_LONG is always defined (although it certainly is on major platforms). I expect it will always be defined on platforms that support liblzma - the API uses uint64_t in quite a few places, via the lzma_vli typedef. In any case, _lzmamodule.c checks for PY_LONG_LONG explicitly at compile-time and gives a useful error message if it is undefined. ---------- Added file: http://bugs.python.org/file25480/lzma-properties.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 12:35:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 May 2012 10:35:09 +0000 Subject: [issue9116] test_capi.test_no_FatalError_infinite_loop crash on Windows In-Reply-To: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 4d74d275224d by Vinay Sajip in branch 'default': Issue #9116: Allowed test to pass on Windows by adjusting the test condition slightly to allow for a Windows-specific error message. http://hg.python.org/cpython/rev/4d74d275224d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 12:38:57 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 10:38:57 +0000 Subject: [issue14736] Add {encode, decode}_filter_properties() functions to lzma module In-Reply-To: <1336266483.84.0.291030499892.issue14736@psf.upfronthosting.co.za> Message-ID: <1336300737.0.0.831407342457.issue14736@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The updated patch looks ok to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 13:03:17 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 May 2012 11:03:17 +0000 Subject: [issue12660] test_gdb fails when installed In-Reply-To: <1312038409.05.0.274432685937.issue12660@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 84bbb8d2d237 by Vinay Sajip in branch 'default': #12660: Skip test_gdb when run from an installed Python. http://hg.python.org/cpython/rev/84bbb8d2d237 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 13:43:35 2012 From: report at bugs.python.org (ganges master) Date: Sun, 06 May 2012 11:43:35 +0000 Subject: [issue14737] subprocess.Popen pipes not working Message-ID: <1336304615.86.0.376011401786.issue14737@psf.upfronthosting.co.za> New submission from ganges master : Attempting to read from stdout of a running process seems broken on Python3.2. I've been able to reproduce this on Ubuntu 11.4 and Windows 7 (with /bin/sh installed as part of git for windows) Python 3.2 (r32:88445, Dec 8 2011, 15:26:51) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from subprocess import Popen, PIPE >>> p=Popen(["/bin/sh"], stdin=PIPE, stderr=PIPE, stdout=PIPE) >>> p.stdin.write(b"echo hello\n") 11 >>> p.stdout.readline() >>> from subprocess import Popen, PIPE >>> p=Popen(["/bin/sh"], stdin=PIPE, stderr=PIPE, stdout=PIPE) >>> p.stdin.write(b"echo hello\n") 11 >>> p.stdout.read(2) For comparison, on python 2.7 (again, linux and windows: Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from subprocess import Popen, PIPE >>> p=Popen(["/bin/sh"], stdin=PIPE, stderr=PIPE, stdout=PIPE) >>> p.stdin.write(b"echo hello\n") >>> p.stdout.readline() 'hello\n' >>> ---------- components: Library (Lib) messages: 160075 nosy: gangesmaster priority: normal severity: normal status: open title: subprocess.Popen pipes not working versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 13:55:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 11:55:40 +0000 Subject: [issue14737] subprocess.Popen pipes not working In-Reply-To: <1336304615.86.0.376011401786.issue14737@psf.upfronthosting.co.za> Message-ID: <1336305340.06.0.94955415497.issue14737@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Works with 3.2.2: Python 3.2.2+ (3.2:9ef20fbd340f, Oct 15 2011, 21:22:07) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from subprocess import Popen, PIPE >>> p=Popen(["/bin/sh"], stdin=PIPE, stderr=PIPE, stdout=PIPE) >>> p.stdin.write(b"echo hello\n") 11 >>> p.stdout.readline() b'hello\n' Try calling p.stdin.flush() perhaps? ---------- nosy: +gregory.p.smith, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 13:59:43 2012 From: report at bugs.python.org (ganges master) Date: Sun, 06 May 2012 11:59:43 +0000 Subject: [issue14737] subprocess.Popen pipes not working In-Reply-To: <1336304615.86.0.376011401786.issue14737@psf.upfronthosting.co.za> Message-ID: <1336305583.66.0.138667334527.issue14737@psf.upfronthosting.co.za> ganges master added the comment: hmm, it does work when i call flush, but it works perfectly fine without flushing on python2.x... i guess this has to do with str/bytes again. maybe this should be documented somewhere? thanks for the tip though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 14:04:43 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 12:04:43 +0000 Subject: [issue14737] subprocess.Popen pipes not working In-Reply-To: <1336304615.86.0.376011401786.issue14737@psf.upfronthosting.co.za> Message-ID: <1336305883.06.0.20307403198.issue14737@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Nothing to do with str/bytes, actually; I think it was fixed in #11459 (changeset 7451da272111), so you might want to upgrade your Python 3.2 (or use the flush() workaround). ---------- resolution: -> out of date stage: -> committed/rejected status: open -> closed superseder: -> Python select.select does not correctly report read readyness _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 15:08:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 13:08:41 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1336309721.15.0.241369613888.issue13968@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > So, anybody for or against this patch? I'd really like to see this > feature make its way in... I think the feature is useful, but someone needs to review the patch. Sorry if it takes some time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 15:11:08 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 May 2012 13:11:08 +0000 Subject: [issue13989] gzip always returns byte strings, no text mode In-Reply-To: <1328894094.18.0.18729195074.issue13989@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 55202ca694d7 by Nadeem Vawda in branch 'default': Closes #13989: Add support for text modes to gzip.open(). http://hg.python.org/cpython/rev/55202ca694d7 ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 15:29:44 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 06 May 2012 13:29:44 +0000 Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za> Message-ID: <1336310984.96.0.167518015532.issue13241@psf.upfronthosting.co.za> Ned Deily added the comment: Trent, yes, now that the Xcode 4 situation has settled down a bit, clang is the compiler of choice for OS X 10.7 with Xcode 4.3 although there are still some open questions. I intend to update configure in the near future for all active branches to provide more appropriate defaults for 10.6 and 10.7 and for universal builds with the various SDK locations. >"Once we fix this I can add the build slave" I'm missing the context for this. Can't you override with environment variables or on the configure command itself? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 15:33:54 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 06 May 2012 13:33:54 +0000 Subject: [issue14583] try/except import fails --without-threads In-Reply-To: <1334436331.01.0.461185960127.issue14583@psf.upfronthosting.co.za> Message-ID: <1336311234.02.0.754155761532.issue14583@psf.upfronthosting.co.za> Changes by Nadeem Vawda : ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 15:37:47 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 06 May 2012 13:37:47 +0000 Subject: [issue14654] Faster utf-8 decoding In-Reply-To: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za> Message-ID: <1336311467.27.0.734381628108.issue14654@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I understand Martin point, but I think 95% of issues in the bugtracker are "work in progress", mine included. Maybe the issue is that Serhiy hasn't made a concrete proposal to be tested & integrated. It seems to be more an exploratory work. I am in the nosy list because I am interested in this work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 15:55:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 May 2012 13:55:26 +0000 Subject: [issue14034] Add argparse howto In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 48385618525b by Ezio Melotti in branch '2.7': #14034: added the argparse tutorial. Patch by Tshepang Lekhonkhobe. http://hg.python.org/cpython/rev/48385618525b New changeset 11703cb2a2f3 by Ezio Melotti in branch '3.2': #14034: added the argparse tutorial. Patch by Tshepang Lekhonkhobe. http://hg.python.org/cpython/rev/11703cb2a2f3 New changeset 645969f4193b by Ezio Melotti in branch 'default': #14034: merge argparse tutorial from 3.2. http://hg.python.org/cpython/rev/645969f4193b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 16:06:01 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 May 2012 14:06:01 +0000 Subject: [issue14034] Add argparse howto In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 549aa1460811 by Ezio Melotti in branch '2.7': #14034: adapt to Python 2 and fix indentation. http://hg.python.org/cpython/rev/549aa1460811 New changeset d5b7be0629c0 by Ezio Melotti in branch '3.2': #14034: fix indentation. http://hg.python.org/cpython/rev/d5b7be0629c0 New changeset e14c860f6eee by Ezio Melotti in branch 'default': #14034: merge indentation fixes from 3.2. http://hg.python.org/cpython/rev/e14c860f6eee ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 16:10:35 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 May 2012 14:10:35 +0000 Subject: [issue14034] Add argparse howto In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za> Message-ID: <1336313435.91.0.579168451592.issue14034@psf.upfronthosting.co.za> Ezio Melotti added the comment: Committed, thanks for the patch! (Note that the example with "TypeError: unorderable types: NoneType() >= int()" works fine in Python 2 (by accident), and that I left it unchanged. Some error messages are also different on Python 2, but I left the ones from Python 3.) ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 16:17:07 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 May 2012 14:17:07 +0000 Subject: [issue14674] Add link to RFC 4627 from json documentation In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <1336313827.22.0.570245875878.issue14674@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 18:10:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 16:10:06 +0000 Subject: [issue14583] try/except import fails --without-threads In-Reply-To: <1334436331.01.0.461185960127.issue14583@psf.upfronthosting.co.za> Message-ID: <1336320606.64.0.883639383662.issue14583@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. The __import__ function's crazy API never ceases to amaze me. ---------- keywords: +patch nosy: +pitrou Added file: http://bugs.python.org/file25481/impstuff.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 18:11:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 16:11:42 +0000 Subject: [issue14583] try/except import fails --without-threads In-Reply-To: <1334436331.01.0.461185960127.issue14583@psf.upfronthosting.co.za> Message-ID: <1336320702.84.0.439167828536.issue14583@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file25481/impstuff.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 18:12:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 16:12:06 +0000 Subject: [issue14583] try/except import fails --without-threads In-Reply-To: <1334436331.01.0.461185960127.issue14583@psf.upfronthosting.co.za> Message-ID: <1336320726.87.0.333268764074.issue14583@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Oops, there was a duplicate test. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file25482/impstuff.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 18:13:05 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 06 May 2012 16:13:05 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1336320785.07.0.67353524324.issue14657@psf.upfronthosting.co.za> Brett Cannon added the comment: To respond to Nick's "yes, there are two copies of importlib._bootstrap" leanings, distutils2 has actually run into issues with this because they initially made some assumptions about consistency in what importlib returned vs. what import does (Arfrever can explain better than I can since he keeps pointing it out to me =). If using _frozen_importlib to bootstrap in importlib._bootstrap is looking bad, then I'm fine w/ simply having the tests for importlib and imp use importlib._bootstrap and otherwise just use _frozen_importlib for everything else since I have tried to be diligent to add any and all import-related tests to importlib. Except while developing the code should be exactly the same so hiding the details really won't make much of a difference in the very common case. If we go this route, though, then we really should take this time to do a proper context manager/decorator/whatever that covers all import state (including uncaching modules and sys.path_importer_cache) that we might care about and put the solution into test.support (what issue #14715 is asking for and I think is reasonable). We should also then add to regrtest detection of stuff left in sys.path_importer_cache or sys.modules that do not come from _frozen_importlib (which should help with the sporadic test_imp failure). ---------- dependencies: +test.support.DirsOnSysPath should be replaced by importlib.test.util.import_state _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 18:22:50 2012 From: report at bugs.python.org (Nurhusien Hasen) Date: Sun, 06 May 2012 16:22:50 +0000 Subject: [issue14674] Add link to RFC 4627 from json documentation In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <1336321370.05.0.63653582892.issue14674@psf.upfronthosting.co.za> Nurhusien Hasen added the comment: find python truste .net all serves ---------- nosy: +Nurhusien.Hasen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 18:24:00 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 06 May 2012 16:24:00 +0000 Subject: [issue14583] try/except import fails --without-threads In-Reply-To: <1334436331.01.0.461185960127.issue14583@psf.upfronthosting.co.za> Message-ID: <1336321440.61.0.280194133984.issue14583@psf.upfronthosting.co.za> Brett Cannon added the comment: Only two comments, otherwise LGTM (and I can't believe the solution was to go back through the import system just to pull out the cached module; the things we would change if we were doing this from scratch). One, you have some "XXX False" markers in the tests. Should those get deleted or replaced with something? Two, in your first test (at least) you only test what is in sys.modules once instead of after each attempted import. I would repeat the test after each import. ---------- assignee: -> pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 18:24:18 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 06 May 2012 16:24:18 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1336321458.34.0.111670330501.issue14657@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: It was distribute (fork of setuptools, with added support for Python 3), not distutils2. distribute has been changed to directly use _frozen_importlib: https://bitbucket.org/tarek/distribute/changeset/a2685f3af854 https://bitbucket.org/tarek/distribute/changeset/77c8b155a07d distribute checks __loader__ and __class__.__mro__ attributes of modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 18:32:00 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 16:32:00 +0000 Subject: [issue14583] try/except import fails --without-threads In-Reply-To: <1336321440.61.0.280194133984.issue14583@psf.upfronthosting.co.za> Message-ID: <1336321804.3336.6.camel@localhost.localdomain> Antoine Pitrou added the comment: > One, you have some "XXX False" markers in the tests. Should those get > deleted or replaced with something? Well, I don't know what to replace them with. I would have expected pkg.module to end up in sys.modules, but as mentioned in the comments the relative import line actually fails with an ImportError. There's probably some logic behind that, but that's beyond me. > Two, in your first test (at least) you only test what is in > sys.modules once instead of after each attempted import. I would > repeat the test after each import. Ok, will do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 18:33:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 16:33:10 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1336321458.34.0.111670330501.issue14657@psf.upfronthosting.co.za> Message-ID: <1336321873.3336.7.camel@localhost.localdomain> Antoine Pitrou added the comment: > It was distribute (fork of setuptools, with added support for Python 3), not distutils2. > distribute has been changed to directly use _frozen_importlib: This sounds like a rather good hint we need to avoid duplicate copies. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 18:35:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 16:35:45 +0000 Subject: [issue14583] try/except import fails --without-threads In-Reply-To: <1336321804.3336.6.camel@localhost.localdomain> Message-ID: <1336322030.3336.8.camel@localhost.localdomain> Antoine Pitrou added the comment: > > One, you have some "XXX False" markers in the tests. Should those get > > deleted or replaced with something? > > Well, I don't know what to replace them with. I would have expected > pkg.module to end up in sys.modules, but as mentioned in the comments > the relative import line actually fails with an ImportError. There's > probably some logic behind that, but that's beyond me. I should mention that the same happens with 2.7 and 3.2, so it's not a regression. It's just that I don't understand the logic :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 18:36:04 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 06 May 2012 16:36:04 +0000 Subject: [issue14695] Tools/parser/unparse.py is out of date. In-Reply-To: <1335728674.11.0.179577366721.issue14695@psf.upfronthosting.co.za> Message-ID: <1336322164.76.0.782344028423.issue14695@psf.upfronthosting.co.za> Mark Dickinson added the comment: Ah, that's good to know. I think I'll commit the fix and then look into hooking test_unparse into test_tools. For 3.2, it turns out that all that's missing is support for Starred. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 18:38:33 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 06 May 2012 16:38:33 +0000 Subject: [issue14695] Tools/parser/unparse.py is out of date. In-Reply-To: <1335728674.11.0.179577366721.issue14695@psf.upfronthosting.co.za> Message-ID: <1336322313.67.0.58141983448.issue14695@psf.upfronthosting.co.za> Mark Dickinson added the comment: Committed in revision c80576303892 (3.2), revision 89e928048903 (default). (I put 14965 instead of 14695 in the commit messages by mistake.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 19:10:05 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 06 May 2012 17:10:05 +0000 Subject: [issue14695] Tools/parser/unparse.py is out of date. In-Reply-To: <1335728674.11.0.179577366721.issue14695@psf.upfronthosting.co.za> Message-ID: <1336324205.81.0.481586524381.issue14695@psf.upfronthosting.co.za> Mark Dickinson added the comment: David: Any suggestions for how best to integrate test_unparse.py into test_tools? We could move the contents of test_unparse.py directly in test_tools.py and just kill the old test_unparse.py. Alternatively, we could import those TestCase subclasses from test_unparse; is there a better way of doing this than temporarily hacking sys.path to add the Tools/parser directory, as in the attached patch? ---------- Added file: http://bugs.python.org/file25483/test_unparse_in_test_tools.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 19:19:30 2012 From: report at bugs.python.org (Nurhusien Hasen) Date: Sun, 06 May 2012 17:19:30 +0000 Subject: [issue14674] Add link to RFC 4627 from json documentation In-Reply-To: <1336321370.05.0.63653582892.issue14674@psf.upfronthosting.co.za> Message-ID: Nurhusien Hasen added the comment: find python .org public all serves On 5/6/12, Nurhusien Hasen wrote: > > Nurhusien Hasen added the comment: > > find python truste .net all serves > > ---------- > nosy: +Nurhusien.Hasen > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 19:26:14 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 May 2012 17:26:14 +0000 Subject: [issue14674] Add link to RFC 4627 from json documentation In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <1336325174.03.0.836987826141.issue14674@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- Removed message: http://bugs.python.org/msg160089 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 19:26:19 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 May 2012 17:26:19 +0000 Subject: [issue14674] Add link to RFC 4627 from json documentation In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <1336325179.38.0.166629344583.issue14674@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- Removed message: http://bugs.python.org/msg160098 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 19:26:46 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 May 2012 17:26:46 +0000 Subject: [issue14674] Add link to RFC 4627 from json documentation In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <1336325206.49.0.967662140984.issue14674@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: -Nurhusien.Hasen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 19:31:09 2012 From: report at bugs.python.org (Trent Nelson) Date: Sun, 06 May 2012 17:31:09 +0000 Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za> Message-ID: <1336325469.83.0.543512825765.issue13241@psf.upfronthosting.co.za> Trent Nelson added the comment: > > "Once we fix this I can add the build slave" > I'm missing the context for this. Yeah I uh, ....seemed to have deleted the introductory sentence I wrote that said I was doing some prep work before adding an OS X 10.7 build slave. > Can't you override with environment variables or on the configure command itself? Are you referring to when I set up the build slave? i.e. tweak the local environment the build slave account runs under so that `./configure --with-pydebug` works out of the box? I don't think that's really a precedent we want to set (having build slave owners hack the local environment to work around build issues). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 19:39:09 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 06 May 2012 17:39:09 +0000 Subject: [issue14695] Tools/parser/unparse.py is out of date. In-Reply-To: <1335728674.11.0.179577366721.issue14695@psf.upfronthosting.co.za> Message-ID: <1336325949.32.0.259889524238.issue14695@psf.upfronthosting.co.za> R. David Murray added the comment: Since we are already doing path hackery in that test file to get things to run, I think your patch would be fine. If we grow more tests for the stuff in Tools (which would be good), we might want to consider reorganizing things, but for now I think that the simplest thing that works is good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 19:50:09 2012 From: report at bugs.python.org (Mark Shannon) Date: Sun, 06 May 2012 17:50:09 +0000 Subject: [issue12660] test_gdb fails when installed In-Reply-To: <1312038409.05.0.274432685937.issue12660@psf.upfronthosting.co.za> Message-ID: <1336326609.48.0.57551047243.issue12660@psf.upfronthosting.co.za> Mark Shannon added the comment: python-gdb.py was modified for the new dictionary implementation. Can you check that your 3.3 installation isn't using an earlier version of python-gdb.py? ---------- nosy: +Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 19:51:17 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 May 2012 17:51:17 +0000 Subject: [issue14654] Faster utf-8 decoding In-Reply-To: <1336244534.29.0.188785865082.issue14654@psf.upfronthosting.co.za> Message-ID: <1336326831.2525.129.camel@raxxla> Serhiy Storchaka added the comment: Martin, sorry to have wasted your time. I understand that you are busy, so I'm not too worried not receiving a feedback for ten days. > At this point, it appears that you don't intend to submit any of these patches for inclusion into Python. I'm at a loss. What causes such an impression? I quickly reacting to the comments, responding by the new patches. I take into account your comments, and if I do not agree, reinforce my opinion by the benchmarks. I suggest only cleaned and well-tested code. I provide tools for benchmarking. What am I doing wrong? May be my bad English has been misunderstood? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 20:00:55 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 May 2012 18:00:55 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding Message-ID: <1336327254.8.0.865225437508.issue14738@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : I propose a complex patch, which significantly speeds up UTF-8 decoding. Now decoder faster even decoder in 3.2 (except in a few unreal patological cases). Also the decoder code reduced and simplified (formerly decoding code was repeated in at least three places). As a side effect ASCII decoding now faster on some platforms (issue14419). Related issues: [issue4868] Faster utf-8 decoding [issue13417] faster utf-8 decoding [issue14419] Faster ascii decoding [issue14624] Faster utf-16 decoder [issue14625] Faster utf-32 decoder [issue14654] Faster utf-8 decoding Here are the results of benchmarking (numbers is speed in MB/s). On 32-bit Linux, AMD Athlon 64 X2 4600+ @ 2.4GHz: 3.2 3.3(vanilla) patched utf-8 'A'*10000 1199 (+69%) 1721 (+18%) 2032 utf-8 'A'*9999+'\x80' 1189 (+25%) 996 (+49%) 1488 utf-8 'A'*9999+'\u0100' 1192 (-25%) 887 (+1%) 894 utf-8 'A'*9999+'\u8000' 1178 (-24%) 888 (+0%) 890 utf-8 'A'*9999+'\U00010000' 1177 (-29%) 872 (-4%) 837 utf-8 '\x80'*10000 220 (+74%) 172 (+122%) 382 utf-8 '\x80'+'A'*9999 1192 (+5%) 376 (+232%) 1250 utf-8 '\x80'*9999+'\u0100' 220 (+54%) 160 (+112%) 339 utf-8 '\x80'*9999+'\u8000' 220 (+54%) 160 (+112%) 339 utf-8 '\x80'*9999+'\U00010000' 221 (+49%) 176 (+88%) 330 utf-8 '\u0100'*10000 220 (+74%) 163 (+134%) 382 utf-8 '\u0100'+'A'*9999 1177 (+4%) 382 (+219%) 1220 utf-8 '\u0100'+'\x80'*9999 220 (+74%) 163 (+134%) 382 utf-8 '\u0100'*9999+'\u8000' 220 (+74%) 163 (+134%) 382 utf-8 '\u0100'*9999+'\U00010000' 220 (+50%) 180 (+83%) 330 utf-8 '\u8000'*10000 261 (+66%) 191 (+126%) 432 utf-8 '\u8000'+'A'*9999 1197 (+1%) 384 (+216%) 1212 utf-8 '\u8000'+'\x80'*9999 216 (+77%) 163 (+134%) 382 utf-8 '\u8000'+'\u0100'*9999 215 (+77%) 164 (+132%) 381 utf-8 '\u8000'*9999+'\U00010000' 261 (+46%) 201 (+89%) 380 utf-8 '\U00010000'*10000 248 (+44%) 198 (+80%) 357 utf-8 '\U00010000'+'A'*9999 1192 (-5%) 383 (+196%) 1135 utf-8 '\U00010000'+'\x80'*9999 220 (+73%) 180 (+111%) 380 utf-8 '\U00010000'+'\u0100'*9999 220 (+73%) 180 (+111%) 380 utf-8 '\U00010000'+'\u8000'*9999 261 (+54%) 201 (+100%) 403 ascii 'A'*10000 233 (+971%) 1876 (+33%) 2496 On 32-bit Linux, Intel Atom N570 @ 1.66GHz: 3.2 3.3(vanilla) patched utf-8 'A'*10000 345 (+81%) 596 (+5%) 623 utf-8 'A'*9999+'\x80' 335 (+41%) 303 (+56%) 474 utf-8 'A'*9999+'\u0100' 336 (-23%) 123 (+110%) 258 utf-8 'A'*9999+'\u8000' 337 (-24%) 123 (+108%) 256 utf-8 'A'*9999+'\U00010000' 336 (-24%) 261 (-3%) 254 utf-8 '\x80'*10000 88 (+66%) 65 (+125%) 146 utf-8 '\x80'+'A'*9999 334 (+8%) 124 (+190%) 360 utf-8 '\x80'*9999+'\u0100' 88 (+43%) 65 (+94%) 126 utf-8 '\x80'*9999+'\u8000' 88 (+43%) 65 (+94%) 126 utf-8 '\x80'*9999+'\U00010000' 89 (+40%) 65 (+92%) 125 utf-8 '\u0100'*10000 88 (+85%) 65 (+151%) 163 utf-8 '\u0100'+'A'*9999 336 (+2%) 77 (+345%) 343 utf-8 '\u0100'+'\x80'*9999 88 (+86%) 65 (+152%) 164 utf-8 '\u0100'*9999+'\u8000' 88 (+86%) 65 (+152%) 164 utf-8 '\u0100'*9999+'\U00010000' 88 (+57%) 65 (+112%) 138 utf-8 '\u8000'*10000 98 (+79%) 69 (+154%) 175 utf-8 '\u8000'+'A'*9999 339 (+3%) 77 (+353%) 349 utf-8 '\u8000'+'\x80'*9999 89 (+84%) 66 (+148%) 164 utf-8 '\u8000'+'\u0100'*9999 88 (+86%) 65 (+152%) 164 utf-8 '\u8000'*9999+'\U00010000' 98 (+58%) 69 (+125%) 155 utf-8 '\U00010000'*10000 104 (+46%) 79 (+92%) 152 utf-8 '\U00010000'+'A'*9999 339 (-5%) 124 (+160%) 323 utf-8 '\U00010000'+'\x80'*9999 88 (+84%) 68 (+138%) 162 utf-8 '\U00010000'+'\u0100'*9999 88 (+83%) 68 (+137%) 161 utf-8 '\U00010000'+'\u8000'*9999 98 (+63%) 72 (+122%) 160 ascii 'A'*10000 132 (+499%) 758 (+4%) 791 ---------- components: Interpreter Core files: decode_utf8_4.patch keywords: patch messages: 160103 nosy: Arfrever, haypo, jcea, loewis, pitrou, storchaka priority: normal severity: normal status: open title: Amazingly faster UTF-8 decoding type: performance versions: Python 3.3 Added file: http://bugs.python.org/file25484/decode_utf8_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 20:30:06 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 May 2012 18:30:06 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding In-Reply-To: <1336327254.8.0.865225437508.issue14738@psf.upfronthosting.co.za> Message-ID: <1336329006.2.0.342387904791.issue14738@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Unicode nosy: +ezio.melotti stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 21:05:06 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 06 May 2012 19:05:06 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1336331106.6.0.0390815701026.issue14657@psf.upfronthosting.co.za> Brett Cannon added the comment: I think it's beyond a hint and says we need to find a solution or else other people will run into similar issues. And while I'm thinking about it, there is precedent for exposing modules under a different name than they are actually installed as in the system (e.g. os.path is posixpath), so I don't think we need to bend over backwards to mask every detail if the bootstrap solution is not taken (e.g. if we decided to just paper over _frozen_importlib we don't need to iterate over _frozen_importlib.__dict__ and patch up __module__). But I do think that we need to choose some solution to prevent this "forking" of code in the running interpreter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 21:24:32 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 06 May 2012 19:24:32 +0000 Subject: [issue14583] try/except import fails --without-threads In-Reply-To: <1334436331.01.0.461185960127.issue14583@psf.upfronthosting.co.za> Message-ID: <1336332272.74.0.0239666112587.issue14583@psf.upfronthosting.co.za> Brett Cannon added the comment: So I was going to try to figure out the logic, so I manually created the test files to start debugging, but I didn't get the ImportError but instead the 1/0 error for the relative import. Maybe it's specific to lack of threads or the change you made? I mean if that's how it has always worked then I'm not arguing that it's wrong, just that it's a weird side-effect: >>> import pkg Traceback (most recent call last): File "", line 1, in File "", line 977, in _find_and_load File "", line 596, in load_module File "", line 262, in module_for_loader_wrapper File "", line 484, in _load_module File "./pkg/__init__.py", line 3, in 1/0 ZeroDivisionError: division by zero [70552 refs] >>> import sys [70554 refs] >>> sys.modules['pkg'] Traceback (most recent call last): File "", line 1, in KeyError: 'pkg' [70462 refs] >>> sys.modules['pkg.module'] [70465 refs] >>> with open('pkg/__init__.py') as file: print(file.read()) ... from . import module #import pkg.module 1/0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 21:42:43 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 19:42:43 +0000 Subject: [issue14583] try/except import fails --without-threads In-Reply-To: <1336332272.74.0.0239666112587.issue14583@psf.upfronthosting.co.za> Message-ID: <1336333248.3371.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > So I was going to try to figure out the logic, so I manually created > the test files to start debugging, but I didn't get the ImportError > but instead the 1/0 error for the relative import. Maybe it's specific > to lack of threads or the change you made? I mean if that's how it has > always worked then I'm not arguing that it's wrong, just that it's a > weird side-effect: The first "import pkg" gets you a ImportError but the second one should get you a ZeroDivisionError (yes, weird). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 21:48:14 2012 From: report at bugs.python.org (Chris Rebert) Date: Sun, 06 May 2012 19:48:14 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1336333694.84.0.197127041402.issue13968@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 22:01:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 May 2012 20:01:02 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding In-Reply-To: <1336327254.8.0.865225437508.issue14738@psf.upfronthosting.co.za> Message-ID: <1336334462.79.0.814301184537.issue14738@psf.upfronthosting.co.za> Antoine Pitrou added the comment: 64-bit Linux, Intel Core i5 2500K: 3.2 3.3 patched utf-8 'A'*10000 2550 (+198%) 6828 (+11%) 7607 utf-8 'A'*9999+'\x80' 2501 (+118%) 2415 (+126%) 5456 utf-8 'A'*9999+'\u0100' 2501 (-20%) 2297 (-13%) 1996 utf-8 'A'*9999+'\u8000' 2494 (-14%) 2291 (-7%) 2133 utf-8 'A'*9999+'\U00010000' 2494 (-11%) 2293 (-3%) 2219 utf-8 '\x80'*10000 422 (+135%) 517 (+92%) 991 utf-8 '\x80'+'A'*9999 2513 (+12%) 860 (+228%) 2820 utf-8 '\x80'*9999+'\u0100' 426 (+102%) 525 (+64%) 862 utf-8 '\x80'*9999+'\u8000' 426 (+104%) 538 (+62%) 871 utf-8 '\x80'*9999+'\U00010000' 428 (+105%) 523 (+68%) 878 utf-8 '\u0100'*10000 425 (+140%) 517 (+97%) 1019 utf-8 '\u0100'+'A'*9999 2488 (+2%) 820 (+211%) 2549 utf-8 '\u0100'+'\x80'*9999 426 (+139%) 517 (+97%) 1019 utf-8 '\u0100'*9999+'\u8000' 426 (+139%) 529 (+93%) 1019 utf-8 '\u0100'*9999+'\U00010000' 426 (+106%) 509 (+72%) 876 utf-8 '\u8000'*10000 573 (+28%) 490 (+50%) 733 utf-8 '\u8000'+'A'*9999 2500 (+1%) 822 (+208%) 2528 utf-8 '\u8000'+'\x80'*9999 426 (+139%) 530 (+92%) 1018 utf-8 '\u8000'+'\u0100'*9999 428 (+138%) 509 (+100%) 1018 utf-8 '\u8000'*9999+'\U00010000' 573 (+17%) 447 (+51%) 673 utf-8 '\U00010000'*10000 562 (+24%) 552 (+26%) 696 utf-8 '\U00010000'+'A'*9999 2512 (+3%) 939 (+175%) 2584 utf-8 '\U00010000'+'\x80'*9999 423 (+140%) 553 (+84%) 1017 utf-8 '\U00010000'+'\u0100'*9999 426 (+139%) 549 (+85%) 1017 utf-8 '\U00010000'+'\u8000'*9999 572 (+18%) 479 (+41%) 674 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 23:10:03 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 06 May 2012 21:10:03 +0000 Subject: [issue14736] Add {encode, decode}_filter_properties() functions to lzma module In-Reply-To: <1336266483.84.0.291030499892.issue14736@psf.upfronthosting.co.za> Message-ID: <1336338603.79.0.285538376528.issue14736@psf.upfronthosting.co.za> Nadeem Vawda added the comment: Committed as changeset 9118ef2b651a. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 23:13:59 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 06 May 2012 21:13:59 +0000 Subject: [issue14366] Supporting lzma compression in zip files In-Reply-To: <1332112236.1.0.964135054036.issue14366@psf.upfronthosting.co.za> Message-ID: <1336338839.88.0.658687887354.issue14366@psf.upfronthosting.co.za> Nadeem Vawda added the comment: I've committed my patch as changeset 9118ef2b651a, adding functions encode_filter_properties and decode_filter_properties to the lzma module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 23:25:53 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 May 2012 21:25:53 +0000 Subject: [issue13116] setup.cfg in [sb]dists should be static In-Reply-To: <1317915762.54.0.969795427533.issue13116@psf.upfronthosting.co.za> Message-ID: <1336339553.11.0.741810397788.issue13116@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 23:26:32 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 May 2012 21:26:32 +0000 Subject: [issue14555] clock_gettime/settime/getres: Add more clock identifiers In-Reply-To: <1334183358.11.0.0329195703165.issue14555@psf.upfronthosting.co.za> Message-ID: <1336339592.29.0.755747965206.issue14555@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 23:48:11 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 May 2012 21:48:11 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding In-Reply-To: <1336334462.79.0.814301184537.issue14738@psf.upfronthosting.co.za> Message-ID: <1336341045.2525.135.camel@raxxla> Serhiy Storchaka added the comment: Thank your, Antoine. Finally Intel Core is defeated! If someone wants to repeat tests, see benchmark tools in issue14624. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 6 23:57:49 2012 From: report at bugs.python.org (Glenn Linderman) Date: Sun, 06 May 2012 21:57:49 +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: <1336341469.99.0.804496511632.issue14565@psf.upfronthosting.co.za> Glenn Linderman added the comment: Hi Pierre, Nice to see your name pop up again. Your suggestion is certainly simpler... but unfortunately, too much simpler. One reason, is that in configuring a path to contain CGI files, the CGI files are allowed to be there, or anywhere deeper in the tree. So configuring "/http/bin" should allow the CGI file to be any of: /http/bin/some.cgi /http/bin/application1/other.cgi /http/bin/app2/subapp/third.cgi and many more. The second reason, is that once /http/bin is determined to be the path prefix, then the search down the tree is done for the cgi file. Now let's say URL looks like: http://server.com/http/bin/app2/subapp/third.cgi/more/path/info/params It is appropriate to find third.cgi and execute it as a CGI file, and pass it as PATHINFO /more/path/info/params ! Yet, using your suggested over-simplification, "params" would be considered the CGI file (if it even exists), and /http/bin/app2/subapp/third.cgi/more/path/info certainly wouldn't exactly match /http/bin... so neither params nor third.cgi would get a chance to be executed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 00:11:08 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 May 2012 22:11:08 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding In-Reply-To: <1336327254.8.0.865225437508.issue14738@psf.upfronthosting.co.za> Message-ID: <1336342268.02.0.932414871191.issue14738@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch updated in accordance with Antoine cosmetic comments. ---------- Added file: http://bugs.python.org/file25485/decode_utf8_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 00:27:42 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 May 2012 22:27:42 +0000 Subject: [issue14072] urlparse on tel: URI-s misses the scheme in some cases In-Reply-To: <1329817524.78.0.223656665156.issue14072@psf.upfronthosting.co.za> Message-ID: <1336343262.03.0.732962569277.issue14072@psf.upfronthosting.co.za> Ezio Melotti added the comment: Here's a possible patch. The problem is that urlsplit (in Lib/urllib/parse.py:348) tries to convert the part after the : (in this case +31-641044153 and +31641044153) to int to see if it's a port number. This doesn't work with +31-641044153, but it does with +31-641044153. In the patch I'm assuming that the port number can only contain ascii digits (no leading '+/-', no spaces, no non-ascii digits) and checking for it explicitly, rather than using int() in a try/except. ---------- keywords: +patch nosy: +ezio.melotti stage: -> patch review Added file: http://bugs.python.org/file25486/issue14072.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 00:31:14 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 May 2012 22:31:14 +0000 Subject: [issue6602] BaseHTTPServer log_message should log to sys.stdout In-Reply-To: <1248952406.18.0.680079792557.issue6602@psf.upfronthosting.co.za> Message-ID: <1336343474.72.0.387084827137.issue6602@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy versions: +Python 3.3 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 00:32:35 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 May 2012 22:32:35 +0000 Subject: [issue9559] mailbox.mbox creates new file when adding message to mbox In-Reply-To: <1281458408.75.0.432136903483.issue9559@psf.upfronthosting.co.za> Message-ID: <1336343555.41.0.424359036991.issue9559@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> needs patch versions: +Python 3.3 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 00:36:43 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 May 2012 22:36:43 +0000 Subject: [issue13659] Add a help() viewer for IDLE's Shell. In-Reply-To: <1324707815.11.0.534121320744.issue13659@psf.upfronthosting.co.za> Message-ID: <1336343803.87.0.272849482377.issue13659@psf.upfronthosting.co.za> Ezio Melotti added the comment: I don't think adding a "browser" arg to help() is a good idea. The original suggestion of having the help in a separate window and adding a checkbox in the options to (de)activate the feature sounds good to me (it could even allow to select between normal/new window/browser). ---------- nosy: +ezio.melotti stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 00:40:40 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 May 2012 22:40:40 +0000 Subject: [issue14426] date format problem in Cookie/http.cookies In-Reply-To: <1332869878.62.0.0507950246068.issue14426@psf.upfronthosting.co.za> Message-ID: <1336344040.05.0.498578447998.issue14426@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 00:42:45 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 May 2012 22:42:45 +0000 Subject: [issue12541] Accepting Badly formed headers in urllib HTTPBasicAuth In-Reply-To: <1310478499.65.0.178767259424.issue12541@psf.upfronthosting.co.za> Message-ID: <1336344165.32.0.308506017878.issue12541@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 00:44:47 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 May 2012 22:44:47 +0000 Subject: [issue4333] Reworked Dialog.py In-Reply-To: <1226881404.91.0.533308530681.issue4333@psf.upfronthosting.co.za> Message-ID: <1336344287.93.0.399011331948.issue4333@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 00:50:02 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 May 2012 22:50:02 +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: <1336344602.38.0.49233074943.issue9374@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> needs patch versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 01:05:28 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 May 2012 23:05:28 +0000 Subject: [issue14736] Add {encode, decode}_filter_properties() functions to lzma module In-Reply-To: <1336266483.84.0.291030499892.issue14736@psf.upfronthosting.co.za> Message-ID: <1336345528.41.0.868231189346.issue14736@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you, Nadeem Vawda. I also wrote a patch for this, but because of the lack of experience it was too cumbersome. But there are no tests for these functions. I tried to use these functions and got the random values. >>> lzma.decode_filter_properties(lzma.FILTER_LZMA1, lzma.encode_filter_properties({'id': lzma.FILTER_LZMA1, 'preset': 6})) {'mode': 3075124424, 'dict_size': 8388608, 'id': 4611686018427387905, 'lp': 0, 'nice_len': 739426833, 'depth': 0, 'lc': 3, 'mf': 0, 'pb': 2} >>> lzma.decode_filter_properties(lzma.FILTER_LZMA1, lzma.encode_filter_properties({'id': lzma.FILTER_LZMA1, 'preset': 6})) {'mode': 0, 'dict_size': 8388608, 'id': 4611686018427387905, 'lp': 0, 'nice_len': 2053908595, 'depth': 0, 'lc': 3, 'mf': 0, 'pb': 2} >>> lzma.decode_filter_properties(lzma.FILTER_LZMA1, lzma.encode_filter_properties({'id': lzma.FILTER_LZMA1, 'preset': 6})) {'mode': 0, 'dict_size': 8388608, 'id': 4611686018427387905, 'lp': 0, 'nice_len': 2053908595, 'depth': 0, 'lc': 3, 'mf': 0, 'pb': 2} It seems, 'mode' and 'nice_len' was not initialized. Tests for zipfile module with the use of these functions are broken, and I don't know, this happens because of errors in these functions or in zipfile module. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 03:04:21 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 07 May 2012 01:04:21 +0000 Subject: [issue14703] Update PEP metaprocesses to describe PEP czar role In-Reply-To: <1335836124.46.0.0512543168568.issue14703@psf.upfronthosting.co.za> Message-ID: <1336352661.96.0.210943012538.issue14703@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 03:56:04 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 07 May 2012 01:56:04 +0000 Subject: [issue14735] Version 3.2.3 IDLE CTRL-Z plus Carriage Return to end does not work In-Reply-To: <1336252501.23.0.54042826511.issue14735@psf.upfronthosting.co.za> Message-ID: <1336355764.52.0.813991137093.issue14735@psf.upfronthosting.co.za> R. David Murray added the comment: Making idle work with ctl-Z+enter might be reasonable. However, can you describe more fully the documentation that led you believe that would work? ctl-Z+enter is for the CMD window, not IDLE, to my understanding. ---------- nosy: +r.david.murray, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 06:12:40 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 07 May 2012 04:12:40 +0000 Subject: [issue14735] Version 3.2.3 IDLE CTRL-Z plus Carriage Return to end does not work In-Reply-To: <1336252501.23.0.54042826511.issue14735@psf.upfronthosting.co.za> Message-ID: <1336363960.46.0.0455058378244.issue14735@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Using ^Z (ascii Substitute char) instead of ^D (ascii 'End of Transmission') is an MSDOS affectation carried over to the the MSDOS-based text-mode Command Prompt on Windows. I verified that ^D now closes IDLE on Windows. ^Z gives a beep. (I do not know about 2.7. It needs to be checked.) I also see that the IDLE Help document still says "Control-d sends end-of-file; closes window if typed at >>> prompt (this is Control-z on Windows)." so you are right to be confused. I do not know when the change was made, but I presume it was intentional as ^D is standard and most Windows users have no experience with MSDOS and ^Z. (It does not close Windows gui applications that I know of, nor does ^D usually.) So my inclination is to just remove the note (after checking 2.7.3 behavior) and not change the code. ---------- nosy: +serwy versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 07:11:22 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Mon, 07 May 2012 05:11:22 +0000 Subject: [issue14736] Add {encode, decode}_filter_properties() functions to lzma module In-Reply-To: <1336266483.84.0.291030499892.issue14736@psf.upfronthosting.co.za> Message-ID: <1336367482.73.0.0426261235366.issue14736@psf.upfronthosting.co.za> Nadeem Vawda added the comment: Changeset 9118ef2b651a was broken, but the bug should have been fixed by changeset 10ccbb90a8e9. Which revision have you been using? > But there are no tests for these functions. There *are* tests for these functions, and they were failing on some of the buildbots for the original changeset. They are currently passing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 08:14:13 2012 From: report at bugs.python.org (Pierre Quentel) Date: Mon, 07 May 2012 06:14:13 +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: <1336371253.84.0.553175626218.issue14565@psf.upfronthosting.co.za> Pierre Quentel added the comment: Thanks for the explanation I still think that the patch can be simplified, not using path lengths and the "found" flag collapsed_path = _url_collapse_path(self.path) for head in self.cgi_directories: if head==collapsed_path: self.cgi_info = (head,'') return True elif collapsed_path.startswith(head) \ and collapsed_path[len(head)]=='/': self.cgi_info = head, collapsed_path[len(head)+1:] return True return False BTW the last "return False" is rather useless since is_cgi() is only used in tests like "if is_cgi()" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 08:50:04 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 07 May 2012 06:50:04 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1336373404.51.0.688970379347.issue14657@psf.upfronthosting.co.za> Nick Coghlan added the comment: In that case, how about we go with: 1. By default, importlib._bootstrap is never imported. Instead, it is set to be a reference to _frozen_importlib. However, _frozen_importlib does *not* lie about where it came from (and doesn't assume the on-disk source matches the frozen source). 2. We provide two private functions in importlib.__init__: one that replaces all _frozen_importlib references in the import state with importlib._bootstrap references (retrieving the latter from disk first), and one that reverses the process. Note that the __import__ builtin should be replaced as well, since that will otherwise call in to the frozen version of the module. This is basically the same as Eric Snow's suggestion, just with most of the nuts and bolts kept within importlib, so that the testing context manager doesn't need to know the details - it can just call the appropriate importlib functions to change the active implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 10:03:14 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 07 May 2012 08:03:14 +0000 Subject: [issue14034] Add argparse howto In-Reply-To: <1336313435.91.0.579168451592.issue14034@psf.upfronthosting.co.za> Message-ID: Tshepang Lekhonkhobe added the comment: thanks so much for your rime in reviewing and committing ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 10:47:50 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 May 2012 08:47:50 +0000 Subject: [issue14736] Add {encode, decode}_filter_properties() functions to lzma module In-Reply-To: <1336367482.73.0.0426261235366.issue14736@psf.upfronthosting.co.za> Message-ID: <1336380623.2339.11.camel@raxxla> Serhiy Storchaka added the comment: > Changeset 9118ef2b651a was broken, but the bug should have been fixed by > changeset 10ccbb90a8e9. Which revision have you been using? I used the revision 76809:ab57e29157bb. Yes, now the bug fixed. Thank you once again. ---------- title: Add {encode,decode}_filter_properties() functions to lzma module -> Add {encode, decode}_filter_properties() functions to lzma module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 11:27:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 May 2012 09:27:31 +0000 Subject: [issue14695] Tools/parser/unparse.py is out of date. In-Reply-To: <1335728674.11.0.179577366721.issue14695@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f9344a3eaaa6 by Mark Dickinson in branch 'default': Issue #14695: Run Tools/parser/test_unparse.py as part of test_tools. http://hg.python.org/cpython/rev/f9344a3eaaa6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 11:27:57 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 May 2012 09:27:57 +0000 Subject: [issue14695] Tools/parser/unparse.py is out of date. In-Reply-To: <1335728674.11.0.179577366721.issue14695@psf.upfronthosting.co.za> Message-ID: <1336382877.59.0.30459771923.issue14695@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks, David! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 11:35:09 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 May 2012 09:35:09 +0000 Subject: [issue14739] Add PyArg_Parse format unit like O& but providing context Message-ID: <1336383309.79.0.581336532675.issue14739@psf.upfronthosting.co.za> New submission from Larry Hastings : If you write a PyArg_Parse "converter", and your conversion hits an error, you must raise an exception and error out. But, since your converter has no context about the parameter, it can't provide any helpful information in the error. For example, PyUnicode_FSConverter attempts to convert a PyUnicode object to a PyBytes object; if it gets back some other kind of object, it calls PyErr_SetString(PyExc_TypeError, "encoder failed to return bytes"); What parameter did this happen with? When calling what function? The hapless programmer is forced to guess. In practice, the argument parser generally knows the name of the function and the name of the parameter. It'd be nice to encode those values in the error. But that information isn't passed in to the converter. I propose adding a new format unit, let's call it 'O%', which is identical to 'O&' except for the signature of the converter function: int converter(PyObject *o, void *p, PyConverterContext_t *context); where PyConverterContext_t is defined as typedef struct { char *function_name; char *parameter_name; } PyConverterContext_t; If the function name or parameter name is not known, it will be NULL. ---------- messages: 160125 nosy: larry priority: normal severity: normal status: open title: Add PyArg_Parse format unit like O& but providing context _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 11:35:36 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 May 2012 09:35:36 +0000 Subject: [issue14739] Add PyArg_Parse format unit like O& but providing context In-Reply-To: <1336383309.79.0.581336532675.issue14739@psf.upfronthosting.co.za> Message-ID: <1336383336.55.0.863797911164.issue14739@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- assignee: -> larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 11:36:37 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 May 2012 09:36:37 +0000 Subject: [issue14739] Add PyArg_Parse format unit like O& but providing context In-Reply-To: <1336383309.79.0.581336532675.issue14739@psf.upfronthosting.co.za> Message-ID: <1336383397.33.0.972233811386.issue14739@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- components: +Interpreter Core stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 11:37:46 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 May 2012 09:37:46 +0000 Subject: [issue9530] integer undefined behaviors In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset c9c2031cf16d by Mark Dickinson in branch 'default': Add John Regehr to Misc/ACKS for his help with finding integer overflows (issue #9530). http://hg.python.org/cpython/rev/c9c2031cf16d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 11:45:44 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 May 2012 09:45:44 +0000 Subject: [issue14705] Add 'bool' format character to PyArg_ParseTuple* In-Reply-To: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e4617650f006 by Larry Hastings in branch 'default': Issue #14705: Added support for the new 'p' format unit to skipitem(). http://hg.python.org/cpython/rev/e4617650f006 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 12:00:11 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 May 2012 10:00:11 +0000 Subject: [issue14739] Add PyArg_Parse format unit like O& but providing context In-Reply-To: <1336383309.79.0.581336532675.issue14739@psf.upfronthosting.co.za> Message-ID: <1336384811.51.0.172160034481.issue14739@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It would be better if the functions PyArg_Parse* were wrapped converter's exception, in other exception with adding the names of function and parameter in the message. This will save us from necessity of the introduction of the new interface and immediately give effect to the old code. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 12:08:23 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 May 2012 10:08:23 +0000 Subject: [issue14695] Tools/parser/unparse.py is out of date. In-Reply-To: <1335728674.11.0.179577366721.issue14695@psf.upfronthosting.co.za> Message-ID: <1336385303.72.0.593191230639.issue14695@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 12:15:28 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 May 2012 10:15:28 +0000 Subject: [issue14722] Overflow in parsing 'float' parameters in PyArg_ParseTuple* In-Reply-To: <1336142237.23.0.0183531993231.issue14722@psf.upfronthosting.co.za> Message-ID: <1336385728.57.0.29654491157.issue14722@psf.upfronthosting.co.za> Mark Dickinson added the comment: Closing as "won't fix"; Python is sadly far from consistent about returning infinity versus raising OverflowError, in a wide variety of situations. For example, compare: * float(Decimal('1e310')) with float(Fraction('1e310')), or * struct.pack('f', 1e100) with struct.pack(' wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 12:21:11 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 May 2012 10:21:11 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335804926.58.0.135059540144.issue14700@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 064c2d0483f8 by Mark Dickinson in branch 'default': Issue #14700: Fix two broken and undefined-behaviour-inducing overflow checks in old-style string formatting. Thanks Serhiy Storchaka for report and original patch. http://hg.python.org/cpython/rev/064c2d0483f8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 12:22:00 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 May 2012 10:22:00 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335804926.58.0.135059540144.issue14700@psf.upfronthosting.co.za> Message-ID: <1336386120.24.0.571944786451.issue14700@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 12:26:52 2012 From: report at bugs.python.org (Mike Meyer) Date: Mon, 07 May 2012 10:26:52 +0000 Subject: [issue13697] python RLock implementation unsafe with signals In-Reply-To: <1325538793.4.0.376965160112.issue13697@psf.upfronthosting.co.za> Message-ID: <1336386412.53.0.732556015439.issue13697@psf.upfronthosting.co.za> Mike Meyer added the comment: I just ran into this issue in the logging module using 2.7. Here's the TB in case it sheds any light on the issue Traceback (most recent call last): File "./crawler.py", line 531, in main(argv[1:]1:) File "./crawler.py", line 522, in main MCP(config).run() File "./crawler.py", line 332, in run self.reaper() File "./crawler.py", line 359, in reaper logging.debug('MCP process alive: %s', state) File "/usr/local/lib/python2.7/logging/__init__.py", line 1600, in debug root.debug(msg, *args, **kwargs) File "/usr/local/lib/python2.7/logging/__init__.py", line 1120, in debug self._log(DEBUG, msg, args, **kwargs) File "/usr/local/lib/python2.7/logging/__init__.py", line 1250, in _log self.handle(record) File "/usr/local/lib/python2.7/logging/__init__.py", line 1260, in handle self.callHandlers(record) File "/usr/local/lib/python2.7/logging/__init__.py", line 1300, in callHandlers hdlr.handle(record) File "/usr/local/lib/python2.7/logging/__init__.py", line 746, in handle self.release() File "/usr/local/lib/python2.7/logging/__init__.py", line 700, in release self.lock.release() File "/usr/local/lib/python2.7/threading.py", line 147, in release self.__block.release() thread.error: release unlocked lock Since I'm not using threads, getting thread errors was a little bit of a surprise. I guess trying to make the logging module thread safe added a potential bug. ---------- nosy: +Mike.Meyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 12:35:27 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 07 May 2012 10:35:27 +0000 Subject: [issue14722] Overflow in parsing 'float' parameters in PyArg_ParseTuple* In-Reply-To: <1336385728.57.0.29654491157.issue14722@psf.upfronthosting.co.za> Message-ID: <20120507103526.GA809@sleipnir.bytereef.org> Stefan Krah added the comment: I agree. Fixing all this would probably require a PEP. It looks like the original plan was to provide a facility to turn off the Overflow exception: http://mail.python.org/pipermail/python-dev/2000-May/003990.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 12:45:55 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 07 May 2012 10:45:55 +0000 Subject: [issue14739] Add PyArg_Parse format unit like O& but providing context In-Reply-To: <1336383309.79.0.581336532675.issue14739@psf.upfronthosting.co.za> Message-ID: <1336387555.98.0.832554078309.issue14739@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- nosy: +georg.brandl, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 13:03:24 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 May 2012 11:03:24 +0000 Subject: [issue14701] parser module doesn't support 'raise ... from' In-Reply-To: <1335812123.91.0.810471517196.issue14701@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset fc17f70292f6 by Mark Dickinson in branch '3.2': Issue #14701: Add missing support for 'raise ... from' in parser module. http://hg.python.org/cpython/rev/fc17f70292f6 New changeset 0dd0d56bdcc1 by Mark Dickinson in branch 'default': Issue #14701: Merge fix from 3.2. http://hg.python.org/cpython/rev/0dd0d56bdcc1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 13:05:21 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 07 May 2012 11:05:21 +0000 Subject: [issue14588] PEP 3115 compliant dynamic class creation In-Reply-To: <1334535798.87.0.826104374353.issue14588@psf.upfronthosting.co.za> Message-ID: <1336388721.86.0.512190739589.issue14588@psf.upfronthosting.co.za> Nick Coghlan added the comment: In going to add documentation for your patch, I realised the operator module is not the right place for this. The "types" module actually seems like the most appropriate home, but that will require adding a _types module to back it. I'll post to python-dev to get additional feedback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 13:07:56 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 May 2012 11:07:56 +0000 Subject: [issue14701] parser module doesn't support 'raise ... from' In-Reply-To: <1335812123.91.0.810471517196.issue14701@psf.upfronthosting.co.za> Message-ID: <1336388876.79.0.820801536675.issue14701@psf.upfronthosting.co.za> Mark Dickinson added the comment: Now fixed. Terry: I suggest opening a separate doc issue for the 'CPython-specific' issue ---------- assignee: -> mark.dickinson components: +Library (Lib) resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 13:08:11 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 May 2012 11:08:11 +0000 Subject: [issue14716] Use unicode_writer API for str.format() In-Reply-To: <1336082896.6.0.108889213788.issue14716@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 7be716a47e9d by Victor Stinner in branch 'default': Close #14716: str.format() now uses the new "unicode writer" API instead of the http://hg.python.org/cpython/rev/7be716a47e9d New changeset ab500b297900 by Victor Stinner in branch 'default': Issue #14716: Change integer overflow check in unicode_writer_prepare() http://hg.python.org/cpython/rev/ab500b297900 ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 13:09:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 May 2012 11:09:46 +0000 Subject: [issue6602] BaseHTTPServer log_message should log to sys.stdout In-Reply-To: <1248952406.18.0.680079792557.issue6602@psf.upfronthosting.co.za> Message-ID: <1336388986.68.0.302239661148.issue6602@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Disagreed. sys.stderr is not only for "errors" but all informational messages of little value (warnings, debug messages etc.). Also, logging to two different streams makes redirecting clumsier. If you want to change this, it would more useful to add a facility to allow users to choose output streams. Or even - shocking idea - to integrate the logging module in BaseHTTPServer. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 13:19:11 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 07 May 2012 11:19:11 +0000 Subject: [issue9177] ssl.read/write on closed socket raises AttributeError In-Reply-To: <1278409980.47.0.00506027612669.issue9177@psf.upfronthosting.co.za> Message-ID: <1336389551.94.0.105987564354.issue9177@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, pitrou stage: -> needs patch versions: +Python 3.3 -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 13:38:16 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 07 May 2012 11:38:16 +0000 Subject: [issue11477] Bug in code dispatching based on internal slots In-Reply-To: <1299965091.63.0.267715976543.issue11477@psf.upfronthosting.co.za> Message-ID: <1336390696.97.0.197405787258.issue11477@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm currently planning to postpone fixing this until 3.4. However, if someone else wants to pick it up for 3.3, go ahead. ---------- assignee: ncoghlan -> versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 13:40:43 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 07 May 2012 11:40:43 +0000 Subject: [issue5251] contextlib.nested inconsistent with, well, nested with statements due exceptions raised in __enter__ In-Reply-To: <1234548570.86.0.145574171135.issue5251@psf.upfronthosting.co.za> Message-ID: <1336390843.75.0.201151665661.issue5251@psf.upfronthosting.co.za> Nick Coghlan added the comment: Superseded by issue 13585 (which will add an improved dynamic context management API) ---------- resolution: postponed -> out of date status: open -> closed superseder: -> Add contextlib.ExitStack _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 13:41:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 May 2012 11:41:35 +0000 Subject: [issue9177] ssl.read/write on closed socket raises AttributeError In-Reply-To: <1278409980.47.0.00506027612669.issue9177@psf.upfronthosting.co.za> Message-ID: <1336390895.89.0.658255970323.issue9177@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't think mimicking EBADF is very useful. Reading from a closed socket is usually a programming error, so it's not the kind of error you'll want to catch at runtime. AttributeError may not be very pretty though, so perhaps a ValueError can be raised as with closed files: >>> f = open("LICENSE") >>> f.close() >>> f.read() Traceback (most recent call last): File "", line 1, in ValueError: I/O operation on closed file. ---------- type: behavior -> enhancement versions: -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 14:05:37 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 07 May 2012 12:05:37 +0000 Subject: [issue1294232] Error in metaclass search order Message-ID: <1336392337.27.0.000463289543372.issue1294232@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: ncoghlan -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 14:14:16 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 May 2012 12:14:16 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335804926.58.0.135059540144.issue14700@psf.upfronthosting.co.za> Message-ID: <1336392856.43.0.409053141696.issue14700@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Mark, I deliberately have not used the exact formula for the overflow. Comparison with the constant is much cheaper than division or multiplication. Microbencmark: ./python -m timeit -s 'f="%.1234567890s"*100;x=("",)*100' 'f%x' Before changeset 064c2d0483f8: 10000 loops, best of 3: 27.1 usec per loop Changeset 064c2d0483f8: 10000 loops, best of 3: 25.7 usec per loop Original patch: 100000 loops, best of 3: 18.2 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 14:21:09 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 May 2012 12:21:09 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335804926.58.0.135059540144.issue14700@psf.upfronthosting.co.za> Message-ID: <1336393269.05.0.506931220694.issue14700@psf.upfronthosting.co.za> Mark Dickinson added the comment: Sure, I realize that, but I prefer not to be sloppy in the overflow check, and to use the same formula that's already used in stringlib. I somehow doubt that this micro-optimization is going to have any noticeable effect in real code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 14:31:16 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 May 2012 12:31:16 +0000 Subject: [issue14722] Overflow in parsing 'float' parameters in PyArg_ParseTuple* In-Reply-To: <1336142237.23.0.0183531993231.issue14722@psf.upfronthosting.co.za> Message-ID: <1336393876.54.0.0252576965318.issue14722@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be proposed tests (except for the overflow) would be helpful? Right now 'f' and 'd' parsing code is not covered by tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 15:36:33 2012 From: report at bugs.python.org (Bob Glickstein) Date: Mon, 07 May 2012 13:36:33 +0000 Subject: [issue14740] get_payload(n, True) returns None Message-ID: <1336397793.0.0.246147056664.issue14740@psf.upfronthosting.co.za> New submission from Bob Glickstein : Passing both a value for i and decode=True to email.message.Message.get_payload(), when self is a multipart, returns None when it should return a string. The reason is that an is_multipart() test is done on self when it should instead be done on the selected payload part. Here's a patch that fixes this: --- /usr/lib64/python2.7/email/message.py 2011-10-26 18:40:36.000000000 -0700 +++ /home/bobg/tmp/message.py 2012-05-07 06:34:28.579401481 -0700 @@ -192,9 +192,9 @@ else: payload = self._payload[i] if decode: - if self.is_multipart(): + if payload.is_multipart(): return None - cte = self.get('content-transfer-encoding', '').lower() + cte = payload.get('content-transfer-encoding', '').lower() if cte == 'quoted-printable': return utils._qdecode(payload) elif cte == 'base64': ---------- components: Library (Lib) messages: 160144 nosy: Bob.Glickstein priority: normal severity: normal status: open title: get_payload(n, True) returns None type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 15:37:45 2012 From: report at bugs.python.org (Bob Glickstein) Date: Mon, 07 May 2012 13:37:45 +0000 Subject: [issue14740] get_payload(n, True) returns None In-Reply-To: <1336397793.0.0.246147056664.issue14740@psf.upfronthosting.co.za> Message-ID: <1336397865.2.0.182468448387.issue14740@psf.upfronthosting.co.za> Bob Glickstein added the comment: Incidentally, a workaround is: msg.get_payload(n).get_payload(decode=True) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 15:57:48 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 07 May 2012 13:57:48 +0000 Subject: [issue14740] get_payload(n, True) returns None In-Reply-To: <1336397793.0.0.246147056664.issue14740@psf.upfronthosting.co.za> Message-ID: <1336399068.44.0.819813694414.issue14740@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the report and patch suggestion, but... This is actually the way it is designed to work. get_payload(i) returns the ith element of a multipart payload. Your workaround is in fact the correct way to do this operation. decode=True is documented to return None if is_multipart is True. You will note that if decode=False, you get back the Message sub-object, not a string. Since decoding a Message object (as opposed to its payload) is not a meaningful operation, None is returned for decode=True. Arguably we should raise a TypeError or ValueError instead, but we don't for historical reasons. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 17:01:38 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 07 May 2012 15:01:38 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1336402898.09.0.459727646619.issue14657@psf.upfronthosting.co.za> Brett Cannon added the comment: Should we have a separate context manager for this, or just make it a flag for a unified import_state() decorator? Or do we want to *always* force the use of the Python code instead of the frozen code? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 17:05:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 May 2012 15:05:29 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1336402898.09.0.459727646619.issue14657@psf.upfronthosting.co.za> Message-ID: <1336403010.3352.5.camel@localhost.localdomain> Antoine Pitrou added the comment: > Should we have a separate context manager for this, or just make it a > flag for a unified import_state() decorator? Or do we want to *always* > force the use of the Python code instead of the frozen code? Ideally, we would want to test both versions, so that any oddity in the freezing mechanism gets exercised and diagnosed properly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 17:11:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 May 2012 15:11:02 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1336403462.2.0.417953582947.issue14657@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Ideally, we would want to test both versions, so that any oddity in the > freezing mechanism gets exercised and diagnosed properly. (not to mention the speedups in import.c) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 17:23:05 2012 From: report at bugs.python.org (Eric Snow) Date: Mon, 07 May 2012 15:23:05 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1336404185.35.0.781702256856.issue14657@psf.upfronthosting.co.za> Eric Snow added the comment: I'm +1 on Nick's recommendation. @Antoine > Ideally, we would want to test both versions, so that any oddity in > the freezing mechanism gets exercised and diagnosed properly. +1 Does this mean that the whole test suite should be run under both (whenever _bootstrap.py is modified)? Would that warrant a new flag for the test suite or even an automated check? That's what I was getting at with this: > 1. python starts up normally. > 2. we clear out all the entire import state except for builtins. > 3. we stick importlib._bootstrap in place. > 4. we set builtins.__import__ to importlib.__import__. > 5. we re-populate sys.modules by reloading all the modules that > were in there before (?). > 6. we run the test suite against this new import state. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 17:27:05 2012 From: report at bugs.python.org (fishdude) Date: Mon, 07 May 2012 15:27:05 +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: <1336404425.7.0.657238440179.issue4508@psf.upfronthosting.co.za> fishdude added the comment: i have to report that this issue also happens on Linux and Mac as well. no matter wether python 2.6 or 2.7 is used. ---------- components: +Macintosh nosy: +fishdude versions: +Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 17:36:47 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 May 2012 15:36:47 +0000 Subject: [issue14697] parser module doesn't support set displays or set comprehensions In-Reply-To: <1335735898.27.0.486602524616.issue14697@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 129289144dfb by Mark Dickinson in branch '3.2': Issue #14697: Fix missing parser module support for set displays and set comprehensions. http://hg.python.org/cpython/rev/129289144dfb New changeset 4815a4a4a852 by Mark Dickinson in branch 'default': Issue #14697: Merge fix from 3.2. http://hg.python.org/cpython/rev/4815a4a4a852 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 17:37:34 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 May 2012 15:37:34 +0000 Subject: [issue14697] parser module doesn't support set displays or set comprehensions In-Reply-To: <1335735898.27.0.486602524616.issue14697@psf.upfronthosting.co.za> Message-ID: <1336405054.56.0.47408760097.issue14697@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: -> mark.dickinson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 17:42:31 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 07 May 2012 15:42:31 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1336405351.06.0.455127553331.issue14657@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: It might be sufficient to only run tests from the following files with both importlib._bootstrap and _frozen_importlib: test_imp.py test_import.py test_importhooks.py test_importlib.py test_pkgimport.py test_threaded_import.py test_zipimport.py test_zipimport_support.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 17:47:04 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 May 2012 15:47:04 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1336405351.06.0.455127553331.issue14657@psf.upfronthosting.co.za> Message-ID: <1336405506.3352.8.camel@localhost.localdomain> Antoine Pitrou added the comment: > It might be sufficient to only run tests from the following files with > both importlib._bootstrap and _frozen_importlib: I was only thinking about test_importlib myself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 17:54:36 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 May 2012 15:54:36 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1336393269.05.0.506931220694.issue14700@psf.upfronthosting.co.za> Message-ID: <1336406228.2362.4.camel@raxxla> Serhiy Storchaka added the comment: > I somehow doubt that this micro-optimization is going to have any noticeable effect in real code. Agree. I just found this bug, trying to optimize the code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 18:07:47 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 07 May 2012 16:07: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: <1336406867.62.0.307829415119.issue4508@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the confirmation. Note that the versions field in this bug tracker indicates the versions that will get fixed, not all versions with the bug; 2.6 only gets security fixes now. Are you interested in updating the patch with a test (see my previous messages)? ---------- assignee: tarek -> eric.araujo components: +Distutils2 -Extension Modules, Macintosh, Windows nosy: +alexis versions: +3rd party -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 18:18:43 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 May 2012 16:18:43 +0000 Subject: [issue14741] parser module doesn't support Ellipsis. Message-ID: <1336407523.58.0.0696113570093.issue14741@psf.upfronthosting.co.za> New submission from Mark Dickinson : Here's a simple patch. With this and other recent patches to the parser module, we can now correctly roundtrip all the (valid) Python files in Lib/ and Lib/test/. ---------- assignee: mark.dickinson components: Library (Lib) files: parser_ellipsis.patch keywords: patch messages: 160157 nosy: mark.dickinson priority: normal severity: normal stage: needs patch status: open title: parser module doesn't support Ellipsis. type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25487/parser_ellipsis.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 18:25:24 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 May 2012 16:25:24 +0000 Subject: [issue14741] parser module doesn't support Ellipsis. In-Reply-To: <1336407523.58.0.0696113570093.issue14741@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2b1cc84bf1d9 by Mark Dickinson in branch '3.2': Issue #14741: Fix missing support for ellipsis in parser module. http://hg.python.org/cpython/rev/2b1cc84bf1d9 New changeset d50577c5711b by Mark Dickinson in branch 'default': Issue #14741: Merge fix from 3.2. http://hg.python.org/cpython/rev/d50577c5711b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 18:25:49 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 May 2012 16:25:49 +0000 Subject: [issue14741] parser module doesn't support Ellipsis. In-Reply-To: <1336407523.58.0.0696113570093.issue14741@psf.upfronthosting.co.za> Message-ID: <1336407949.6.0.0687419842448.issue14741@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 18:49:45 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 07 May 2012 16:49:45 +0000 Subject: [issue14072] urlparse on tel: URI-s misses the scheme in some cases In-Reply-To: <1329817524.78.0.223656665156.issue14072@psf.upfronthosting.co.za> Message-ID: <1336409385.86.0.158927587395.issue14072@psf.upfronthosting.co.za> Ezio Melotti added the comment: > In the patch I'm assuming that the port number can only contain ascii digits RFC 3986 [0] defines the port as port = *DIGIT and part of the "authority" [1] as authority = [ userinfo "@" ] host [ ":" port ] userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) host = IP-literal / IPv4address / reg-name port = *DIGIT so my assumption should be correct. [0]: http://tools.ietf.org/html/rfc3986#section-3.2.3 [1]: http://tools.ietf.org/html/rfc3986#appendix-A ---------- stage: patch review -> commit review versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 18:59:53 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 07 May 2012 16:59:53 +0000 Subject: [issue10733] plistlib rejects strings containing control characters In-Reply-To: <1292701201.09.0.309647416438.issue10733@psf.upfronthosting.co.za> Message-ID: <1336409993.69.0.65556993585.issue10733@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.3 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 19:00:56 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 07 May 2012 17:00:56 +0000 Subject: [issue14072] urlparse on tel: URI-s misses the scheme in some cases In-Reply-To: <1329817524.78.0.223656665156.issue14072@psf.upfronthosting.co.za> Message-ID: <1336410056.99.0.403977807719.issue14072@psf.upfronthosting.co.za> R. David Murray added the comment: See also issue 14036. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 19:02:31 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 07 May 2012 17:02:31 +0000 Subject: [issue10765] Build regression from automation changes on windows In-Reply-To: <1293146347.8.0.828425848028.issue10765@psf.upfronthosting.co.za> Message-ID: <1336410151.66.0.134218556527.issue10765@psf.upfronthosting.co.za> Ezio Melotti added the comment: Can you still reproduce this? ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 20:29:13 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 07 May 2012 18:29:13 +0000 Subject: [issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time In-Reply-To: <1328301796.8.0.996607861145.issue13936@psf.upfronthosting.co.za> Message-ID: <1336415353.49.0.691641853879.issue13936@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 20:31:24 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 07 May 2012 18:31:24 +0000 Subject: [issue10427] 24:00 Hour in DateTime In-Reply-To: <1289831880.43.0.381934582888.issue10427@psf.upfronthosting.co.za> Message-ID: <1336415484.06.0.816764714438.issue10427@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 21:31:12 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 07 May 2012 19:31:12 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1336419072.66.0.970099972153.issue14657@psf.upfronthosting.co.za> Brett Cannon added the comment: I would say test_importlib and test_imp (test_import really should just get folded into test_importlib). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 21:34:58 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 May 2012 19:34:58 +0000 Subject: [issue14366] Supporting lzma compression in zip files In-Reply-To: <1332112236.1.0.964135054036.issue14366@psf.upfronthosting.co.za> Message-ID: <1336419298.6.0.859611977405.issue14366@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch updated to use functions encode_filter_properties and decode_filter_properties from the lzma module. Thank you, Nadeem Vawda. ---------- Added file: http://bugs.python.org/file25488/lzma_in_zip_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 21:38:00 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 May 2012 19:38:00 +0000 Subject: [issue14366] Supporting lzma compression in zip files In-Reply-To: <1332112236.1.0.964135054036.issue14366@psf.upfronthosting.co.za> Message-ID: <1336419480.67.0.192512106632.issue14366@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file25430/lzma_in_zip.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 21:44:05 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 May 2012 19:44:05 +0000 Subject: [issue14583] try/except import fails --without-threads In-Reply-To: <1334436331.01.0.461185960127.issue14583@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset d6324941b739 by Antoine Pitrou in branch 'default': Issue #14583: Fix importlib bug when a package's __init__.py would first import one of its modules then raise an error. http://hg.python.org/cpython/rev/d6324941b739 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 21:45:15 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 May 2012 19:45:15 +0000 Subject: [issue14742] test_tools very slow Message-ID: <1336419915.88.0.52212163456.issue14742@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Apparently test_unparse goes a bit overboard. test_compiler in 2.x had a more reasonable approach: it only compiled all files with -uall, otherwise it would choose 10 at random. ---------- components: Tests messages: 160165 nosy: mark.dickinson, pitrou priority: normal severity: normal status: open title: test_tools very slow type: performance versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 21:48:31 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 07 May 2012 19:48:31 +0000 Subject: [issue14743] on terminating, Pdb debugs itself Message-ID: <1336420111.44.0.550150061213.issue14743@psf.upfronthosting.co.za> New submission from Xavier de Gaye : All the problems raised in this issue are caused by self.botframe being set in a Pdb frame. In the following pdb session run with python 3.2.2, the first two frames in the printed stack are Pdb frames, this is wrong. And the second step command steps incorrectly into the exec() frame that is called by the Bdb run() method. What prevents the third step command to step into the run() frame, is that this frame does not have a trace function setup initially. === foo.py ================================= i = 1 ================================================= $ python3 -m pdb foo.py > path_to/foo.py(1)() -> i = 1 (Pdb) import sys; print(sys.version) 3.2.2 (default, Dec 27 2011, 17:35:55) [GCC 4.3.2] (Pdb) where /usr/local/lib/python3.2/bdb.py(392)run() -> exec(cmd, globals, locals) (1)() > path_to/foo.py(1)() -> i = 1 (Pdb) step --Return-- > path_to/foo.py(1)()->None -> i = 1 (Pdb) step --Return-- > (1)()->None (Pdb) step The program finished and will be restarted > path_to/foo.py(1)() -> i = 1 (Pdb) quit ================================================= In the following pdb session run with python built from the default branch (i.e. after issue 13183 has been fixed) the third step command steps into the run() method of Bdb and the backtrace printed after the quit command shows duplicate entries. Pdb is trying to debug itself ! Pdb steps in the run() method because after the fix in issue 13183, Pdb knows now how to step when returning into the caller frame with no trace function. === foo.py ================================= i = 1 ================================================= $ python -m pdb foo.py > path_to/foo.py(1)() -> i = 1 (Pdb) step --Return-- > path_to/foo.py(1)()->None -> i = 1 (Pdb) step --Return-- > (1)()->None (Pdb) step > path_to/cpython/Lib/bdb.py(409)run() -> self.quitting = True (Pdb) quit Traceback (most recent call last): File "path_to/cpython/Lib/pdb.py", line 1651, in main pdb._runscript(mainpyfile) File "path_to/cpython/Lib/pdb.py", line 1532, in _runscript self.run(statement) File "path_to/cpython/Lib/bdb.py", line 409, in run self.quitting = True File "path_to/cpython/Lib/bdb.py", line 409, in run self.quitting = True File "path_to/cpython/Lib/bdb.py", line 47, in trace_dispatch return self.dispatch_line(frame) File "path_to/cpython/Lib/bdb.py", line 66, in dispatch_line if self.quitting: raise BdbQuit bdb.BdbQuit Uncaught exception. Entering post mortem debugging Running 'cont' or 'step' will restart the program > path_to/cpython/Lib/bdb.py(66)dispatch_line() -> if self.quitting: raise BdbQuit (Pdb) quit Post mortem debugger finished. The foo.py will be restarted > path_to/foo.py(1)() -> i = 1 (Pdb) quit ================================================= In the following pdb session run with python 3.2.2, the session is interrupted with . The same problems occur as in the previous case. ================================================= import time i = 1 while i: time.sleep(.100) i = 0 ================================================= $ python3 -m pdb foo.py > path_to/foo.py(1)() -> import time (Pdb) import sys; print(sys.version) 3.2.2 (default, Dec 27 2011, 17:35:55) [GCC 4.3.2] (Pdb) continue ^C Program interrupted. (Use 'cont' to resume). > path_to/foo.py(3)() -> while i: (Pdb) !i=0 (Pdb) step > path_to/foo.py(5)() -> i = 0 (Pdb) step --Return-- > path_to/foo.py(5)()->None -> i = 0 (Pdb) step --Return-- > (1)()->None (Pdb) step > /usr/local/lib/python3.2/bdb.py(396)run() -> self.quitting = True (Pdb) quit Traceback (most recent call last): File "/usr/local/lib/python3.2/pdb.py", line 1556, in main pdb._runscript(mainpyfile) File "/usr/local/lib/python3.2/pdb.py", line 1437, in _runscript self.run(statement) File "/usr/local/lib/python3.2/bdb.py", line 396, in run self.quitting = True File "/usr/local/lib/python3.2/bdb.py", line 396, in run self.quitting = True File "/usr/local/lib/python3.2/bdb.py", line 46, in trace_dispatch return self.dispatch_line(frame) File "/usr/local/lib/python3.2/bdb.py", line 65, in dispatch_line if self.quitting: raise BdbQuit bdb.BdbQuit Uncaught exception. Entering post mortem debugging Running 'cont' or 'step' will restart the program > /usr/local/lib/python3.2/bdb.py(65)dispatch_line() -> if self.quitting: raise BdbQuit (Pdb) quit Post mortem debugger finished. The foo.py will be restarted > path_to/foo.py(1)() -> import time (Pdb) quit ================================================= The attached patch fixes all those problems. The patch applies to the default branch. ---------- components: Library (Lib) files: pdb_botframe_default.patch keywords: patch messages: 160166 nosy: xdegaye priority: normal severity: normal status: open title: on terminating, Pdb debugs itself type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25489/pdb_botframe_default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 21:48:52 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 May 2012 19:48:52 +0000 Subject: [issue14583] try/except import fails --without-threads In-Reply-To: <1334436331.01.0.461185960127.issue14583@psf.upfronthosting.co.za> Message-ID: <1336420132.56.0.11753600137.issue14583@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Should be fixed now. The buildbot has been able to launch the test suite. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 21:53:06 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 07 May 2012 19:53:06 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: <1336420386.27.0.945893005449.issue13183@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Note that now that this issue is fixed, issue 14743 has become more visible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 23:09:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 May 2012 21:09:22 +0000 Subject: [issue10765] Build regression from automation changes on windows In-Reply-To: <1293146347.8.0.828425848028.issue10765@psf.upfronthosting.co.za> Message-ID: <1336424962.19.0.799681197123.issue10765@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 23:15:36 2012 From: report at bugs.python.org (Glenn Linderman) Date: Mon, 07 May 2012 21:15:36 +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: <1336425336.27.0.546029481239.issue14565@psf.upfronthosting.co.za> Glenn Linderman added the comment: Hi Pierre, You are right, the "found" variable is not needed, I guess the reason I coded it that way, is I had some validation code before the return, during testing, so it was easier not to have it in three places. Regarding precalculating ln, I don't know how Python is coded internally, so it seems that string compares could be lengthier integer compares, and even in your code the length is calculated sometimes. So it is mostly an order of operations optimization... I didn't attempt to benchmark it with various URL and cgi_directories values, including at least both some with large prefix matches, and some without... I didn't figure it would matter much, but if you think it does, then feel free to benchmark. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 23:32:41 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 07 May 2012 21:32:41 +0000 Subject: [issue12298] Sphinx glitch in library/functions In-Reply-To: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za> Message-ID: <1336426361.12.0.854722455054.issue12298@psf.upfronthosting.co.za> ?ric Araujo added the comment: Sandro ported to 2.7 in 07b3fc67bf45. Thanks! If I may make two remarks: - Please duplicate commit messages from 3.2 and 2.7: it makes it easier to understand what a changeset is about without having to hunt. (This does not apply to 3.3 as the changeset with the full commit message is a direct parent and thus easily found.) - I?m not retired yet :) ---------- nosy: +sandro.tosi resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 23:34:48 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 May 2012 21:34:48 +0000 Subject: [issue14742] test_tools very slow In-Reply-To: <1336419915.88.0.52212163456.issue14742@psf.upfronthosting.co.za> Message-ID: <1336426488.53.0.342189025342.issue14742@psf.upfronthosting.co.za> Mark Dickinson added the comment: That sounds like a better approach. I'll back out the test_unparse inclusion until this can be fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 23:37:03 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 May 2012 21:37:03 +0000 Subject: [issue14742] test_tools very slow In-Reply-To: <1336419915.88.0.52212163456.issue14742@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset dbfacec7e368 by Mark Dickinson in branch 'default': Issue #14742: Don't include DirectoryTestCase from test_unparse in test_tools until we can speed it up. http://hg.python.org/cpython/rev/dbfacec7e368 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 23:41:58 2012 From: report at bugs.python.org (Sandro Tosi) Date: Mon, 07 May 2012 21:41:58 +0000 Subject: [issue12298] Sphinx glitch in library/functions In-Reply-To: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za> Message-ID: <1336426918.99.0.195642677784.issue12298@psf.upfronthosting.co.za> Sandro Tosi added the comment: Oh sorry ?ric, I completely oversaw there was an issue associated with the cset - i'll pay more attention next time! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 23:43:11 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 07 May 2012 21:43:11 +0000 Subject: [issue12298] Sphinx glitch in library/functions In-Reply-To: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za> Message-ID: <1336426991.07.0.457727229909.issue12298@psf.upfronthosting.co.za> ?ric Araujo added the comment: No problem, what counts is that our documentation and code get better for our users, not my ego :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 7 23:50:14 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 May 2012 21:50:14 +0000 Subject: [issue14716] Use unicode_writer API for str.format() In-Reply-To: <1336082896.6.0.108889213788.issue14716@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 01581e8b50f2 by Victor Stinner in branch 'default': Backout ab500b297900: the check for integer overflow is wrong http://hg.python.org/cpython/rev/01581e8b50f2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 00:09:22 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 May 2012 22:09:22 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals Message-ID: <1336428561.46.0.842580483885.issue14744@psf.upfronthosting.co.za> New submission from STINNER Victor : Since 7be716a47e9d (issue #14716), str.format() uses the "unicode_writer" API. I propose to continue the work in this direction to avoid more temporary buffers. Python 3.3: 1000000 loops, best of 3: 0.573 usec per loop 100000 loops, best of 3: 16.4 usec per loop 1000000 loops, best of 3: 0.705 usec per loop 100000 loops, best of 3: 2.61 usec per loop Python 3.3 + patch (compared to Python 3.3): 1000000 loops, best of 3: 0.516 usec per loop (-10%) 100000 loops, best of 3: 13.2 usec per loop (-20%) 1000000 loops, best of 3: 0.574 usec per loop (-18%) 100000 loops, best of 3: 2.59 usec per loop (-1%) -- If this patch is accepted, it's more to go even deeper: use _PyUnicodeWriter in long_to_decimal_string() for example. -- Benchmark Python 3 / Python 2 bytes: python -m timeit -s 'fmt="{0}.{1}.{2}"' 'fmt.format("http", "client", "HTTPConnection")' python -m timeit -s 'fmt="{0:s}"*100' 'fmt.format("ABCDEF")' python -m timeit -s 'fmt=" [line {0:2d}] "' 'fmt.format(5)' python -m timeit -s 'fmt="x={} y={} z={}"' 'fmt.format(12345, 12.345, 12.345+2j)' Benchmark Python 2 unicode: python -m timeit -s 'fmt=u"{0}.{1}.{2}"' 'fmt.format(u"http", u"client", u"HTTPConnection")' python -m timeit -s 'fmt=u"{0:s}"*100' 'fmt.format(u"ABCDEF")' python -m timeit -s 'fmt=u" [line {0:2d}] "' 'fmt.format(5)' python -m timeit -s 'fmt=u"x={} y={} z={}"' 'fmt.format(12345, 12.345, 12.345+2j)' Python 2.7 bytes: 1000000 loops, best of 3: 0.393 usec per loop 100000 loops, best of 3: 9.72 usec per loop 1000000 loops, best of 3: 0.337 usec per loop 1000000 loops, best of 3: 1.56 usec per loop Python 2.7 wide: 1000000 loops, best of 3: 0.443 usec per loop 100000 loops, best of 3: 10.3 usec per loop 1000000 loops, best of 3: 0.785 usec per loop 100000 loops, best of 3: 2.48 usec per loop Python 3.2 wide: 1000000 loops, best of 3: 0.457 usec per loop 100000 loops, best of 3: 10.5 usec per loop 1000000 loops, best of 3: 0.538 usec per loop 100000 loops, best of 3: 2.36 usec per loop ---------- components: Interpreter Core files: format_writer.patch keywords: patch messages: 160176 nosy: haypo, loewis, pitrou, storchaka priority: normal severity: normal status: open title: Use _PyUnicodeWriter API in str.format() internals versions: Python 3.3 Added file: http://bugs.python.org/file25490/format_writer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 00:19:42 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 May 2012 22:19:42 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336428561.46.0.842580483885.issue14744@psf.upfronthosting.co.za> Message-ID: <1336429182.09.0.719303000192.issue14744@psf.upfronthosting.co.za> STINNER Victor added the comment: Comments on the patch. -PyAPI_FUNC(PyObject *) _PyComplex_FormatAdvanced(PyObject *obj, +PyAPI_FUNC(int) _PyComplex_FormatWriter(PyObject *obj, Even if it is a private function, I prefer to rename it because its API does change. /* Use the inlined version in unicodeobject.c */ #define _PyUnicodeWriter_prepare _PyUnicodeWriter_prepare_inline #define _PyUnicodeWriter_write_substr _PyUnicodeWriter_write_substr_inline #define _PyUnicodeWriter_write_str _PyUnicodeWriter_write_str_inline #define _PyUnicodeWriter_write_char _PyUnicodeWriter_write_char_inline Inlining may be removed to simplify the code (but inlining does speed up the code a little bit). Or the opposite: this code should be moved to a new "unicodewriterinline.h" file which would be included by unicodeobject.c and formatter_unicode.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 00:33:31 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 07 May 2012 22:33:31 +0000 Subject: [issue14745] Misleading exception Message-ID: <1336430011.64.0.70812729636.issue14745@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis : $ python3.2 -c 'open("/dev/null", "w").read()' Traceback (most recent call last): File "", line 1, in io.UnsupportedOperation: not readable $ python3.3 -c 'open("/dev/null", "w").read()' Traceback (most recent call last): File "", line 1, in _frozen_importlib.UnsupportedOperation: not readable $ python3.3 -c 'import _frozen_importlib; _frozen_importlib.UnsupportedOperation' Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'UnsupportedOperation' ---------- messages: 160178 nosy: Arfrever, brett.cannon priority: normal severity: normal status: open title: Misleading exception versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 01:24:52 2012 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 May 2012 23:24:52 +0000 Subject: [issue14746] Remove redundant paragraphs from getargs.c skipitem() Message-ID: <1336433092.13.0.553393159676.issue14746@psf.upfronthosting.co.za> New submission from Larry Hastings : There's code like this in skipitem() in Python/getargs.c: case 'b': /* byte -- very short int */ /* ... a zillion more case statements here ... */ case 'C': /* unicode char */ case 'p': /* boolean predicate */ { (void) va_arg(*p_va, void *); break; } case 'n': /* Py_ssize_t */ { (void) va_arg(*p_va, Py_ssize_t *); break; } /* ... a bunch of other stuff here ... */ case 'S': /* string object */ case 'Y': /* string object */ case 'U': /* unicode string object */ { (void) va_arg(*p_va, PyObject **); break; } I cannot for the life of me imagine a platform where the size of a "Py_ssize_t *" or a "PyObject **" would be different from the size of a "void *". I've programmed on platforms where code pointers and data pointers were different sizes--but data pointers to different sizes of data? Never heard of it. But I've been wrong before! So, rather than simply make the change, I'm posting this bug just as a double check. It's safe to fold 'n', 'S', 'Y', and 'U' into the initial paragraph of case statements simply skipping a pointer... isn't it? ---------- assignee: larry messages: 160179 nosy: larry priority: low severity: normal stage: needs patch status: open title: Remove redundant paragraphs from getargs.c skipitem() type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 03:07:36 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 08 May 2012 01:07:36 +0000 Subject: [issue14735] Version 3.2.3 IDLE CTRL-Z plus Carriage Return to end does not work In-Reply-To: <1336252501.23.0.54042826511.issue14735@psf.upfronthosting.co.za> Message-ID: <1336439256.62.0.122151864206.issue14735@psf.upfronthosting.co.za> Roger Serwy added the comment: Ctrl+Z followed by Return still exits the Python shell on the command prompt under Vista. The simplest way to get this behavior working in IDLE would be modifying the end-of-file definition in config-keys.def, but only for the Windows keymap: [IDLE Classic Windows] # truncated end-of-file= # truncated I left the Ctrl+D bindings in place, as these are IDLE's "norm". In a strict sense they should be removed for a Windows key map. (I am basing my cross-platform understanding of Ctrl+Z from here: http://en.wikipedia.org/wiki/Control-Z ) The undo functionality already binds to Ctrl+Z. By using the Ctrl+Z and Return sequence to signal IDLE's shell to exit, I can foresee users accidentally closing their shells. Consider this scenario: a user types a long command and the prompt and then presses Ctrl+Z to undo the last few key strokes. The user then presses enter to run the command but the shell closes instead. The regular python shell from a command prompt displays a "^Z" as a visual indicator. If IDLE's shell did the same then I would not have hesitations about changing the key bindings. For now, I'm in favor of changing the documentation in help.txt to omit "(this is Control-z on Windows)." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 04:19:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 May 2012 02:19:50 +0000 Subject: [issue14745] Misleading exception In-Reply-To: <1336430011.64.0.70812729636.issue14745@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2cd9dadd5c6c by Benjamin Peterson in branch 'default': explicitly set UnsupportedOperation's module rather than relying on incorrect globals on startup (closes #14745) http://hg.python.org/cpython/rev/2cd9dadd5c6c ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 04:49:25 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 08 May 2012 02:49:25 +0000 Subject: [issue13659] Add a help() viewer for IDLE's Shell. In-Reply-To: <1324707815.11.0.534121320744.issue13659@psf.upfronthosting.co.za> Message-ID: <1336445365.16.0.379098182653.issue13659@psf.upfronthosting.co.za> Roger Serwy added the comment: Attached is an initial diff for creating a separate pager window by using a textView widget. The recently applied patch in issue964437 allows this window to be non-modal, which can be useful for interactive development. The diff contains code to allow the pager to work with and without a subprocess. The "pager" and "use_help_window" in PyShell.py provide the core functionality. The "use_help_window" presently is a placeholder for implementing Ezio's suggestion in msg160114. Does anyone know why "import pydoc" is wrapped in a try/except block? I omitted that in "pager". ---------- keywords: +patch Added file: http://bugs.python.org/file25491/help_pager.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 05:08:37 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 May 2012 03:08:37 +0000 Subject: [issue14732] PEP 3121 Refactoring applied to _csv module In-Reply-To: <1336247238.98.0.79082288942.issue14732@psf.upfronthosting.co.za> Message-ID: <1336446517.75.0.814407020855.issue14732@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 05:29:09 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 May 2012 03:29:09 +0000 Subject: [issue14654] Faster utf-8 decoding In-Reply-To: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za> Message-ID: <1336447749.82.0.31052184357.issue14654@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 05:29:53 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 May 2012 03:29:53 +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: <1336447793.19.0.741790335449.issue9374@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo, orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 05:31:21 2012 From: report at bugs.python.org (Zhiping Deng) Date: Tue, 08 May 2012 03:31:21 +0000 Subject: [issue5557] Byte-code compilation uses excessive memory In-Reply-To: <1237924124.82.0.478709056921.issue5557@psf.upfronthosting.co.za> Message-ID: <1336447881.19.0.58160300935.issue5557@psf.upfronthosting.co.za> Changes by Zhiping Deng : ---------- nosy: +Zhiping.Deng _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 05:33:24 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 May 2012 03:33:24 +0000 Subject: =?utf-8?q?=5Bissue6602=5D_Add_argument_to_control_file_object_used_by_Bas?= =?utf-8?q?eHTTPServer=E2=80=99s_log=5Fmessage?= In-Reply-To: <1248952406.18.0.680079792557.issue6602@psf.upfronthosting.co.za> Message-ID: <1336448004.88.0.675425555153.issue6602@psf.upfronthosting.co.za> ?ric Araujo added the comment: Clearly +1 to Antoine; that?s just how unix programs do it. stdout is for the program output, which may be formatted in a certain way in order to be piped to another program, and stderr is for all messages for the human user. Editing the bug title and version to reflect Antoine?s suggestion, which does have a chance of going in if someone is interested in providing a patch. ---------- nosy: +eric.araujo status: open -> pending title: BaseHTTPServer log_message should log to sys.stdout -> Add argument to control file object used by BaseHTTPServer?s log_message versions: -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 05:36:11 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 May 2012 03:36:11 +0000 Subject: [issue14743] on terminating, Pdb debugs itself In-Reply-To: <1336420111.44.0.550150061213.issue14743@psf.upfronthosting.co.za> Message-ID: <1336448171.33.0.616979449059.issue14743@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- keywords: +needs review nosy: +georg.brandl stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 05:37:59 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 May 2012 03:37:59 +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: <1336448279.4.0.439240819709.issue14565@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- versions: -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 06:55:40 2012 From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=) Date: Tue, 08 May 2012 04:55:40 +0000 Subject: [issue14747] Classifiers are missing from distutils2-generated metadata Message-ID: <1336452940.51.0.60009566738.issue14747@psf.upfronthosting.co.za> New submission from Alex Gr?nholm : Apparently they worked in 1.0a3 but not in 1.0a4 anymore. ---------- assignee: eric.araujo components: Distutils2 messages: 160184 nosy: agronholm, alexis, eric.araujo, tarek priority: normal severity: normal status: open title: Classifiers are missing from distutils2-generated metadata type: behavior versions: 3rd party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 07:02:12 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 May 2012 05:02:12 +0000 Subject: [issue14654] Faster utf-8 decoding In-Reply-To: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za> Message-ID: <1336453332.9.0.859538628805.issue14654@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See issue14738 for advanced optimization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 07:32:10 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 May 2012 05:32:10 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336428561.46.0.842580483885.issue14744@psf.upfronthosting.co.za> Message-ID: <1336455282.4987.19.camel@raxxla> Serhiy Storchaka added the comment: > If this patch is accepted, it's more to go even deeper: use _PyUnicodeWriter in long_to_decimal_string() for example. long_to_decimal_string() is already creates a string of known size. How _PyUnicodeWriter can help here? Issue3451 looks much more promising for int formatting. But it will take a lot of time to carefully check this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 08:22:49 2012 From: report at bugs.python.org (Pierre Quentel) Date: Tue, 08 May 2012 06:22:49 +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: <1336458169.03.0.0544980651441.issue14565@psf.upfronthosting.co.za> Pierre Quentel added the comment: Hi Glenn, My proposal was not about optimization, I just thought that "if x==y" is simpler than "if len(x)==len(y) and x==y". Since we don't expect that there will be many directories in the list, I don't think optimizing is so important. But it doesn't matter to me really, the most important is to have the bug fixed Can you propose a diff file so that the committers can review it ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 10:01:56 2012 From: report at bugs.python.org (halfie) Date: Tue, 08 May 2012 08:01:56 +0000 Subject: [issue14748] spwd.getspall() is returning LDAP (non local) users too Message-ID: <1336464116.12.0.238019715557.issue14748@psf.upfronthosting.co.za> New submission from halfie : spwd.getspall() is returning LDAP (non local) users too. On RHEL 6.2 machine with LDAP authentication configured, spwd.getspall() is returning LDAP (non local) users too. On a similarly configured CentOS 6.2 machine, spwd.getspall() is returning only local users. Is spwd.getspall() supposed to return LDAP users? (If yes, this should to documented). Why is spwd.getspall() behavior different on different Linux OSes? ---------- components: Library (Lib) messages: 160188 nosy: halfie priority: normal severity: normal status: open title: spwd.getspall() is returning LDAP (non local) users too type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 10:37:06 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 May 2012 08:37:06 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336455282.4987.19.camel@raxxla> Message-ID: STINNER Victor added the comment: _PyUnicodeWriter in long_to_decimal_string() for example. > > long_to_decimal_string() is already creates a string of known size. How > _PyUnicodeWriter can help here? "x={}".format(123) uses a temporary buffer for "123". Using _PyUnicodeWriter even to format 123 would avoid a malloc() and a copy of the characters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 11:02:13 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 08 May 2012 09:02:13 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336428561.46.0.842580483885.issue14744@psf.upfronthosting.co.za> Message-ID: <1336467733.56.0.350318530975.issue14744@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Issue3451 looks much more promising for int formatting. But it will take > a lot of time to carefully check this. I disagree: Issue 3451 is about *asymptotically* fast base conversion, and the changes proposed there are only going to kick in for numbers with hundreds of digits; it's not going to affect the common case at all. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 11:56:32 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 08 May 2012 09:56:32 +0000 Subject: [issue14749] Add 'Z' to skipitem() in Python/getargs.c Message-ID: <1336470992.95.0.551776226644.issue14749@psf.upfronthosting.co.za> New submission from Larry Hastings : skipitem() (in Python/getargs.c) has to be taught about all the "format units" understood by PyArg_Parse. There's a note at the top of the format-unit-understanding code saying When you add new format codes, please don't forget poor skipitem() below. Well, someone forgot poor skipitem() when they added 'Z'. Since this is a bugfix, I assert it should go into 3.2, then get forward-ported into trunk. So, step 1: check the attached one-line patch to 3.2. Georg: sound good? ---------- assignee: larry components: Interpreter Core files: larry.skipitem.Z.1.diff keywords: patch messages: 160191 nosy: georg.brandl, larry priority: low severity: normal stage: patch review status: open title: Add 'Z' to skipitem() in Python/getargs.c type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file25492/larry.skipitem.Z.1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 12:13:30 2012 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 08 May 2012 10:13:30 +0000 Subject: [issue14732] PEP 3121 Refactoring applied to _csv module In-Reply-To: <1336247238.98.0.79082288942.issue14732@psf.upfronthosting.co.za> Message-ID: <1336472010.45.0.623691640962.issue14732@psf.upfronthosting.co.za> Changes by Skip Montanaro : ---------- nosy: -skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 12:14:29 2012 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 08 May 2012 10:14:29 +0000 Subject: [issue14732] PEP 3121 Refactoring applied to _csv module In-Reply-To: <1336446517.78.0.944950544341.issue14732@psf.upfronthosting.co.za> Message-ID: Skip Montanaro added the comment: > Changes by ?ric Araujo : > > > ---------- > nosy: +skip.montanaro Thanks, but I'm out of the Python development business, except as it pertains to my day job... Skip ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 12:22:34 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 08 May 2012 10:22:34 +0000 Subject: [issue14749] Add 'Z' to skipitem() in Python/getargs.c In-Reply-To: <1336470992.95.0.551776226644.issue14749@psf.upfronthosting.co.za> Message-ID: <1336472554.63.0.660156920948.issue14749@psf.upfronthosting.co.za> Georg Brandl added the comment: Sound good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 12:38:53 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 May 2012 10:38:53 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: Message-ID: <1336473684.4987.42.camel@raxxla> Serhiy Storchaka added the comment: > "x={}".format(123) uses a temporary buffer for "123". This, apparently, is inevitable. I doubt that it is able to considerably optimize, not worsened str(int) (which is optimal for current algorithm). Note that the more complex formatting (with width) will still require the temporary buffer. Be very careful not to cause regress. > Using > _PyUnicodeWriter even to format 123 would avoid a malloc() and a copy of > the characters. Fill the ascii buffer and then copying can be cheaper than using _PyUnicodeWriter with general non-ascii string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 12:51:42 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 May 2012 10:51:42 +0000 Subject: [issue14749] Add 'Z' to skipitem() in Python/getargs.c In-Reply-To: <1336470992.95.0.551776226644.issue14749@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 91612618985b by Larry Hastings in branch '3.2': Issue #14749: Add support for 'Z' to skipitem() in Python/getargs.c. http://hg.python.org/cpython/rev/91612618985b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 12:54:21 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 May 2012 10:54:21 +0000 Subject: [issue14749] Add 'Z' to skipitem() in Python/getargs.c In-Reply-To: <1336470992.95.0.551776226644.issue14749@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b32baa5b7626 by Larry Hastings in branch 'default': Merge from 3.2. Issue #14749: Add support for 'Z' to skipitem(). http://hg.python.org/cpython/rev/b32baa5b7626 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 13:20:40 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 08 May 2012 11:20:40 +0000 Subject: [issue14749] Add 'Z' to skipitem() in Python/getargs.c In-Reply-To: <1336470992.95.0.551776226644.issue14749@psf.upfronthosting.co.za> Message-ID: <1336476040.1.0.677118622624.issue14749@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 13:39:38 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 08 May 2012 11:39:38 +0000 Subject: [issue14743] on terminating, Pdb debugs itself In-Reply-To: <1336420111.44.0.550150061213.issue14743@psf.upfronthosting.co.za> Message-ID: <1336477178.24.0.404336961262.issue14743@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Uploaded a new patch, pdb_botframe_default_2.patch (that applies to the current tip of the default branch) with: * a correction to the initial change made to fix sigint_handler() * the two test cases ---------- Added file: http://bugs.python.org/file25493/pdb_botframe_default_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 13:43:28 2012 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 08 May 2012 11:43:28 +0000 Subject: [issue14750] importlib fails with tkinter application on Windows Message-ID: <1336477408.86.0.0365400477373.issue14750@psf.upfronthosting.co.za> New submission from Vinay Sajip : I'm now getting failures to import tkinter on Windows: C:\Users\Vinay\Projects\scratch>..\cpython\PCbuild\python tkhello.py Traceback (most recent call last): File "tkhello.py", line 1, in from tkinter import * File "", line 977, in _find_and_load File "", line 596, in load_module File "", line 262, in module_for_loader_wrapper File "", line 484, in _load_module File "C:\Users\Vinay\Projects\cpython\lib\tkinter\__init__.py", line 36, in from tkinter import _fix ImportError: cannot import name _fix I'm not sure if this is an importlib issue or a tkinter one, but with a recent build (30 April) this worked OK. The tkhello.py script is just from tkinter import * root = Tk() w = Label(root, text="Hello, world!") w.pack() root.mainloop() ---------- components: Library (Lib), Windows messages: 160198 nosy: brett.cannon, vinay.sajip priority: normal severity: normal status: open title: importlib fails with tkinter application on Windows type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 14:06:27 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 08 May 2012 12:06:27 +0000 Subject: [issue14749] Add 'Z' to skipitem() in Python/getargs.c In-Reply-To: <1336470992.95.0.551776226644.issue14749@psf.upfronthosting.co.za> Message-ID: <1336478787.27.0.121279249576.issue14749@psf.upfronthosting.co.za> Benjamin Peterson added the comment: No test? ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 14:33:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 08 May 2012 12:33:03 +0000 Subject: [issue14732] PEP 3121 Refactoring applied to _csv module In-Reply-To: <1336247238.98.0.79082288942.issue14732@psf.upfronthosting.co.za> Message-ID: <1336480383.36.0.80008367239.issue14732@psf.upfronthosting.co.za> Antoine Pitrou added the comment: PyModule_AddObject steals the value's reference, so you need to INCREF it before. Besides that, I don't see any obvious bug, but perhaps Martin wants to take a look. ---------- nosy: +pitrou priority: normal -> low stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 14:39:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 08 May 2012 12:39:50 +0000 Subject: [issue14750] importlib fails with tkinter application on Windows In-Reply-To: <1336477408.86.0.0365400477373.issue14750@psf.upfronthosting.co.za> Message-ID: <1336480790.12.0.660315126099.issue14750@psf.upfronthosting.co.za> Antoine Pitrou added the comment: For the record, the script works fine under Linux. Vinay, can you bisect and find out which revision introduced the issue? ---------- nosy: +brian.curtin, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 14:40:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 08 May 2012 12:40:48 +0000 Subject: [issue14748] spwd.getspall() is returning LDAP (non local) users too In-Reply-To: <1336464116.12.0.238019715557.issue14748@psf.upfronthosting.co.za> Message-ID: <1336480848.06.0.154535225764.issue14748@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +dmalcolm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 15:00:18 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 08 May 2012 13:00:18 +0000 Subject: [issue14751] Pdb does not stop at a breakpoint Message-ID: <1336482018.48.0.822650830886.issue14751@psf.upfronthosting.co.za> New submission from Xavier de Gaye : When a breakpoint is set in one of the frames of the frame stack, Pdb may not stop at that breakpoint when the frame does not have a trace function. This problem is closely related to issue 13183 and issue 14728. The following scenario demonstrates this problem. ==== main.py ================================ import bar def foo(): bar.bar() x = 1 foo() ==== bar.py ================================== def bar(): pass ================================================= $ python3 -m pdb main.py > /path_to/main.py(1)() -> import bar (Pdb) import sys; print(sys.version) 3.2.2 (default, Dec 27 2011, 17:35:55) [GCC 4.3.2] (Pdb) break bar.bar Breakpoint 1 at /path_to/bar.py:1 (Pdb) continue > /path_to/bar.py(2)bar() -> pass (Pdb) break main.py:5 Breakpoint 2 at /path_to/main.py:5 (Pdb) continue The program finished and will be restarted > /path_to/main.py(1)() -> import bar (Pdb) quit ================================================= The attached patch fixes this problem. A test case is included in the patch. The patch is made against the proposed fix of issue 14728 (i.e. assumes this patch is applied), the reason being that self._curframe must be correctly set. Actually this issue and issue 14728 should probably be merged. Note that the trace function does not need anymore to be set in all the frames of the frame stack in set_trace(), so setting the trace function has been removed from the while loop. ---------- components: Library (Lib) files: pdb_default.patch keywords: patch messages: 160202 nosy: xdegaye priority: normal severity: normal status: open title: Pdb does not stop at a breakpoint type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25494/pdb_default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 15:19:49 2012 From: report at bugs.python.org (Damien Cassou) Date: Tue, 08 May 2012 13:19:49 +0000 Subject: [issue14752] Memleak in typeobject add_methods() Message-ID: <1336483189.75.0.262092061745.issue14752@psf.upfronthosting.co.za> New submission from Damien Cassou : In add_methods() function from typeobject.c, it looks like Py_DECREF is not called where it should be. Please find attached a patch that fixes the leak. The patch is also in commit #85a01718b3e3 of my hg repository under the branch fix_add_methods_leak. This bug has been found using Coccinelle (http://coccinelle.lip6.fr/) and a dedicated semantic patch (https://gist.github.com/2634899). ---------- components: Interpreter Core files: fix_add_methods_leak.patch hgrepos: 122 keywords: patch messages: 160203 nosy: cassou, lemburg, tim_one priority: normal severity: normal status: open title: Memleak in typeobject add_methods() type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file25495/fix_add_methods_leak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 15:21:29 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 08 May 2012 13:21:29 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1336483289.02.0.689708967399.issue9260@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 15:23:16 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 May 2012 13:23:16 +0000 Subject: [issue14752] Memleak in typeobject add_methods() In-Reply-To: <1336483189.75.0.262092061745.issue14752@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset d937b527b76e by Benjamin Peterson in branch '3.2': fix possible refleak (closes #14752) http://hg.python.org/cpython/rev/d937b527b76e New changeset 5319a4bf72e7 by Benjamin Peterson in branch '2.7': fix possible refleak (closes #14752) http://hg.python.org/cpython/rev/5319a4bf72e7 New changeset 07b04373aef8 by Benjamin Peterson in branch 'default': merge 3.2 (#14752) http://hg.python.org/cpython/rev/07b04373aef8 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 15:39:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 08 May 2012 13:39:29 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1336484369.78.0.270511710972.issue9260@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch against tip. I also changed the internal API of module locks a bit (acquire() raises _DeadlockError instead of returning False, and deadlock detection is not optional anymore). ---------- Added file: http://bugs.python.org/file25496/module_locks8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 16:58:08 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 08 May 2012 14:58:08 +0000 Subject: [issue14753] multiprocessing treats negative timeouts differently from before Message-ID: <1336489087.9.0.014285533368.issue14753@psf.upfronthosting.co.za> New submission from Richard Oudkerk : In version 3.2 and earlier, Process.join() and Connection.poll() treat negative timeouts as zero timeouts. (Thread.join() does the same.) In the current 3.3 version, they treat negative timeouts as infinite timeouts. Also multiprocessing.connection.wait() (new in 3.3) currently treats them as infinite on Unix and zero on Windows. The attached patch fixes the regression with Process.join() and Connection.poll(). It also makes wait() treat negative timeouts as zero on both Windows and Unix. It is worth noting that there is a fair amount of inconsistency in the handling of negative timeouts in the stdlib in 3.2: Treat negative as infinite: select.select select.*.poll threading.*.acquire (new in 3.2) multiprocessing.dummy.*.acquire (new in 3.2) Treat negative as zero: threading.Thread.join threading.(Condition|Event).wait multiprocessing.Process.join multiprocessing.*.acquire multiprocessing.(Condition|Event).wait multiprocessing.Connection.poll multiprocessing.Queue.(get|put) concurrent.futures.Future.result concurrent.futures.wait Treat negative as error: queue.Queue.(get|put) socket.socket.settimeout ---------- components: Library (Lib) files: neg-timeout.patch keywords: patch messages: 160206 nosy: pitrou, sbt priority: normal severity: normal stage: patch review status: open title: multiprocessing treats negative timeouts differently from before type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file25497/neg-timeout.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 17:17:24 2012 From: report at bugs.python.org (Brian Curtin) Date: Tue, 08 May 2012 15:17:24 +0000 Subject: [issue14750] importlib fails with tkinter application on Windows In-Reply-To: <1336477408.86.0.0365400477373.issue14750@psf.upfronthosting.co.za> Message-ID: <1336490244.31.0.430139417791.issue14750@psf.upfronthosting.co.za> Brian Curtin added the comment: Reproduced here as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 17:23:11 2012 From: report at bugs.python.org (Damien Cassou) Date: Tue, 08 May 2012 15:23:11 +0000 Subject: [issue14754] Emacs configuration to enforce PEP7 Message-ID: <1336490591.2.0.870599678053.issue14754@psf.upfronthosting.co.za> New submission from Damien Cassou : Please find attached a patch that adds an emacs configuration file to enforce PEP7. The patch is also in commit #518f2af0a687 of my hg repository under the branch emacs-configuration. ---------- components: Demos and Tools files: emacs-configuration-pep7.patch hgrepos: 123 keywords: patch messages: 160208 nosy: cassou priority: normal severity: normal status: open title: Emacs configuration to enforce PEP7 versions: Python 3.4 Added file: http://bugs.python.org/file25498/emacs-configuration-pep7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 17:24:30 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 08 May 2012 15:24:30 +0000 Subject: [issue14754] Emacs configuration to enforce PEP7 In-Reply-To: <1336490591.2.0.870599678053.issue14754@psf.upfronthosting.co.za> Message-ID: <1336490670.11.0.445270547221.issue14754@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 17:51:47 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 08 May 2012 15:51:47 +0000 Subject: [issue14727] test_multiprocessing failure under Linux In-Reply-To: <1336209215.05.0.989780505108.issue14727@psf.upfronthosting.co.za> Message-ID: <1336492307.57.0.00927066036362.issue14727@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > I've recently started seeing this failure repeatably on Linux (Ubuntu > Jaunty): The test is newly enabled. Does "repeatably" mean you always get the failure? I have not seen any failures on the Linux buildbots. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 17:58:34 2012 From: report at bugs.python.org (Dave Malcolm) Date: Tue, 08 May 2012 15:58:34 +0000 Subject: [issue14748] spwd.getspall() is returning LDAP (non local) users too In-Reply-To: <1336464116.12.0.238019715557.issue14748@psf.upfronthosting.co.za> Message-ID: <1336492714.38.0.953778114728.issue14748@psf.upfronthosting.co.za> Dave Malcolm added the comment: Like passwd and group information, the shadow password entries are pulled through libc's Name Service Switch and modules for it, depending on configuration. See "man nsswitch.conf". Hence this is likely to be a configuration difference between the two boxes. Some notes from one of my Red Hat colleagues: * Is a module listed in /etc/nsswitch.conf so that it'll be used to look up "shadow" information? * Does the module support looking up shadow information? The libnss_ldap.so.2 stub from nss-pam-ldapd does; SSSD (at least version 1.8.3) doesn't. * Are there shadowAccount entries in the directory server? An IPA server won't have them, because IPA makes use of the directory server's built-in password policy functionality to avoid depending on clients to enforce aging policies. * Is the client performing the lookup authorized to read the shadow data from the directory server? * Does the client perform any additional access control? The daemon in nss-pam-ldapd only exposes shadow information to processes running as UID 0. etc Hope this is helpful ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 18:06:16 2012 From: report at bugs.python.org (Nick Wilson) Date: Tue, 08 May 2012 16:06:16 +0000 Subject: [issue14755] Distutils2 doesn't have a Python 3 version on PyPI Message-ID: <1336493176.58.0.778594682888.issue14755@psf.upfronthosting.co.za> New submission from Nick Wilson : PyPI only has a version of distutils2 for Python 2, not for Python 3. There is an "ImportError: No module named ConfigParser" when trying to "pip install distutils2" from Python 3. ---------- assignee: eric.araujo components: Distutils2 messages: 160211 nosy: alexis, eric.araujo, njwilson, tarek priority: normal severity: normal status: open title: Distutils2 doesn't have a Python 3 version on PyPI _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 18:06:44 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 08 May 2012 16:06:44 +0000 Subject: [issue14725] test_multiprocessing failure under Windows In-Reply-To: <1336172041.91.0.79006187387.issue14725@psf.upfronthosting.co.za> Message-ID: <1336493204.19.0.99503304524.issue14725@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 18:48:01 2012 From: report at bugs.python.org (Matthew Walker) Date: Tue, 08 May 2012 16:48:01 +0000 Subject: [issue14756] Empty Dict in Initializer is Shared Betwean Objects Message-ID: <1336495681.08.0.928968758685.issue14756@psf.upfronthosting.co.za> New submission from Matthew Walker : When initializing a class with an empty dict() object as a default initializer, if it is not overridden, multiple instances of the class will share the dictionary. IE: class test(object): def __init__(self, obj=dict()): self.obj = obj a = test() b = test() Then id(a.obj) points to the same location as id(b.obj). The behaviour I would expect would be that a.obj and b.obj would be unique instances. ---------- components: Interpreter Core messages: 160212 nosy: Matthew.Walker priority: normal severity: normal status: open title: Empty Dict in Initializer is Shared Betwean Objects versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 18:48:55 2012 From: report at bugs.python.org (Matthew Walker) Date: Tue, 08 May 2012 16:48:55 +0000 Subject: [issue14756] Empty Dict in Initializer is Shared Betwean Objects In-Reply-To: <1336495681.08.0.928968758685.issue14756@psf.upfronthosting.co.za> Message-ID: <1336495735.55.0.626155548038.issue14756@psf.upfronthosting.co.za> Changes by Matthew Walker : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 18:49:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 08 May 2012 16:49:40 +0000 Subject: [issue14756] Empty Dict in Initializer is Shared Betwean Objects In-Reply-To: <1336495681.08.0.928968758685.issue14756@psf.upfronthosting.co.za> Message-ID: <1336495780.04.0.363225532514.issue14756@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is not a bug, see http://docs.python.org/dev/faq/design.html#why-are-default-values-shared-between-objects ---------- nosy: +pitrou resolution: -> invalid stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 18:49:44 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 08 May 2012 16:49:44 +0000 Subject: [issue14756] Empty Dict in Initializer is Shared Betwean Objects In-Reply-To: <1336495681.08.0.928968758685.issue14756@psf.upfronthosting.co.za> Message-ID: <1336495784.44.0.94236958426.issue14756@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 19:10:41 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 08 May 2012 17:10:41 +0000 Subject: [issue14755] Distutils2 doesn't have a Python 3 version on PyPI In-Reply-To: <1336493176.58.0.778594682888.issue14755@psf.upfronthosting.co.za> Message-ID: <1336497041.16.0.293791515202.issue14755@psf.upfronthosting.co.za> ?ric Araujo added the comment: This comes from the fact that d2 is developed with two Mercurial branches, not build-time 2to3 conversion (which I dislike as ugly and not fully correct) nor single-source (which I dislike as ugly and hard to maintain :). PyPI does not work well with that workflow; see how unittest2 had to use a unittest2py3k project name. I think pip does the right thing if you upload project-X.Y-py3.tar.gz, I need to check that and if it works do a manual upload of 1.0a4-py3. ---------- versions: +3rd party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 19:26:51 2012 From: report at bugs.python.org (Martin) Date: Tue, 08 May 2012 17:26:51 +0000 Subject: [issue10765] Build regression from automation changes on windows In-Reply-To: <1293146347.8.0.828425848028.issue10765@psf.upfronthosting.co.za> Message-ID: <1336498011.23.0.414077168875.issue10765@psf.upfronthosting.co.za> Martin added the comment: Yes, this is still reproducible. For instance, by: > hg clone -b default 3.3 "feature branch" > cd "feature branch/PCbuild" > call build_env.bat > call build.bat It seems python33.dll now does get created so it's less severe, but the python3dll still fails due to the makefile OutDir not being quoted: NMAKE : fatal error U1073: don't know how to make 'branch\PCbuild\' ---------- versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 19:37:56 2012 From: report at bugs.python.org (stefan brunthaler) Date: Tue, 08 May 2012 17:37:56 +0000 Subject: [issue14757] INCA: Inline Caching meets Quickening in Python 3.3 Message-ID: <1336498675.39.0.776636251166.issue14757@psf.upfronthosting.co.za> New submission from stefan brunthaler : The attached patch adds quickening based inline caching (INCA) to the CPython 3.3 interpreter. It uses a code generator to generate instruction derivatives using the mako template engine, and a set of utility functions to enable automatic and safe quickening. The code generator itself resides in "cgen" and the generated files reside in "Python/opt/gen". Auxiliary files resides in "Python/opt" and only minor changes are necessary in ceval.c and places where type feedback is possible (mostly in abstract.c and object.c) Details of the technique have been published (see my home page: http://www.ics.uci.edu/~sbruntha/.) On my machine (i7-920 with Intel Turbo Boost disabled) this results in average arithmetic speedups of 1.47 over the vanilla interpreter without threaded code/computed gotos, and 1.13 over an interpreter with threaded code/computed gotos enabled. (Maximal speedups are 1.61 over the vanilla interpreter and 1.17 over the threaded code interpreter.) The optimized interpreter uses 206 instructions which currently only cover the standard library, i.e., there is still ample space left for optimized instruction derivatives for popular applications/libraries, such as NumPy or Django. Furthermore, based on the purely interpretative nature of the technique, there are no compatibility implications (modulo libraries/modules relying on concrete opcode values---I would guess that such code is rather unlikely, but one never knows...) Additional memory overhead is minimal, too, since the technique only requires space for the new derivatives and is something along the lines of 80-100 KiB. ---------- components: Interpreter Core files: 20120508-inca.patch hgrepos: 124 keywords: patch messages: 160216 nosy: sbrunthaler priority: normal severity: normal status: open title: INCA: Inline Caching meets Quickening in Python 3.3 type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25499/20120508-inca.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 20:16:41 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 08 May 2012 18:16:41 +0000 Subject: [issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper In-Reply-To: <1326892577.13.0.456815776311.issue13815@psf.upfronthosting.co.za> Message-ID: <1336501001.4.0.790112333932.issue13815@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I think it would have been better to keep the ExFileObject class, and base it on io.BufferedReader: class ExFileObject(io.BufferedReader): def __init__(self, tarfile, tarinfo): raw = _FileInFile(tarfile.fileobj, tarinfo.offset_data, tarinfo.size, tarinfo.sparse) io.BufferedReader.__init__(self, raw) The result is the same of course, but there is no need to special-case the pre-3.3 API. In addition, _FileInFile could probably inherit from io.RawIOBase. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 20:23:55 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 08 May 2012 18:23:55 +0000 Subject: [issue14757] INCA: Inline Caching meets Quickening in Python 3.3 In-Reply-To: <1336498675.39.0.776636251166.issue14757@psf.upfronthosting.co.za> Message-ID: <1336501435.04.0.806562518072.issue14757@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 21:01:25 2012 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 08 May 2012 19:01:25 +0000 Subject: [issue14750] importlib fails with tkinter application on Windows In-Reply-To: <1336477408.86.0.0365400477373.issue14750@psf.upfronthosting.co.za> Message-ID: <1336503685.92.0.596202545348.issue14750@psf.upfronthosting.co.za> Vinay Sajip added the comment: I went back a fair way, and the failure still keeps happening. So now I'm wondering - is a Tk app *supposed* to work from a source build? I've verified that the test script works OK when run from an installed Python. So, this issue may be invalid, if we don't care about running Tk apps from a source build (if so, sorry for the noise) - or if we do care, then it's not an importlib issue, but Tk-related (I'm not a Tk expert by any means, so I'm not sure what needs to be done to make a Tk app work from a source build). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 21:03:38 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 08 May 2012 19:03:38 +0000 Subject: [issue14750] importlib fails with tkinter application on Windows In-Reply-To: <1336503685.92.0.596202545348.issue14750@psf.upfronthosting.co.za> Message-ID: <1336503697.3376.14.camel@localhost.localdomain> Antoine Pitrou added the comment: > I went back a fair way, and the failure still keeps happening. So now > I'm wondering - is a Tk app *supposed* to work from a source build? Does it work with 3.2? Did you try debugging at the prompt? e.g. looking what tkinter.__file__ is, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 21:13:45 2012 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 08 May 2012 19:13:45 +0000 Subject: [issue14727] test_multiprocessing failure under Linux In-Reply-To: <1336209215.05.0.989780505108.issue14727@psf.upfronthosting.co.za> Message-ID: <1336504425.39.0.553477688317.issue14727@psf.upfronthosting.co.za> Vinay Sajip added the comment: > Does "repeatably" mean you always get the failure? Yes, every time. The first symptom is always a ConnectionRefusedError. > I have not seen any failures on the Linux buildbots. I'm running a fairly old version of Ubuntu, which might be relevant, or it may be that the connection is being refused because it's clashing with something else just on the test machine. In general this machine is just used for Python builds and tests, but I do run some services (e.g. Jenkins). Or it might be a race condition - the test machine is a VM and does have somewhat different timing characteristics from those of real hardware. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 21:29:17 2012 From: report at bugs.python.org (Georg Brandl) Date: Tue, 08 May 2012 19:29:17 +0000 Subject: [issue14754] Emacs configuration to enforce PEP7 In-Reply-To: <1336490591.2.0.870599678053.issue14754@psf.upfronthosting.co.za> Message-ID: <1336505357.97.0.868243359791.issue14754@psf.upfronthosting.co.za> Georg Brandl added the comment: As much as I like Emacs, I don't think it is special enough to warrant a special file in the root directory. Editor-specific directories in Misc/ are fine, and you can put instructions there how to add your own .dir-locals.el, and we can even add this to .hgignore if requested, but not more. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 21:48:43 2012 From: report at bugs.python.org (Dave Malcolm) Date: Tue, 08 May 2012 19:48:43 +0000 Subject: [issue14757] INCA: Inline Caching meets Quickening in Python 3.3 In-Reply-To: <1336498675.39.0.776636251166.issue14757@psf.upfronthosting.co.za> Message-ID: <1336506523.65.0.279859264918.issue14757@psf.upfronthosting.co.za> Changes by Dave Malcolm : ---------- nosy: +dmalcolm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 22:18:42 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 08 May 2012 20:18:42 +0000 Subject: [issue14757] INCA: Inline Caching meets Quickening in Python 3.3 In-Reply-To: <1336498675.39.0.776636251166.issue14757@psf.upfronthosting.co.za> Message-ID: <1336508322.79.0.759981731607.issue14757@psf.upfronthosting.co.za> Stefan Krah added the comment: This looks quite impressive, so sorry for immediately jumping in with criticism. -- I've benchmarked the things I worked on, and I can't see any speedups but some significant slowdowns. This is on 64-bit Linux with a Core 2 Duo, both versions compiled with just `./configure && make`: Modules/_decimal/tests/bench.py: -------------------------------- Not much change for floats and decimal.py, 8-10% slowdown for _decimal! Telco benchmark [1]: -------------------- 4% slowdown. Memoryview: ----------- ./python -m timeit -n 10000000 -s "x = memoryview(bytearray(b'x'*10000))" "x[:100]" 17% (!) slowdown. Did I perhaps miss some option to turn on the optimizations? [1] http://www.bytereef.org/mpdecimal/quickstart.html#telco-benchmark ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 22:27:10 2012 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 08 May 2012 20:27:10 +0000 Subject: [issue14750] importlib fails with tkinter application on Windows In-Reply-To: <1336477408.86.0.0365400477373.issue14750@psf.upfronthosting.co.za> Message-ID: <1336508830.75.0.850953019134.issue14750@psf.upfronthosting.co.za> Vinay Sajip added the comment: > Does it work with 3.2? I'm not able to build 3.2 - make_buildinfo fails, seemingly because it can't find some Subversion-related files. I'll keep looking into it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 22:58:54 2012 From: report at bugs.python.org (stefan brunthaler) Date: Tue, 08 May 2012 20:58:54 +0000 Subject: [issue14757] INCA: Inline Caching meets Quickening in Python 3.3 In-Reply-To: <1336508322.79.0.759981731607.issue14757@psf.upfronthosting.co.za> Message-ID: stefan brunthaler added the comment: > This looks quite impressive, so sorry for immediately jumping in with > criticism. -- I've benchmarked the things I worked on, and I can't see > any speedups but some significant slowdowns. This is on 64-bit Linux > with a Core 2 Duo, both versions compiled with just `./configure && make`: Well, no problem -- I don't actually consider it criticism at all. Build is correct, you could verify the interpreter working adequatly by running the test suite and seeing some tests depending on specific bytecodes fail (test_dis, and test_importlib, AFAIR). I don't have a Core 2 Duo available for testing, though. > Modules/_decimal/tests/bench.py: > -------------------------------- > > Not much change for floats and decimal.py, 8-10% slowdown for _decimal! This result is not unexpected, as I have no inline cached versions of functions using this module. The derivatives I generate work for Long, Float and Complex numbers (plus Unicode strings and some others.) If there is a clear need, of course I can look into that and add these derivatives (as I said, there are still some 40+ opcodes unused.) > Memoryview: > ----------- > > ./python -m timeit -n 10000000 -s "x = memoryview(bytearray(b'x'*10000))" "x[:100]" > > 17% (!) slowdown. Hm, the 17% slowdown seems strange to me. However, I don't expect to see any speedups in this case, as there is no repeated execution within the benchmark code that could leverage type feedback via inline caching. You should see most speedups when dealing with for-loops (as FOR_ITER has optimized derivatives), if-statements (COMPARE_OP has optimized derivatives), and mathematical code. In addition there are some optimizations for frequently executed function calls, unpacked sequences, etc. Note: frequent as in how I encountered them, probably this needs adjustments for different use cases. > Did I perhaps miss some option to turn on the optimizations? Does not seem to be the case, but if you could verify running the regression tests we could easily eliminate this scenario. You could verifiy speedups, too, on computer language benchmark game benchmarks, primarily binarytrees, mandelbrot, nbody and spectralnorm, just to see how much you *should* gain on your machine. Testing methodology could also make a difference. I use the following: - Linux 3.0.0-17 (Ubuntu) - gcc version 4.6.1 - nice -n -20 to minimize scheduler interference - 30 repetitions per benchmark I hope that helps/explains, regards, --stefan ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 23:09:37 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 08 May 2012 21:09:37 +0000 Subject: [issue14757] INCA: Inline Caching meets Quickening in Python 3.3 In-Reply-To: <1336498675.39.0.776636251166.issue14757@psf.upfronthosting.co.za> Message-ID: <1336511377.89.0.904602999946.issue14757@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well I've just run the benchmark suite from http://hg.python.org/benchmarks/ on a Core i5-2500K under 64-bit Linux with gcc 4.5.2, and got the following results: Report on Linux localhost.localdomain 2.6.38.8-desktop-10.mga #1 SMP Wed Jan 25 10:17:18 UTC 2012 x86_64 x86_64 Total CPU cores: 4 ### call_method ### Min: 0.281984 -> 0.272776: 1.03x faster Avg: 0.284389 -> 0.275780: 1.03x faster Significant (t=34.11) Stddev: 0.00170 -> 0.00258: 1.5137x larger Timeline: http://tinyurl.com/bvr6vgc ### call_method_slots ### Min: 0.284536 -> 0.266709: 1.07x faster Avg: 0.287137 -> 0.268378: 1.07x faster Significant (t=146.85) Stddev: 0.00132 -> 0.00084: 1.5761x smaller Timeline: http://tinyurl.com/c5a2exr ### call_method_unknown ### Min: 0.282038 -> 0.267772: 1.05x faster Avg: 0.286445 -> 0.272408: 1.05x faster Significant (t=36.76) Stddev: 0.00368 -> 0.00289: 1.2735x smaller Timeline: http://tinyurl.com/d9c44cg ### call_simple ### Min: 0.209886 -> 0.199631: 1.05x faster Avg: 0.213417 -> 0.202189: 1.06x faster Significant (t=34.52) Stddev: 0.00304 -> 0.00258: 1.1775x smaller Timeline: http://tinyurl.com/dxes8w7 ### fastunpickle ### Min: 0.400666 -> 0.417532: 1.04x slower Avg: 0.406783 -> 0.426830: 1.05x slower Significant (t=-21.12) Stddev: 0.00427 -> 0.00518: 1.2148x larger Timeline: http://tinyurl.com/c4rp95k ### formatted_logging ### Min: 0.277797 -> 0.301302: 1.08x slower Avg: 0.281376 -> 0.308164: 1.10x slower Significant (t=-37.95) Stddev: 0.00239 -> 0.00438: 1.8378x larger Timeline: http://tinyurl.com/ck9ggaj ### iterative_count ### Min: 0.103784 -> 0.114922: 1.11x slower Avg: 0.105549 -> 0.117207: 1.11x slower Significant (t=-40.04) Stddev: 0.00140 -> 0.00151: 1.0725x larger Timeline: http://tinyurl.com/cffbdw4 ### nbody ### Min: 0.241282 -> 0.228552: 1.06x faster Avg: 0.247193 -> 0.233512: 1.06x faster Significant (t=19.99) Stddev: 0.00369 -> 0.00313: 1.1766x smaller Timeline: http://tinyurl.com/c85oabx ### nqueens ### Min: 0.260105 -> 0.298352: 1.15x slower Avg: 0.263279 -> 0.303216: 1.15x slower Significant (t=-72.55) Stddev: 0.00220 -> 0.00321: 1.4595x larger Timeline: http://tinyurl.com/c4w9qul ### regex_effbot ### Min: 0.061832 -> 0.064062: 1.04x slower Avg: 0.062817 -> 0.066098: 1.05x slower Significant (t=-19.95) Stddev: 0.00071 -> 0.00092: 1.2962x larger Timeline: http://tinyurl.com/bnfh5s3 ### regex_v8 ### Min: 0.063420 -> 0.066753: 1.05x slower Avg: 0.064579 -> 0.067768: 1.05x slower Significant (t=-8.38) Stddev: 0.00186 -> 0.00195: 1.0464x larger Timeline: http://tinyurl.com/bq4uwr4 ### richards ### Min: 0.157204 -> 0.161524: 1.03x slower Avg: 0.159884 -> 0.166099: 1.04x slower Significant (t=-13.74) Stddev: 0.00198 -> 0.00251: 1.2709x larger Timeline: http://tinyurl.com/c774hmy ### silent_logging ### Min: 0.066531 -> 0.071248: 1.07x slower Avg: 0.068753 -> 0.073617: 1.07x slower Significant (t=-16.43) Stddev: 0.00133 -> 0.00162: 1.2181x larger Timeline: http://tinyurl.com/cmg433a ### simple_logging ### Min: 0.265349 -> 0.280200: 1.06x slower Avg: 0.269531 -> 0.285340: 1.06x slower Significant (t=-23.12) Stddev: 0.00295 -> 0.00383: 1.2957x larger Timeline: http://tinyurl.com/dytv5rs ### threaded_count ### Min: 0.102369 -> 0.115217: 1.13x slower Avg: 0.104309 -> 0.117157: 1.12x slower Significant (t=-58.97) Stddev: 0.00113 -> 0.00104: 1.0893x smaller Timeline: http://tinyurl.com/cu4b5hn ### unpack_sequence ### Min: 0.000044 -> 0.000051: 1.18x slower Avg: 0.000045 -> 0.000053: 1.18x slower Significant (t=-557.67) Stddev: 0.00000 -> 0.00000: 1.1571x larger Timeline: http://tinyurl.com/d822sf2 The following not significant results are hidden, use -v to show them: fastpickle, float, json_dump, json_load, normal_startup, pidigits, regex_compile, startup_nosite. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 23:15:50 2012 From: report at bugs.python.org (Ivan Sergeev) Date: Tue, 08 May 2012 21:15:50 +0000 Subject: [issue14758] SMTPServer of smptd does not support binding to an IPv6 address Message-ID: <1336511750.16.0.237606043889.issue14758@psf.upfronthosting.co.za> New submission from Ivan Sergeev : The SMTPServer class of the smtpd module creates a server socket with the IPv4 socket.AF_INET address family hardcoded, and this prevents it from later binding to an IPv6 local address. This occurs on line 282 of smtpd.py for the Python 2.7 branch: http://hg.python.org/cpython/file/5319a4bf72e7/Lib/smtpd.py#l282 And on line 435 of smtpd for the Python 3.2 branch ( Lib/smtpd.py:435 ): http://hg.python.org/cpython/file/d937b527b76e/Lib/smtpd.py#l435 One IPv4/IPv6 agnostic solution is to look up provided local address with getaddrinfo(), and use one of the result's address family, socket type and address tuple for create_socket() and bind() at those lines: ... try: gai_results = socket.getaddrinfo(localaddr[0], localaddr[1]) self.create_socket(gai_results[0][0], gai_results[0][1]) # try to re-use a server port if possible self.set_reuse_addr() self.bind(gai_results[0][4]) self.listen(5) ... ---------- components: Library (Lib) messages: 160226 nosy: vsergeev priority: normal severity: normal status: open title: SMTPServer of smptd does not support binding to an IPv6 address 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 May 8 23:28:17 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 May 2012 21:28:17 +0000 Subject: [issue14727] test_multiprocessing failure under Linux In-Reply-To: <1336209215.05.0.989780505108.issue14727@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 3d900c9641c9 by Richard Oudkerk in branch 'default': Issue #14727: Fix race in test_multiprocessing http://hg.python.org/cpython/rev/3d900c9641c9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 23:28:51 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 08 May 2012 21:28:51 +0000 Subject: [issue14757] INCA: Inline Caching meets Quickening in Python 3.3 In-Reply-To: <1336498675.39.0.776636251166.issue14757@psf.upfronthosting.co.za> Message-ID: <1336512531.1.0.531947476087.issue14757@psf.upfronthosting.co.za> Stefan Krah added the comment: Here are my perf.py results: Report on Linux localhost 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43 UTC 2011 x86_64 Total CPU cores: 2 ### call_method_unknown ### Min: 0.345289 -> 0.358096: 1.04x slower Avg: 0.345678 -> 0.358167: 1.04x slower Significant (t=-713.58) Stddev: 0.00019 -> 0.00010: 1.7897x smaller Timeline: b'http://tinyurl.com/c9k7oxu' ### call_simple ### Min: 0.297635 -> 0.239782: 1.24x faster Avg: 0.297788 -> 0.240961: 1.24x faster Significant (t=1183.63) Stddev: 0.00020 -> 0.00055: 2.7115x larger Timeline: b'http://tinyurl.com/c769rmj' ### fastunpickle ### Min: 0.640831 -> 0.629214: 1.02x faster Avg: 0.646831 -> 0.630471: 1.03x faster Significant (t=34.25) Stddev: 0.00324 -> 0.00095: 3.4098x smaller Timeline: b'http://tinyurl.com/cpyrcoy' ### float ### Min: 0.067458 -> 0.070712: 1.05x slower Avg: 0.069109 -> 0.072166: 1.04x slower Significant (t=-27.33) Stddev: 0.00119 -> 0.00131: 1.0939x larger Timeline: b'http://tinyurl.com/c2mhk5o' ### iterative_count ### Min: 0.132501 -> 0.157027: 1.19x slower Avg: 0.132724 -> 0.157425: 1.19x slower Significant (t=-628.41) Stddev: 0.00015 -> 0.00023: 1.5093x larger Timeline: b'http://tinyurl.com/7auyflz' ### json_dump ### Min: 0.569771 -> 0.588654: 1.03x slower Avg: 0.571149 -> 0.589615: 1.03x slower Significant (t=-101.32) Stddev: 0.00094 -> 0.00088: 1.0689x smaller Timeline: b'http://tinyurl.com/d4hhfjh' ### nbody ### Min: 0.283447 -> 0.274458: 1.03x faster Avg: 0.289093 -> 0.281663: 1.03x faster Significant (t=6.47) Stddev: 0.00764 -> 0.00276: 2.7642x smaller Timeline: b'http://tinyurl.com/7483dap' ### normal_startup ### Min: 0.649437 -> 0.666486: 1.03x slower Avg: 0.650395 -> 0.669678: 1.03x slower Significant (t=-10.47) Stddev: 0.00048 -> 0.01302: 27.2168x larger Timeline: b'http://tinyurl.com/d773p3c' ### nqueens ### Min: 0.380882 -> 0.390680: 1.03x slower Avg: 0.382476 -> 0.391790: 1.02x slower Significant (t=-56.25) Stddev: 0.00069 -> 0.00095: 1.3821x larger Timeline: b'http://tinyurl.com/c49drdo' ### regex_compile ### Min: 0.544866 -> 0.564778: 1.04x slower Avg: 0.546157 -> 0.565641: 1.04x slower Significant (t=-159.84) Stddev: 0.00076 -> 0.00041: 1.8308x smaller Timeline: b'http://tinyurl.com/cxv3s5n' ### richards ### Min: 0.217447 -> 0.233456: 1.07x slower Avg: 0.220199 -> 0.235870: 1.07x slower Significant (t=-55.49) Stddev: 0.00154 -> 0.00127: 1.2111x smaller Timeline: b'http://tinyurl.com/7h5zd82' ### silent_logging ### Min: 0.088886 -> 0.086601: 1.03x faster Avg: 0.089748 -> 0.087314: 1.03x faster Significant (t=27.06) Stddev: 0.00056 -> 0.00030: 1.8744x smaller Timeline: b'http://tinyurl.com/6mub6j8' ### simple_logging ### Min: 0.384265 -> 0.394479: 1.03x slower Avg: 0.386462 -> 0.396793: 1.03x slower Significant (t=-28.26) Stddev: 0.00189 -> 0.00177: 1.0687x smaller Timeline: b'http://tinyurl.com/cwacrva' ### threaded_count ### Min: 0.149418 -> 0.213361: 1.43x slower Avg: 0.195123 -> 0.224733: 1.15x slower Significant (t=-17.77) Stddev: 0.01011 -> 0.00604: 1.6744x smaller Timeline: b'http://tinyurl.com/chh36kr' ### unpack_sequence ### Min: 0.000054 -> 0.000063: 1.17x slower Avg: 0.000054 -> 0.000064: 1.17x slower Significant (t=-1952.49) Stddev: 0.00000 -> 0.00000: 2.2326x smaller Timeline: b'http://tinyurl.com/6nps6ew' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 23:55:03 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 08 May 2012 21:55:03 +0000 Subject: [issue5945] PyMapping_Check returns 1 for lists In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za> Message-ID: <1336514103.85.0.238640524688.issue5945@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 8 23:57:56 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 08 May 2012 21:57:56 +0000 Subject: [issue14727] test_multiprocessing failure under Linux In-Reply-To: <1336209215.05.0.989780505108.issue14727@psf.upfronthosting.co.za> Message-ID: <1336514276.2.0.391323621535.issue14727@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I found a race where a connection attempt could happen before the listening socket's listen() method was called. Vinay, could you update and try again please. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 00:00:14 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 08 May 2012 22:00:14 +0000 Subject: [issue14757] INCA: Inline Caching meets Quickening in Python 3.3 In-Reply-To: Message-ID: <20120508220012.GA14881@sleipnir.bytereef.org> Stefan Krah added the comment: > > Modules/_decimal/tests/bench.py: > > -------------------------------- > > > > Not much change for floats and decimal.py, 8-10% slowdown for _decimal! > > This result is not unexpected, as I have no inline cached versions of > functions using this module. The derivatives I generate work for Long, > Float and Complex numbers (plus Unicode strings and some others.) But I couldn't detect a speedup for either float or int in bench.py. Also, in perf.py I'm consistently getting slower results for float with the patch. > there is a clear need, of course I can look into that and add these > derivatives (as I said, there are still some 40+ opcodes unused.) I'd say that the minimum requirement for a performance enhancement patch is that there aren't any slowdowns. :) I'm getting a 9% speedup for mandelbrot and an 18% speedup for spectralnorm. That's nice, but many benchmarks that Antoine and I have posted show slowdowns of 15-18%. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 00:00:20 2012 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 08 May 2012 22:00:20 +0000 Subject: [issue14750] Tkinter application doesn't run from source build on Windows In-Reply-To: <1336477408.86.0.0365400477373.issue14750@psf.upfronthosting.co.za> Message-ID: <1336514420.21.0.823555057825.issue14750@psf.upfronthosting.co.za> Vinay Sajip added the comment: The test script works if tcl85.dll and tk85.dll are copied into the build directory. This can be done using a small batch file and the XML added to each build configuration in PCbuild\_tkinter.vcproj (can be added through the UI, of course). ---------- components: +Tkinter keywords: +needs review, patch nosy: +gpolo -brett.cannon stage: -> patch review title: importlib fails with tkinter application on Windows -> Tkinter application doesn't run from source build on Windows Added file: http://bugs.python.org/file25500/copy_tcl.bat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 00:14:23 2012 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 08 May 2012 22:14:23 +0000 Subject: [issue14727] test_multiprocessing failure under Linux In-Reply-To: <1336209215.05.0.989780505108.issue14727@psf.upfronthosting.co.za> Message-ID: <1336515263.43.0.736366746536.issue14727@psf.upfronthosting.co.za> Vinay Sajip added the comment: test_multiprocessing now passes. Thanks for the quick turnaround. ---------- assignee: -> sbt resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 00:30:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 08 May 2012 22:30:09 +0000 Subject: [issue14758] SMTPServer of smptd does not support binding to an IPv6 address In-Reply-To: <1336511750.16.0.237606043889.issue14758@psf.upfronthosting.co.za> Message-ID: <1336516209.04.0.283491688496.issue14758@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +giampaolo.rodola, r.david.murray stage: -> needs patch type: behavior -> enhancement versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 00:55:20 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 08 May 2012 22:55:20 +0000 Subject: [issue14735] Version 3.2.3 IDLE CTRL-Z plus Carriage Return to end does not work In-Reply-To: <1336252501.23.0.54042826511.issue14735@psf.upfronthosting.co.za> Message-ID: <1336517720.28.0.491284864098.issue14735@psf.upfronthosting.co.za> Changes by Roger Serwy : ---------- keywords: +patch Added file: http://bugs.python.org/file25501/ctrl_z_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 01:47:34 2012 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 08 May 2012 23:47:34 +0000 Subject: [issue14758] SMTPServer of smptd does not support binding to an IPv6 address In-Reply-To: <1336511750.16.0.237606043889.issue14758@psf.upfronthosting.co.za> Message-ID: <1336520854.55.0.820354191779.issue14758@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Agreed. The only problem I see is that unit tests rely on a mock socket object and should be rewritten by using an actual socket. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 01:48:59 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 08 May 2012 23:48:59 +0000 Subject: [issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper In-Reply-To: <1326892577.13.0.456815776311.issue13815@psf.upfronthosting.co.za> Message-ID: <1336520939.58.0.950809162619.issue13815@psf.upfronthosting.co.za> R. David Murray added the comment: Indeed, even though it is not a documented API, our backward compatibility policy pretty much requires that something named ExFileObject still exist, just in case. And in this case it probably should still be the thing returned. ---------- nosy: +r.david.murray status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 01:58:35 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 08 May 2012 23:58:35 +0000 Subject: [issue14758] SMTPServer of smptd does not support binding to an IPv6 address In-Reply-To: <1336511750.16.0.237606043889.issue14758@psf.upfronthosting.co.za> Message-ID: <1336521515.9.0.413763673571.issue14758@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think it is necessary to rewrite the existing tests, just add some that test the socket functionality. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 01:58:42 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 May 2012 23:58:42 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336428561.46.0.842580483885.issue14744@psf.upfronthosting.co.za> Message-ID: <1336521522.38.0.748341957924.issue14744@psf.upfronthosting.co.za> STINNER Victor added the comment: > Fill the ascii buffer and then copying can be cheaper than using > _PyUnicodeWriter with general non-ascii string. Here is a new patch using _PyUnicodeWriter directly in longobject.c. According to my benchmark (see below), formating a small number (5 decimal digits) is 17% faster with my patch version 2 compared to tip, and 38% faster compared to Python 3.3 before my optimizations on str%tuples or str.format(). Creating a temporary PyUnicode is not cheap, at least for short strings. str%tuple and str.format() allocates len(format_string)+100 ASCII characters at the beginning, which is enough for "x={}".format(12345) for example. So only a resize is needed, and it looks like resizing is cheap. I'm not completly satisfied of the usage of Py_LOCAL_INLINE in unicodeobject.c for _PyUnicodeWriter methods. The same "hacks" (?) should be used in formatter_unicode.c. Shell script (bench.sh) used to benchmark: -------- echo -n "{0}.{1}.{2}: "; ./python -m timeit -r 10 -s 'fmt="{0}.{1}.{2}"' 'fmt.format("http", "client", "HTTPConnection")' echo -n " [line {0:2d}] : "; ./python -m timeit -r 10 -s 'fmt=" [line {0:2d}] "' 'fmt.format(5)' echo -n "str: "; ./python -m timeit -r 10 -s 'fmt="{0}"*100' 'fmt.format("ABCDEF")' echo -n "str conv: "; ./python -m timeit -r 10 -s 'fmt="{0:s}"*100' 'fmt.format("ABCDEF")' echo -n "long x 3: "; ./python -m timeit -r 10 -s 'fmt="x={0} x={0} x={0}"' 'fmt.format(12345)' echo -n "float x 3: "; ./python -m timeit -r 10 -s 'fmt="x={0} x={0} x={0}"' 'fmt.format(12.345)' echo -n "complex x 3: "; ./python -m timeit -r 10 -s 'fmt="x={0} x={0} x={0}"' 'fmt.format(12.345+2j)' echo -n "long, float, complex: "; ./python -m timeit -r 10 -s 'fmt="x={} y={} z={}"' 'fmt.format(12345, 12.345, 12.345+2j)' echo -n "huge long: "; ./python -m timeit -r 10 -s 'import math; huge=math.factorial(2000); fmt="x={}"' 'fmt.format(huge)' -------- Results: -------- 3.3: {0}.{1}.{2}: 1000000 loops, best of 10: 0.394 usec per loop [line {0:2d}] : 1000000 loops, best of 10: 0.519 usec per loop str: 100000 loops, best of 10: 7.01 usec per loop str conv: 100000 loops, best of 10: 13.3 usec per loop long x 3: 1000000 loops, best of 10: 0.569 usec per loop float x 3: 1000000 loops, best of 10: 1.62 usec per loop complex x 3: 100000 loops, best of 10: 3.34 usec per loop long, float, complex: 100000 loops, best of 10: 2.08 usec per loop huge long: 1000 loops, best of 10: 666 usec per loop 3.3 + format_writer.patch : {0}.{1}.{2}: 1000000 loops, best of 10: 0.412 usec per loop (+5%) [line {0:2d}] : 1000000 loops, best of 10: 0.461 usec per loop (-11%) str: 100000 loops, best of 10: 6.85 usec per loop (-2%) str conv: 100000 loops, best of 10: 11.1 usec per loop (-17%) long x 3: 1000000 loops, best of 10: 0.605 usec per loop (+6%) float x 3: 1000000 loops, best of 10: 1.57 usec per loop (-3%) complex x 3: 100000 loops, best of 10: 3.54 usec per loop (+6%) long, float, complex: 100000 loops, best of 10: 2.19 usec per loop (+5%) huge long: 1000 loops, best of 10: 665 usec per loop (0%) 3.3 + format_writer-2.patch : {0}.{1}.{2}: 1000000 loops, best of 10: 0.378 usec per loop (-4%) [line {0:2d}] : 1000000 loops, best of 10: 0.454 usec per loop (-13%) str: 100000 loops, best of 10: 6.18 usec per loop (-12%) str conv: 100000 loops, best of 10: 10.9 usec per loop (-18%) long x 3: 1000000 loops, best of 10: 0.471 usec per loop (-17%) float x 3: 1000000 loops, best of 10: 1.37 usec per loop (-15%) complex x 3: 100000 loops, best of 10: 3.4 usec per loop (+2%) long, float, complex: 1000000 loops, best of 10: 1.93 usec per loop (-7%) huge long: 1000 loops, best of 10: 665 usec per loop (0%) -------- ---------- Added file: http://bugs.python.org/file25502/format_writer-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 02:33:13 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 09 May 2012 00:33:13 +0000 Subject: [issue10765] Build regression from automation changes on windows In-Reply-To: <1293146347.8.0.828425848028.issue10765@psf.upfronthosting.co.za> Message-ID: <1336523593.27.0.38704054603.issue10765@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As there is an easy work-around (just don't use spaces in directory names), I still consider this issue as irrelevant as two years ago. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 03:08:20 2012 From: report at bugs.python.org (Jeff Laing) Date: Wed, 09 May 2012 01:08:20 +0000 Subject: [issue14759] Berkeley DB License conditions are onerous (and poorly documented) Message-ID: <1336525700.66.0.626657341837.issue14759@psf.upfronthosting.co.za> New submission from Jeff Laing : As part of an audit of license compliance, I was looking at the terms in the LICENSE.txt that describe the Berkeley DB product. I had thought this would be under the standard Berkeley license, but Oracle have added their own zinger. * 3. Redistributions in any form must be accompanied by information on * how to obtain complete source code for the DB software and any * accompanying software that uses the DB software. The source code * must either be included in the distribution or be available for no * more than the cost of distribution plus a nominal fee, and must be * freely redistributable under reasonable conditions. So, my application, which embeds Python (rather than running it as python.exe) and includes the standard runtime library, must distribute my source code. This page: http://mail.python.org/pipermail/python-dev/2008-September/082316.html suggests that this is not the case for regular Python, but it makes no statement about "embedding". Sadly the Oracle page it links to suggesting this is not an issue, does not exist. The general "License" page on the Python websites makes no reference whatsoever to Berkeley DB license obligations. I note that there are other modules mentioned on the Licenses webpage that are not in the LICENSES.txt file, and vice versa. I have no idea whether this is deliberate, or an oversight. ---------- assignee: docs at python components: Documentation messages: 160238 nosy: Jeff.Laing, docs at python priority: normal severity: normal status: open title: Berkeley DB License conditions are onerous (and poorly documented) type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 03:19:51 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 09 May 2012 01:19:51 +0000 Subject: [issue14759] Berkeley DB License conditions are onerous (and poorly documented) In-Reply-To: <1336525700.66.0.626657341837.issue14759@psf.upfronthosting.co.za> Message-ID: <1336526391.87.0.737354617878.issue14759@psf.upfronthosting.co.za> R. David Murray added the comment: Berkeley DB is no longer part of Python3, so I'm doubtful that this is going to be addressed. If it is addressed, it would have to be by the PSF rather than the developers, since the PSF is responsible for licensing issues. If you wish to pursue this I suggest emailing psf at python.org. I'm going to close this ticket since there is nothing the developers can do about it. ---------- nosy: +r.david.murray stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 04:06:21 2012 From: report at bugs.python.org (Jeff Laing) Date: Wed, 09 May 2012 02:06:21 +0000 Subject: [issue14759] Berkeley DB License conditions are onerous (and poorly documented) In-Reply-To: <1336525700.66.0.626657341837.issue14759@psf.upfronthosting.co.za> Message-ID: <1336529181.09.0.842581998436.issue14759@psf.upfronthosting.co.za> Jeff Laing added the comment: With all due respect, I think that the 2.7.3 License Page is still being actively used by people as a reference, and it should be accurate. I agree that the code developers can't do anything, but the documentation for all releases, particularly in such a sensitive area as licensing, should be as up to date as possible. Similarly, the 3.0 License page talks about a "_random" module which presumably is going ahead. It has a license agreement displayed on the web page but I did not see that text copied into the regular LICENSE.txt that is part of the Python3 distribution, and that I assume meets the "supporting documentation" clause that all the module licenses seem to demand. Ditto socket. Ditto asyncore and asynchat. Ditto Cookie. Ditto trace. Ditto xmlrpclib. etcetera. I agree this is all a documentation exercise - perhaps there is another bug tracker I should be reporting it in? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 04:56:05 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 09 May 2012 02:56:05 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1336532165.94.0.3617242386.issue13210@psf.upfronthosting.co.za> Brian Curtin added the comment: The tip of the vs2010 branch now works just as well as default does. There are no outstanding test failures that aren't seen on default -- test_email still fails for some line ending stuff, but that's not relevant here. Attached is a patch showing just the code changes, including Kristjan's SXS patch, support in Tools\msi\msi.py for VS2010, and a few small distutils and packaging version adjustments to work with VS2010. ---------- keywords: +needs review stage: -> patch review Added file: http://bugs.python.org/file25503/code_changes2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 04:58:30 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 09 May 2012 02:58:30 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1336532310.51.0.773663860142.issue13210@psf.upfronthosting.co.za> Brian Curtin added the comment: Attached is full_vs2010_port.diff. It's 13000 lines, mostly taken up by the conversion of project, filter, and solution files - tons of XML. ---------- Added file: http://bugs.python.org/file25504/full_vs2010_port.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 05:06:38 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 09 May 2012 03:06:38 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1336532798.26.0.296319831887.issue13210@psf.upfronthosting.co.za> ?ric Araujo added the comment: Strange that you had to edit packaging.compiler.msvc9compiler but not the same module in distutils. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 07:38:24 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 09 May 2012 05:38:24 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336521522.38.0.748341957924.issue14744@psf.upfronthosting.co.za> Message-ID: <1336541782.3352.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > According to my benchmark (see below), formating a small number (5 > decimal digits) is 17% faster with my patch version 2 compared to tip, > and 38% faster compared to Python 3.3 before my optimizations on str% > tuples or str.format(). Creating a temporary PyUnicode is not cheap, > at least for short strings. A 17% improvement on a micro-benchmark is not much. There will probably be no visible difference in real-world code. Also, if creating temporary PyUnicodes is not cheap, perhaps we could have a freelist for them? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 08:22:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 09 May 2012 06:22:08 +0000 Subject: [issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper In-Reply-To: <1326892577.13.0.456815776311.issue13815@psf.upfronthosting.co.za> Message-ID: <1336544528.25.0.24924868651.issue13815@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, if it's not documented, it's technically a private API. Also, there doesn't seem to be any explicit use of ExFileObject outside of tarfile.py: http://code.google.com/codesearch#search&q=lang:python+exfileobject ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 08:22:28 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 09 May 2012 06:22:28 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1336544548.58.0.845516464915.issue13210@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'd say go ahead and apply it. We can deal with any aftermath later (which, by my VS 2008 experience, will well take several years - we still haven't fully recovered from the switch to VS 2008). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 08:29:23 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 09 May 2012 06:29:23 +0000 Subject: [issue14746] Remove redundant paragraphs from getargs.c skipitem() In-Reply-To: <1336433092.13.0.553393159676.issue14746@psf.upfronthosting.co.za> Message-ID: <1336544963.54.0.773899506491.issue14746@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not sure what you're proposing to fix. It seems to save at most a couple of lines of (obvious) code? At least Py_ssize_t *could* have a different width from "PyObject *". ---------- nosy: +mark.dickinson, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 08:36:31 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 09 May 2012 06:36:31 +0000 Subject: [issue14746] Remove redundant paragraphs from getargs.c skipitem() In-Reply-To: <1336433092.13.0.553393159676.issue14746@psf.upfronthosting.co.za> Message-ID: <1336545391.09.0.619149277595.issue14746@psf.upfronthosting.co.za> Larry Hastings added the comment: > I'm not sure what you're proposing to fix. It seems to save at > most a couple of lines of (obvious) code? Well, I *did* specify low priority. Attached is the patch for what I had in mind. > At least Py_ssize_t *could* have a different width from "PyObject *". Not "Py_ssize_t", "Py_ssize_t *". ---------- keywords: +patch Added file: http://bugs.python.org/file25505/larry.prune.skipitem.1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 08:44:43 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 09 May 2012 06:44:43 +0000 Subject: [issue14746] Remove redundant paragraphs from getargs.c skipitem() In-Reply-To: <1336545391.09.0.619149277595.issue14746@psf.upfronthosting.co.za> Message-ID: <1336545760.3352.2.camel@localhost.localdomain> Antoine Pitrou added the comment: > > At least Py_ssize_t *could* have a different width from "PyObject *". > > Not "Py_ssize_t", "Py_ssize_t *". Ah, fair enough then. Looks ok to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 08:52:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 May 2012 06:52:26 +0000 Subject: [issue14746] Remove redundant paragraphs from getargs.c skipitem() In-Reply-To: <1336433092.13.0.553393159676.issue14746@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 8ab37fa24e58 by Larry Hastings in branch 'default': Issue #14746: Remove redundant paragraphs from skipitem() in Python/getargs.c. http://hg.python.org/cpython/rev/8ab37fa24e58 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 08:53:16 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 09 May 2012 06:53:16 +0000 Subject: [issue14746] Remove redundant paragraphs from getargs.c skipitem() In-Reply-To: <1336433092.13.0.553393159676.issue14746@psf.upfronthosting.co.za> Message-ID: <1336546396.37.0.492833017648.issue14746@psf.upfronthosting.co.za> Larry Hastings added the comment: Thanks for the double-check. I should have more confidence! ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 09:15:19 2012 From: report at bugs.python.org (anatoly techtonik) Date: Wed, 09 May 2012 07:15:19 +0000 Subject: [issue14760] logging: make setLevel() return handler itself for chained configuration Message-ID: <1336547719.78.0.572014137028.issue14760@psf.upfronthosting.co.za> New submission from anatoly techtonik : It would be convenient if instead of: hdlr = logging.StreamHandler() hglr.setLevel(logging.DEBUG) root.addHandler(hdlr) it would be possible to write: root.addHandler(logging.StreamHandler().setLevel(logging.DEBUG)) ---------- components: Library (Lib) messages: 160252 nosy: techtonik priority: normal severity: normal status: open title: logging: make setLevel() return handler itself for chained configuration _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 09:24:48 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 09 May 2012 07:24:48 +0000 Subject: [issue14245] float rounding examples in FAQ are outdated In-Reply-To: <1331372112.92.0.532785259032.issue14245@psf.upfronthosting.co.za> Message-ID: <1336548288.92.0.142722066117.issue14245@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: docs at python -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 09:25:13 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 09 May 2012 07:25:13 +0000 Subject: [issue14591] Value returned by random.random() out of valid range on 64-bit In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1336548313.62.0.428824721001.issue14591@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 09:25:48 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 09 May 2012 07:25:48 +0000 Subject: [issue14742] test_tools very slow In-Reply-To: <1336419915.88.0.52212163456.issue14742@psf.upfronthosting.co.za> Message-ID: <1336548348.9.0.127950578069.issue14742@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 09:42:04 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 09 May 2012 07:42:04 +0000 Subject: [issue14760] logging: make setLevel() return handler itself for chained configuration In-Reply-To: <1336547719.78.0.572014137028.issue14760@psf.upfronthosting.co.za> Message-ID: <1336549324.66.0.732613537671.issue14760@psf.upfronthosting.co.za> Georg Brandl added the comment: -1. Attribute setters or mutating methods returning self is not a common pattern in Python. See list.sort(). ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 09:51:34 2012 From: report at bugs.python.org (anatoly techtonik) Date: Wed, 09 May 2012 07:51:34 +0000 Subject: [issue14760] logging: make setLevel() return handler itself for chained configuration In-Reply-To: <1336547719.78.0.572014137028.issue14760@psf.upfronthosting.co.za> Message-ID: <1336549894.65.0.955892799835.issue14760@psf.upfronthosting.co.za> anatoly techtonik added the comment: List is a standard type and it have None returned for a reson. Logging is a library with its own semantic and high level object. Here you don't need to return None to explicitly say that the object was modified in place. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 09:53:52 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 09 May 2012 07:53:52 +0000 Subject: [issue14760] logging: make setLevel() return handler itself for chained configuration In-Reply-To: <1336547719.78.0.572014137028.issue14760@psf.upfronthosting.co.za> Message-ID: <1336550032.21.0.192513822983.issue14760@psf.upfronthosting.co.za> Georg Brandl added the comment: Well, can you find any other setter method of a "high level object" in the stdlib that returns self? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 09:58:15 2012 From: report at bugs.python.org (anatoly techtonik) Date: Wed, 09 May 2012 07:58:15 +0000 Subject: [issue14760] logging: make setLevel() return handler itself for chained configuration In-Reply-To: <1336547719.78.0.572014137028.issue14760@psf.upfronthosting.co.za> Message-ID: <1336550295.03.0.744383742362.issue14760@psf.upfronthosting.co.za> anatoly techtonik added the comment: Well, I can remember any other widely used high level objects from stdlib either. HTTP servers perhaps, but they are in a poor state. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 09:58:48 2012 From: report at bugs.python.org (anatoly techtonik) Date: Wed, 09 May 2012 07:58:48 +0000 Subject: [issue14760] logging: make setLevel() return handler itself for chained configuration In-Reply-To: <1336547719.78.0.572014137028.issue14760@psf.upfronthosting.co.za> Message-ID: <1336550328.93.0.981612433609.issue14760@psf.upfronthosting.co.za> anatoly techtonik added the comment: s/can/can't/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 10:02:33 2012 From: report at bugs.python.org (anatoly techtonik) Date: Wed, 09 May 2012 08:02:33 +0000 Subject: [issue14760] logging: make setLevel() return handler itself for chained configuration In-Reply-To: <1336547719.78.0.572014137028.issue14760@psf.upfronthosting.co.za> Message-ID: <1336550553.78.0.300295345632.issue14760@psf.upfronthosting.co.za> anatoly techtonik added the comment: Well, there is argparse, but it doesn't support method chaining. Whatever, it is just a proposal. If consistency inside stdlib covers calling conventions for bundled user-level libs - I am fine with that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 10:03:22 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 May 2012 08:03:22 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336521522.38.0.748341957924.issue14744@psf.upfronthosting.co.za> Message-ID: <1336550749.2591.22.camel@raxxla> Serhiy Storchaka added the comment: > Here is a new patch using _PyUnicodeWriter directly in longobject.c. It may be worth to do it in a separate issue? decimal digits) is 17% faster with my patch version 2 compared to tip, and 38% faster compared to Python 3.3 before my optimizations on str% tuples or str.format(). Creating a temporary PyUnicode is not cheap, at least for short strings. Here is my benchmark script (attached) and the results: Python 3.3 (vanilla): 1.65 str(12345) 2.6 '{}'.format(12345) 2.69 'A{}'.format(12345) 3.16 '\x80{}'.format(12345) 3.23 '\u0100{}'.format(12345) 3.32 '\U00010000{}'.format(12345) 4.6 '{:-10}'.format(12345) 4.89 'A{:-10}'.format(12345) 5.53 '\x80{:-10}'.format(12345) 5.71 '\u0100{:-10}'.format(12345) 5.63 '\U00010000{:-10}'.format(12345) 4.6 '{:,}'.format(12345) 4.71 'A{:,}'.format(12345) 5.28 '\x80{:,}'.format(12345) 5.65 '\u0100{:,}'.format(12345) 5.59 '\U00010000{:,}'.format(12345) Python 3.3 + format_writer.patch: 1.72 str(12345) 2.74 '{}'.format(12345) 2.99 'A{}'.format(12345) 3.4 '\x80{}'.format(12345) 3.52 '\u0100{}'.format(12345) 3.51 '\U00010000{}'.format(12345) 4.24 '{:-10}'.format(12345) 4.6 'A{:-10}'.format(12345) 5.16 '\x80{:-10}'.format(12345) 6.87 '\u0100{:-10}'.format(12345) 6.83 '\U00010000{:-10}'.format(12345) 4.12 '{:,}'.format(12345) 4.6 'A{:,}'.format(12345) 5.09 '\x80{:,}'.format(12345) 6.63 '\u0100{:,}'.format(12345) 6.42 '\U00010000{:,}'.format(12345) Python 3.3 + format_writer-2.patch: 1.91 str(12345) 2.44 '{}'.format(12345) 2.61 'A{}'.format(12345) 3.08 '\x80{}'.format(12345) 3.31 '\u0100{}'.format(12345) 3.13 '\U00010000{}'.format(12345) 4.57 '{:-10}'.format(12345) 4.96 'A{:-10}'.format(12345) 5.52 '\x80{:-10}'.format(12345) 7.01 '\u0100{:-10}'.format(12345) 7.34 '\U00010000{:-10}'.format(12345) 4.42 '{:,}'.format(12345) 4.76 'A{:,}'.format(12345) 5.16 '\x80{:,}'.format(12345) 7.2 '\u0100{:,}'.format(12345) 6.74 '\U00010000{:,}'.format(12345) As you can see, there is a regress, and sometimes it is not less than improvement. ---------- Added file: http://bugs.python.org/file25506/issue14744-bench-1.py _______________________________________ Python tracker _______________________________________ -------------- next part -------------- import timeit def bench(stmt, msg=None, number=100000): if msg is None: msg = stmt best = min(timeit.repeat(stmt, number=number)) print("%.3g\t%s" % (best * 1e6 / number, msg)) bench('str(12345)') for s in ('', 'A', '\u0080', '\u0100', '\U00010000'): bench('%a.format(12345)' % (s + '{}',)) for s in ('', 'A', '\u0080', '\u0100', '\U00010000'): bench('%a.format(12345)' % (s + '{:-10}',)) for s in ('', 'A', '\u0080', '\u0100', '\U00010000'): bench('%a.format(12345)' % (s + '{:,}',)) From report at bugs.python.org Wed May 9 10:12:11 2012 From: report at bugs.python.org (Martin Panter) Date: Wed, 09 May 2012 08:12:11 +0000 Subject: [issue14653] Improve mktime_tz to use calendar.timegm instead of time.mktime In-Reply-To: <1335213212.56.0.724242644314.issue14653@psf.upfronthosting.co.za> Message-ID: <1336551131.72.0.542210979174.issue14653@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 10:18:26 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Wed, 09 May 2012 08:18:26 +0000 Subject: [issue14758] SMTPServer of smptd does not support binding to an IPv6 address In-Reply-To: <1336511750.16.0.237606043889.issue14758@psf.upfronthosting.co.za> Message-ID: <1336551506.29.0.103594175837.issue14758@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 10:20:32 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 09 May 2012 08:20:32 +0000 Subject: [issue1439312] Patch for bug 1438185: os.renames deletes junction points Message-ID: <1336551632.44.0.970479956971.issue1439312@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.3 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 10:34:17 2012 From: report at bugs.python.org (Arthur Kantor) Date: Wed, 09 May 2012 08:34:17 +0000 Subject: [issue1378] fromfd() and dup() for _socket on WIndows In-Reply-To: <1194103455.44.0.390687208828.issue1378@psf.upfronthosting.co.za> Message-ID: <1336552457.09.0.879969490736.issue1378@psf.upfronthosting.co.za> Arthur Kantor added the comment: Hi guys It appears, that this patch was meant to go into both the 2.x and 3.x series, but it never made into 2.x Are there still plans to apply it to 2.7? (apologies if I'm asking this in the wrong forum) ---------- nosy: +Arthur.Kantor versions: +Python 2.7 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 10:42:06 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 09 May 2012 08:42:06 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1336552926.77.0.402912739216.issue13210@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: I concur with Martin. It is much easier to tweak .vcproj and .props files and such after it has been committed, with lesser diffs to worry about. (A more cautious version of me would have seen this go into a PCBuild10 folder first for a shakedown, with a later rename, but I keep that guy and his fearmongering quiet most of the time.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 10:45:55 2012 From: report at bugs.python.org (Damien Cassou) Date: Wed, 09 May 2012 08:45:55 +0000 Subject: [issue14761] Memleak in import.c load_source_module() Message-ID: <1336553155.13.0.322701630685.issue14761@psf.upfronthosting.co.za> New submission from Damien Cassou : In load_source_module() function from import.c, it looks like Py_DECREF is not called where it should be. Please find attached a patch that fixes the leak. This bug has been found using Coccinelle (http://coccinelle.lip6.fr/) using a semantic patch (similar to https://gist.github.com/2634899). ---------- components: Interpreter Core files: fix_load_source_module_leak.patch keywords: patch messages: 160262 nosy: benjamin.peterson, cassou, lemburg, tim_one priority: normal severity: normal status: open title: Memleak in import.c load_source_module() versions: Python 2.7 Added file: http://bugs.python.org/file25507/fix_load_source_module_leak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 10:47:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 09 May 2012 08:47:11 +0000 Subject: [issue14591] Value returned by random.random() out of valid range on 64-bit In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1336553231.73.0.437052435508.issue14591@psf.upfronthosting.co.za> Antoine Pitrou added the comment: In test_random, you should use assertLess so that the offending value is displayed on failure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 10:47:59 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 09 May 2012 08:47:59 +0000 Subject: [issue14761] Memleak in import.c load_source_module() In-Reply-To: <1336553155.13.0.322701630685.issue14761@psf.upfronthosting.co.za> Message-ID: <1336553279.71.0.65303596871.issue14761@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Is it 2.7-only? ---------- nosy: +brett.cannon, ncoghlan, pitrou stage: -> patch review type: -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 10:51:59 2012 From: report at bugs.python.org (Damien Cassou) Date: Wed, 09 May 2012 08:51:59 +0000 Subject: [issue14761] Memleak in import.c load_source_module() In-Reply-To: <1336553155.13.0.322701630685.issue14761@psf.upfronthosting.co.za> Message-ID: <1336553519.74.0.936360886577.issue14761@psf.upfronthosting.co.za> Damien Cassou added the comment: @pitrou I just checked Python-2.7.3 and the tip of the mercurial repository. It's not in the latter at least. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 11:39:47 2012 From: report at bugs.python.org (Giuseppe Attardi) Date: Wed, 09 May 2012 09:39:47 +0000 Subject: [issue14762] ElementTree memory leak Message-ID: <1336556387.72.0.794459300498.issue14762@psf.upfronthosting.co.za> New submission from Giuseppe Attardi : I confirm the presence of a serious memory leak in ElementTree, using the iterparse() function. Memory grows disproportionately to dozens of GB when parsing a large XML file. For further information, see discussion in: http://www.gossamer-threads.com/lists/python/bugs/912164?do=post_view_threaded#912164 but notice that the comments attributing the problem to the OS are quite off the mark. To replicate the problem, try this on a Wikipedia dump: iterparse = ElementTree.iterparse(file) id = None for event, elem in iterparse: if elem.tag.endswith("title"): title = elem.text elif elem.tag.endswith("id") and not id: id = elem.text elif elem.tag.endswith("text"): print id, title, elem.text[:20] ---------- messages: 160266 nosy: Giuseppe.Attardi priority: normal severity: normal status: open title: ElementTree memory leak type: resource usage versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 11:56:35 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 09 May 2012 09:56:35 +0000 Subject: [issue9751] _PyInstance_Lookup() defeats its purpose In-Reply-To: <1283506212.5.0.831864167364.issue9751@psf.upfronthosting.co.za> Message-ID: <1336557395.06.0.289811016399.issue9751@psf.upfronthosting.co.za> Ezio Melotti added the comment: I tracked this down a bit and this is what I found: has_finalizer in Modules/gcmodule.c calls return _PyInstance_Lookup(op, delstr) != NULL; _PyInstance_Lookup in Modules/classobject.c calls v = class_lookup(inst->in_class, name, &klass); where inst is (PyInstanceObject *)op; class_lookup in Modules/classobject.c eventually calls PyObject *value = PyDict_GetItem(cp->cl_dict, name); where cp is (PyClassObject *)inst->in_class and since cp is not a valid pointer, cp->cl_dict results in the segfault after a few recursive calls of class_lookup. Confirmed that this only affects 2.7. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 12:16:58 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 09 May 2012 10:16:58 +0000 Subject: [issue14591] Value returned by random.random() out of valid range on 64-bit In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1336558618.98.0.799573421289.issue14591@psf.upfronthosting.co.za> Mark Dickinson added the comment: Done. ---------- Added file: http://bugs.python.org/file25508/random_jumpahead_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 12:19:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 09 May 2012 10:19:20 +0000 Subject: [issue9751] _PyInstance_Lookup() defeats its purpose In-Reply-To: <1283506212.5.0.831864167364.issue9751@psf.upfronthosting.co.za> Message-ID: <1336558760.59.0.34560361996.issue9751@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, I don't think there's any point in trying to fixing this now. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 13:12:32 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 09 May 2012 11:12:32 +0000 Subject: [issue7980] time.strptime not thread safe In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za> Message-ID: <1336561952.78.0.917801110739.issue7980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: For the record, issue9260 proposes to fix the issues with PyImport_ImportModuleNoBlock. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 13:18:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 09 May 2012 11:18:42 +0000 Subject: [issue14762] ElementTree memory leak In-Reply-To: <1336556387.72.0.794459300498.issue14762@psf.upfronthosting.co.za> Message-ID: <1336562322.1.0.491148453821.issue14762@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +eli.bendersky, flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 13:27:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 May 2012 11:27:20 +0000 Subject: [issue14761] Memleak in import.c load_source_module() In-Reply-To: <1336553155.13.0.322701630685.issue14761@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset a775fc27f469 by Antoine Pitrou in branch '2.7': Issue #14761: Fix potential leak on an error case in the import machinery. http://hg.python.org/cpython/rev/a775fc27f469 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 13:30:25 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 May 2012 11:30:25 +0000 Subject: [issue14761] Memleak in import.c load_source_module() In-Reply-To: <1336553155.13.0.322701630685.issue14761@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 9de4d85e4197 by Antoine Pitrou in branch '3.2': Issue #14761: Fix potential leak on an error case in the import machinery. http://hg.python.org/cpython/rev/9de4d85e4197 New changeset 840cb46d0395 by Antoine Pitrou in branch 'default': Null merge for issue #14761. http://hg.python.org/cpython/rev/840cb46d0395 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 13:30:37 2012 From: report at bugs.python.org (Fj) Date: Wed, 09 May 2012 11:30:37 +0000 Subject: [issue14763] string.split maxsplit documented incorrectly Message-ID: <1336563037.57.0.851636000616.issue14763@psf.upfronthosting.co.za> New submission from Fj : string.split documentation says: > The optional third argument maxsplit defaults to 0. If it is nonzero, at most maxsplit number of splits occur, and the remainder of the string is returned as the final element of the list (thus, the list will have at most maxsplit+1 elements). It lies! If you give it maxsplit=0 it doesn't do any splits at all! It should say: > The optional third argument maxsplit defaults to **-1**. If it is **nonnegative**, at most maxsplit number of splits occur, ... Additionally, it could specify default values in the function signature explicitly, like re.split does: string.split(s, sep=None, maxsplit=-1) instead of string.split(s, [sep, [maxsplit]]) It seems that the inconsistency stems from the time long forgotten (certainly before 2.5) when string.split used the implementation in stropmodule.c (obsolete), which does indeed uses maxsplit=0 (and on which the re.split convention was based, regrettably). Currently string.split just calls str.split, and that uses maxsplit=-1 to mean unlimited splits. >From searching "maxsplit" in the bug tracker I understand that split functions have had a rather difficult history and some quirks preserved for the sake of backward compatibility, and not documented for the sake of brevity. In this case, however, the documentation does try to document the particular behaviour, but is wrong, which is really confusing. Also, maybe an even better fix would be to change the str.split documentation to use the proper signature (`str.split(sep=None, maxsplit=-1)`), and simply say that string.split(s, sep=None, maxsplit=-1) calls s.split(sep, maxsplit) here? Because that's what it does, while having _two_ different, incomplete, partially wrong explanations of the same thing is confusing! ---------- assignee: docs at python components: Documentation messages: 160273 nosy: Fj, docs at python priority: normal severity: normal status: open title: string.split maxsplit documented incorrectly versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 13:31:36 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 09 May 2012 11:31:36 +0000 Subject: [issue14761] Memleak in import.c load_source_module() In-Reply-To: <1336553155.13.0.322701630685.issue14761@psf.upfronthosting.co.za> Message-ID: <1336563096.75.0.77954095437.issue14761@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Fixed, thank you! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 13:39:01 2012 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 09 May 2012 11:39:01 +0000 Subject: [issue14762] ElementTree memory leak In-Reply-To: <1336556387.72.0.794459300498.issue14762@psf.upfronthosting.co.za> Message-ID: <1336563541.77.0.427731745213.issue14762@psf.upfronthosting.co.za> Eli Bendersky added the comment: Can you specify how you import ET? I.e. from the pure Python or the C accelerator? Also, do you realize that the element iterparse returns should be discarded with 'clear'? [see tutorial here: http://eli.thegreenplace.net/2012/03/15/processing-xml-in-python-with-elementtree/] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 13:44:31 2012 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Wed, 09 May 2012 11:44:31 +0000 Subject: [issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper In-Reply-To: <1326892577.13.0.456815776311.issue13815@psf.upfronthosting.co.za> Message-ID: <1336563871.02.0.794138940424.issue13815@psf.upfronthosting.co.za> Lars Gust?bel added the comment: In an earlier draft of my patch, I had kept ExFileObject as a subclass of BufferedReader, but I later decided against it. To use BufferedReader directly is in my opinion the cleaner solution. I admit that the change is not fully backward compatible. But a user can still write code that works for both 3.3 and the versions before. If he didn't subclass ExFileObject his code doesn't even need a change. If he subclassed ExFileObject, he might have a problem in either case: either the ExFileObject class is missing, or he may be unable to use it the way he did before, because all that's left of it is a stub subclass of BufferedReader. I am well aware that backward compatibility is most important, but I think it must still be allowed to change internal (and undocumented) APIs every now and then to clean things up a little. And of course, I did a code search before too, and found no code using ExFileObject. This actually doesn't surprise me, as there is really not much you can do with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 13:53:46 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 May 2012 11:53:46 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336428561.46.0.842580483885.issue14744@psf.upfronthosting.co.za> Message-ID: <1336564426.05.0.314084437427.issue14744@psf.upfronthosting.co.za> STINNER Victor added the comment: > Inlining may be removed to simplify the code Attached inline_unicode_writer.patch does inline the code but also call only unicode_writer_prepare() once for each argument in PyUnicode_Format(). The patch removes unicode_writer_write_char() and unicode_writer_write_str() which had an overhead for the following patches (format_writer.patch, format_writer-2.patch). > As you can see, there is a regress, and sometimes > it is not less than improvement. Oh yes, thanks for your benchmark. I will analyze why my patch slows down these cases and try to update my patch to be applicable after inline_unicode_writer.patch. I suppose that the _PyUnicodeWriter API has a little overhead which is seen by microbenchmarks. ---------- Added file: http://bugs.python.org/file25509/inline_unicode_writer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 13:59:34 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 May 2012 11:59:34 +0000 Subject: [issue14763] string.split maxsplit documented incorrectly In-Reply-To: <1336563037.57.0.851636000616.issue14763@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset d3ddbad31b3e by Ezio Melotti in branch '2.7': #14763: fix documentation for string.split/rsplit. http://hg.python.org/cpython/rev/d3ddbad31b3e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 14:03:27 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 09 May 2012 12:03:27 +0000 Subject: [issue14763] string.split maxsplit documented incorrectly In-Reply-To: <1336563037.57.0.851636000616.issue14763@psf.upfronthosting.co.za> Message-ID: <1336565007.58.0.26475678381.issue14763@psf.upfronthosting.co.za> Ezio Melotti added the comment: I fixed the doc for string.split/rsplit. I didn't change the signature because all the other functions use the old signature convention (the one with []). These functions are anyway deprecated, so I don't think it's worth spending more time improving their docs (as long as they are not wrong). ---------- assignee: docs at python -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 14:07:06 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 09 May 2012 12:07:06 +0000 Subject: [issue14759] Is LICENSES.txt up to date? In-Reply-To: <1336525700.66.0.626657341837.issue14759@psf.upfronthosting.co.za> Message-ID: <1336565226.72.0.817852639425.issue14759@psf.upfronthosting.co.za> R. David Murray added the comment: The LICENSE.txt file is "just" the Python license, which has a rather convoluted history. Newer contributions are all under an Apache-style license from the individual contributors. My understanding (but I'm not a lawyer) is that everything in the distribution has been vetted as available for use under the LISCENSE.txt, which includes commercial use. If you believe that the language either in that file or on the web site does not convey that legally, then psf at python.org is who you need to contact. On the development side, the most we can do is update a license if someone figures out that it is appropriate to do so. For the website text, there's a mailing list listed on the mail.python.org page. There's a project ongoing to make updating the web site easier, but currently there aren't very many developers who do web site updates, and such updates are not tracked on this tracker, just on that mailing list. (Yes, this is not ideal, but it is where we are at right now.) I've added one of those devs as nosy, perhaps he will have additional comments. ---------- nosy: +michael.foord title: Berkeley DB License conditions are onerous (and poorly documented) -> Is LICENSES.txt up to date? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 14:09:53 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 09 May 2012 12:09:53 +0000 Subject: [issue14764] importlib.test.benchmark broken Message-ID: <1336565393.03.0.0926288176672.issue14764@psf.upfronthosting.co.za> New submission from Antoine Pitrou : It seems the benchmark script didn't survive the migration: $ ./python -m importlib.test.benchmark Measuring imports/second over 1 second, best out of 3 Entire benchmark run should take about 33 seconds Using as __import__ sys.modules [ 289195 288128 288050 ] best is 289,195 Built-in module [ 48351 48101 48432 ] best is 48,432 Source writing bytecode: small [ Traceback (most recent call last): File "/home/antoine/cpython/opt/Lib/importlib/test/benchmark.py", line 30, in bench total_time += timer.timeit(1) File "/home/antoine/cpython/opt/Lib/timeit.py", line 190, in timeit timing = self.inner(it, self.timer) File "", line 6, in inner File "/home/antoine/cpython/opt/Lib/importlib/_bootstrap.py", line 1077, in __import__ module = _gcd_import(name) File "/home/antoine/cpython/opt/Lib/importlib/_bootstrap.py", line 1024, in _gcd_import return _find_and_load(name, _gcd_import) File "/home/antoine/cpython/opt/Lib/importlib/_bootstrap.py", line 974, in _find_and_load raise ImportError(_ERR_MSG.format(name), name=name) ImportError: No module named '__importlib_test_benchmark__' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/antoine/cpython/opt/Lib/runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/home/antoine/cpython/opt/Lib/runpy.py", line 75, in _run_code exec(code, run_globals) File "/home/antoine/cpython/opt/Lib/importlib/test/benchmark.py", line 239, in main(import_, options) File "/home/antoine/cpython/opt/Lib/importlib/test/benchmark.py", line 197, in main for result in benchmark(seconds=seconds, repeat=repeat): File "/home/antoine/cpython/opt/Lib/importlib/test/benchmark.py", line 108, in source_writing_bytecode for result in bench(name, cleanup, repeat=repeat, seconds=seconds): File "/home/antoine/cpython/opt/Lib/importlib/test/benchmark.py", line 32, in bench cleanup() File "/home/antoine/cpython/opt/Lib/importlib/test/benchmark.py", line 106, in cleanup sys.modules.pop(name) KeyError: '__importlib_test_benchmark__' ---------- components: Library (Lib) messages: 160281 nosy: brett.cannon, pitrou priority: low severity: normal status: open title: importlib.test.benchmark broken versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 14:14:10 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 09 May 2012 12:14:10 +0000 Subject: [issue14759] Is LICENSES.txt up to date? In-Reply-To: <1336525700.66.0.626657341837.issue14759@psf.upfronthosting.co.za> Message-ID: <1336565650.97.0.271891719348.issue14759@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I am the maintainer of Berkeley DB python bindings, "pybsddb": http://www.jcea.es/programacion/pybsddb.htm If I recall correctly, Berkeley DB license is something like this: 1. Your code must be open source, if you distribute the programs to others. You can write a program for your business, for instance, and don't care about licensing, if it used internally only. OR 2. You have to pay a license to Oracle. Choose one. I could be mistaken... ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 14:16:06 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 09 May 2012 12:16:06 +0000 Subject: [issue14759] Is LICENSES.txt up to date? In-Reply-To: <1336525700.66.0.626657341837.issue14759@psf.upfronthosting.co.za> Message-ID: <1336565766.22.0.125574432334.issue14759@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Could be useful if you directly talk to Oracle about this and communicate what you learned. It could even influence pybsddb licensing/documentation :). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 14:18:53 2012 From: report at bugs.python.org (Fj) Date: Wed, 09 May 2012 12:18:53 +0000 Subject: [issue14763] string.split maxsplit documented incorrectly In-Reply-To: <1336563037.57.0.851636000616.issue14763@psf.upfronthosting.co.za> Message-ID: <1336565933.46.0.553379980584.issue14763@psf.upfronthosting.co.za> Fj added the comment: Thank you. > These functions are anyway deprecated Well, yes, but it's the only place you can get information about the default value of maxsplit, short of looking in the source. Which is kind of wrong. Maybe you can also fix str.split docstring to say "If maxsplit is not specified *or negative*, then there is no limit on the number of splits"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 14:21:05 2012 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 09 May 2012 12:21:05 +0000 Subject: [issue14758] SMTPServer of smptd does not support binding to an IPv6 address In-Reply-To: <1336511750.16.0.237606043889.issue14758@psf.upfronthosting.co.za> Message-ID: <1336566065.53.0.138335884644.issue14758@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Unfortunately unit tests overwrite the original smtpd.socket module object with test.mock_socket [1] and the latter one doesn't expose socket.getaddrinfo(). [1] http://hg.python.org/cpython/file/d937b527b76e/Lib/test/test_smtpd.py#l54 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 14:47:18 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 09 May 2012 12:47:18 +0000 Subject: [issue14762] ElementTree memory leak In-Reply-To: <1336556387.72.0.794459300498.issue14762@psf.upfronthosting.co.za> Message-ID: <1336567638.89.0.32748406907.issue14762@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Can this be reproduced in 3.2/3.3? ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 15:12:02 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 09 May 2012 13:12:02 +0000 Subject: [issue14758] SMTPServer of smptd does not support binding to an IPv6 address In-Reply-To: <1336511750.16.0.237606043889.issue14758@psf.upfronthosting.co.za> Message-ID: <1336569122.86.0.512846384143.issue14758@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 15:33:36 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 09 May 2012 13:33:36 +0000 Subject: [issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper In-Reply-To: <1326892577.13.0.456815776311.issue13815@psf.upfronthosting.co.za> Message-ID: <1336570416.31.0.410198838399.issue13815@psf.upfronthosting.co.za> R. David Murray added the comment: Yeah, I know it is technically private. We still tend to keep names around unless there's a good reason to delete them (like using them leads to broken code anyway). The code search is some evidence this deletion would be OK, but why *not* follow Amaury's suggestion? I'm OK if you reclose this, but I unfortunately I don't think simple cleanliness is a good argument (even though I would like it to be). The other arguments are better :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 15:35:30 2012 From: report at bugs.python.org (Giuseppe Attardi) Date: Wed, 09 May 2012 13:35:30 +0000 Subject: [issue14762] ElementTree memory leak In-Reply-To: <1336556387.72.0.794459300498.issue14762@psf.upfronthosting.co.za> Message-ID: <1336570530.47.0.627652146045.issue14762@psf.upfronthosting.co.za> Giuseppe Attardi added the comment: You are right, I should discard the elements. Thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 15:36:30 2012 From: report at bugs.python.org (Giuseppe Attardi) Date: Wed, 09 May 2012 13:36:30 +0000 Subject: [issue14762] ElementTree memory leak In-Reply-To: <1336556387.72.0.794459300498.issue14762@psf.upfronthosting.co.za> Message-ID: <1336570590.25.0.518276622727.issue14762@psf.upfronthosting.co.za> Changes by Giuseppe Attardi : ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 15:41:47 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 09 May 2012 13:41:47 +0000 Subject: [issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper In-Reply-To: <1336570416.31.0.410198838399.issue13815@psf.upfronthosting.co.za> Message-ID: <1336570782.3352.3.camel@localhost.localdomain> Antoine Pitrou added the comment: > Yeah, I know it is technically private. We still tend to keep names > around unless there's a good reason to delete them (like using them > leads to broken code anyway). The code search is some evidence this > deletion would be OK, but why *not* follow Amaury's suggestion? I don't see the point of maintaining a private API that's proven to be unused :) It's an unwarranted maintenance burden (though admittedly a light one here). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 15:44:20 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 09 May 2012 13:44:20 +0000 Subject: [issue14758] SMTPServer of smptd does not support binding to an IPv6 address In-Reply-To: <1336511750.16.0.237606043889.issue14758@psf.upfronthosting.co.za> Message-ID: <1336571060.01.0.435173256763.issue14758@psf.upfronthosting.co.za> R. David Murray added the comment: Well, that should be fixed anyway (a cleanup added that restores the original value). Then a new TestCase can test the socket stuff. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 15:51:52 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Wed, 09 May 2012 13:51:52 +0000 Subject: [issue14765] the struct example should give consistent results across different hardware platforms Message-ID: <1336571512.12.0.453082723156.issue14765@psf.upfronthosting.co.za> New submission from Tshepang Lekhonkhobe : This example [1] assumes you are using a specific platform to check it out. I am using amd64, and I get different results. To fix, I prefix the format string with '>': before: pack('hhl', 1, 2, 3) after: pack('>hhl', 1, 2, 3) 1: http://hg.python.org/cpython/file/d3ddbad31b3e/Doc/library/struct.rst#l299 ---------- assignee: docs at python components: Documentation messages: 160291 nosy: docs at python, mark.dickinson, meador.inge, tshepang priority: normal severity: normal status: open title: the struct example should give consistent results across different hardware platforms type: enhancement versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 16:07:15 2012 From: report at bugs.python.org (Meador Inge) Date: Wed, 09 May 2012 14:07:15 +0000 Subject: [issue14765] the struct example should give consistent results across different hardware platforms In-Reply-To: <1336571512.12.0.453082723156.issue14765@psf.upfronthosting.co.za> Message-ID: <1336572435.21.0.782296752859.issue14765@psf.upfronthosting.co.za> Meador Inge added the comment: And the examples make an explicit note of that: """ .. note:: All examples assume a native byte order, size, and alignment with a big-endian machine. """ AMD64 is little-endian; the examples are noted to be in big-endian. Is that note not sufficient? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 16:11:21 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Wed, 09 May 2012 14:11:21 +0000 Subject: [issue14765] the struct example should give consistent results across different hardware platforms In-Reply-To: <1336572435.21.0.782296752859.issue14765@psf.upfronthosting.co.za> Message-ID: <1336572833.25343.1.camel@tshepang> Tshepang Lekhonkhobe added the comment: Sadly, I noticed it only after submitting this report. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 16:15:14 2012 From: report at bugs.python.org (Meador Inge) Date: Wed, 09 May 2012 14:15:14 +0000 Subject: [issue14765] the struct example should give consistent results across different hardware platforms In-Reply-To: <1336571512.12.0.453082723156.issue14765@psf.upfronthosting.co.za> Message-ID: <1336572914.33.0.749802194803.issue14765@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 16:18:18 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 09 May 2012 14:18:18 +0000 Subject: [issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper In-Reply-To: <1326892577.13.0.456815776311.issue13815@psf.upfronthosting.co.za> Message-ID: <1336573098.3.0.21253108128.issue13815@psf.upfronthosting.co.za> R. David Murray added the comment: Code search is not proof, I'm afraid. It is evidence, though, and I thought I indicated I thought it was a good argument in favor of dropping the class. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 16:18:45 2012 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 09 May 2012 14:18:45 +0000 Subject: [issue14760] logging: make setLevel() return handler itself for chained configuration In-Reply-To: <1336547719.78.0.572014137028.issue14760@psf.upfronthosting.co.za> Message-ID: <1336573125.43.0.735566729538.issue14760@psf.upfronthosting.co.za> Vinay Sajip added the comment: I agree with Georg. Besides, as far as possible, the API should be consistent across versions of Python, unless something is needed to take advantage of added features. With your proposal, users could write library code which then would not work in older Python versions - and that's not something we want to encourage. ---------- assignee: -> vinay.sajip nosy: +vinay.sajip resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 16:22:29 2012 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 09 May 2012 14:22:29 +0000 Subject: [issue14712] Integrate PEP 405 In-Reply-To: <1336059271.86.0.0525487031192.issue14712@psf.upfronthosting.co.za> Message-ID: <1336573349.33.0.487920242587.issue14712@psf.upfronthosting.co.za> Changes by Vinay Sajip : Added file: http://bugs.python.org/file25510/51b73e1c1e94.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 16:24:23 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 09 May 2012 14:24:23 +0000 Subject: [issue14764] importlib.test.benchmark broken In-Reply-To: <1336565393.03.0.0926288176672.issue14764@psf.upfronthosting.co.za> Message-ID: <1336573463.55.0.994152179257.issue14764@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 16:40:07 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 09 May 2012 14:40:07 +0000 Subject: [issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper In-Reply-To: <1336573098.3.0.21253108128.issue13815@psf.upfronthosting.co.za> Message-ID: <1336574284.3352.4.camel@localhost.localdomain> Antoine Pitrou added the comment: > Code search is not proof, I'm afraid. It is evidence, though, and I > thought I indicated I thought it was a good argument in favor of > dropping the class. Yes, sorry for the vocabulary mismatch :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 16:55:36 2012 From: report at bugs.python.org (Stephen White) Date: Wed, 09 May 2012 14:55:36 +0000 Subject: [issue14308] '_DummyThread' object has no attribute '_Thread__block' In-Reply-To: <1331768900.76.0.717773710833.issue14308@psf.upfronthosting.co.za> Message-ID: <1336575336.51.0.755273498989.issue14308@psf.upfronthosting.co.za> Stephen White added the comment: Glad this is fixed. Attached is a Python 2.7 file that demonstrates the problem in a pretty minimal way in case it is of any use to anyone. ---------- nosy: +Stephen.White Added file: http://bugs.python.org/file25511/bad-thread.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 17:03:48 2012 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 09 May 2012 15:03:48 +0000 Subject: [issue14712] Integrate PEP 405 In-Reply-To: <1336059271.86.0.0525487031192.issue14712@psf.upfronthosting.co.za> Message-ID: <1336575828.72.0.753518233667.issue14712@psf.upfronthosting.co.za> Changes by Vinay Sajip : Removed file: http://bugs.python.org/file25444/old-patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 17:34:51 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 09 May 2012 15:34:51 +0000 Subject: [issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper In-Reply-To: <1326892577.13.0.456815776311.issue13815@psf.upfronthosting.co.za> Message-ID: <1336577691.62.0.678166563282.issue13815@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I came here when I saw this comment in the diff: "# Keep the traditional pre-3.3 API intact". Why keep an internal API intact if we do it partially? The ExFileObject class above will also simplify the code: simply "return self.fileobject(self, tarinfo)" in all cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 17:38:48 2012 From: report at bugs.python.org (Maxim Doucet) Date: Wed, 09 May 2012 15:38:48 +0000 Subject: [issue8617] Better document user site-packages in site module doc In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za> Message-ID: <1336577928.24.0.96951593026.issue8617@psf.upfronthosting.co.za> Maxim Doucet added the comment: Shouldn't there be an update of the 2.6 documentation too? After your patch, the 2.7 reflects the existence of the "--user" option (see http://docs.python.org/release/2.7.3/install/index.html#alternate-installation-the-user-scheme) but not the 2.6 documentation (http://docs.python.org/release/2.6.8/install/index.html#alternate-installation). In my personal experience, I used the "--home" option with python 2.6 to mimic what "--user" does and it took me 2 weeks to, by chance, stumble upon http://www.python.org/dev/peps/pep-0370/ which informed me that the "--user" option was originally available for python 2.6. If it had been on the 2.6 documentation, it would have been easier and more coherent IMHO. ---------- nosy: +maximd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 17:40:17 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 09 May 2012 15:40:17 +0000 Subject: [issue8617] Better document user site-packages in site module doc In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za> Message-ID: <1336578017.53.0.583504028009.issue8617@psf.upfronthosting.co.za> ?ric Araujo added the comment: 2.6 only gets security fixes now. ---------- _______________________________________ Python tracker _______________________________________ From senthil at uthcode.com Wed May 9 17:43:56 2012 From: senthil at uthcode.com (Senthil Kumaran) Date: Wed, 9 May 2012 23:43:56 +0800 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step Message-ID: <20120509154356.GA5510@mathmagic> > Georg Brandl added the comment: > > Should be fixed now. Thanks for the commit fix, Georg. The comment on buildbot failures had escaped my attention. Sorry for that. From report at bugs.python.org Wed May 9 17:44:05 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 09 May 2012 15:44:05 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: <20120509154356.GA5510@mathmagic> Senthil Kumaran added the comment: > Georg Brandl added the comment: > > Should be fixed now. Thanks for the commit fix, Georg. The comment on buildbot failures had escaped my attention. Sorry for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 17:44:05 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 09 May 2012 15:44:05 +0000 Subject: [issue8617] Better document user site-packages in site module doc In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za> Message-ID: <1336578245.96.0.454695455145.issue8617@psf.upfronthosting.co.za> ?ric Araujo added the comment: BTW it appears that many people use the most recent 2.7 documentation even if they are using 2.6, because the doc is better and there are notes which tell you if something was changed or added in 2.7. For PEP 370 there are notes in the doc of the site module and the environment variables but I forgot to add one to the distutils doc; I will do that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 17:45:50 2012 From: report at bugs.python.org (Maxim Doucet) Date: Wed, 09 May 2012 15:45:50 +0000 Subject: [issue8617] Better document user site-packages in site module doc In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za> Message-ID: <1336578350.75.0.666516792248.issue8617@psf.upfronthosting.co.za> Maxim Doucet added the comment: Fair enough, thank you for the information. As a side note, my original question was in fact more suited for issue10745 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 18:30:23 2012 From: report at bugs.python.org (Pierre Quentel) Date: Wed, 09 May 2012 16:30:23 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1336581023.48.0.134673587487.issue11352@psf.upfronthosting.co.za> Pierre Quentel added the comment: Hi, I started working on a revised version of the whole cgi documentation. I mostly changed paragraphs 2 & 3 ("Using the CGI module" and "Higher level interface") and replaced them by a paragraph still called "Using the CGI module" + 2 other paragraphs for special cases : "Multiple fields with the same name" and "File uploads" The content is basically the same but the new presentation is hopefully more clear The patch is attached as file cgi-doc.patch ---------- Added file: http://bugs.python.org/file25512/cgi-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 18:50:51 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 09 May 2012 16:50:51 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding In-Reply-To: <1336327254.8.0.865225437508.issue14738@psf.upfronthosting.co.za> Message-ID: <1336582251.36.0.885334897159.issue14738@psf.upfronthosting.co.za> Antoine Pitrou added the comment: There's a Mac-specific portion in the patch, it would be nice if someone could check that it works. ---------- nosy: +ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 20:05:09 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 May 2012 18:05:09 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding In-Reply-To: <1336327254.8.0.865225437508.issue14738@psf.upfronthosting.co.za> Message-ID: <1336586709.2.0.336361520586.issue14738@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It would be good if someone checked on Macs work with command line arguments, including non-valid utf8. The difficulty is that you need to check on both Macs with 16-bit and with 32-bit wchar_t. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 20:32:10 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 May 2012 18:32:10 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding In-Reply-To: <1336327254.8.0.865225437508.issue14738@psf.upfronthosting.co.za> Message-ID: <1336588330.1.0.819455283467.issue14738@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Issue4388 is related to this Mac-specific portion of the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 20:41:16 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 09 May 2012 18:41:16 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding In-Reply-To: <1336586709.2.0.336361520586.issue14738@psf.upfronthosting.co.za> Message-ID: <1336588751.3382.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > It would be good if someone checked on Macs work with command line > arguments, including non-valid utf8. The difficulty is that you need > to check on both Macs with 16-bit and with 32-bit wchar_t. Actually, it should be enough to run the test suite, since we should have tests for this. As for different wchar_t widths, that's the kind of thing we can leave to the buildbots (assuming our OS X buildbots come back alive some day :-)). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 20:41:36 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 09 May 2012 18:41:36 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding In-Reply-To: <1336327254.8.0.865225437508.issue14738@psf.upfronthosting.co.za> Message-ID: <1336588896.04.0.390824921671.issue14738@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +janssen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 21:29:54 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 May 2012 19:29:54 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding In-Reply-To: <1336588751.3382.0.camel@localhost.localdomain> Message-ID: <1336591948.2591.32.camel@raxxla> Serhiy Storchaka added the comment: I hacked the code (commented out "#if __APPLE__" in Objects/unicodeobject.c and Modules/python.c) to start this branch on Linux and ran the test (test_cmd_line) with C locale. It passed. Then I broke decoder and ran the test again to get the error. I can now confirm that the code works correctly on a platform with a 32-bit wchar_t. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 21:31:10 2012 From: report at bugs.python.org (Armin Rigo) Date: Wed, 09 May 2012 19:31:10 +0000 Subject: [issue9751] _PyInstance_Lookup() defeats its purpose In-Reply-To: <1283506212.5.0.831864167364.issue9751@psf.upfronthosting.co.za> Message-ID: <1336591870.06.0.293288245683.issue9751@psf.upfronthosting.co.za> Armin Rigo added the comment: Unlike other crashers I'm a bit concerned about this one. It can occur on any code that stores custom instances as keys in the __dict__ of an old-style instance. Such code might be unusual-looking, but certainly not unheard-of. And the segfault that we get then is very rare and impossible to reproduce in practice because it depends on when exactly the GC is running and on the low bits of hashes colliding. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 22:13:57 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 09 May 2012 20:13:57 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding In-Reply-To: <1336327254.8.0.865225437508.issue14738@psf.upfronthosting.co.za> Message-ID: <1336594437.82.0.122626705057.issue14738@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Actually, it should be enough to run the test suite, since we should > have tests for this. I just ran the test suite ("python -m test") on OS X 10.6.8 with 'decode_utf8_5.patch' applied. (64-bit --with-pydebug build of Python.) No test failures. test header: == CPython 3.3.0a3+ (default:840cb46d0395+, May 9 2012, 20:55:18) [GCC 4.2.1 (Apple Inc. build 5664)] == Darwin-10.8.0-i386-64bit little-endian == /Users/mdickinson/Python/cpython/build/test_python_39794 Fragment of configure output relevant to wchar looked like this: checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking size of wchar_t... 4 checking for UCS-4 tcl... no checking whether wchar_t is signed... yes no usable wchar_t found ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 22:18:21 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 May 2012 20:18:21 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding In-Reply-To: <1336327254.8.0.865225437508.issue14738@psf.upfronthosting.co.za> Message-ID: <1336594701.84.0.413166347713.issue14738@psf.upfronthosting.co.za> STINNER Victor added the comment: > The difficulty is that you need to check on both Macs > with 16-bit and with 32-bit wchar_t. I don't think that the size of wchar_t is configurable: it should always be 32 bits on Mac OS X. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 9 22:32:53 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 May 2012 20:32:53 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336428561.46.0.842580483885.issue14744@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 6c8a117f8966 by Victor Stinner in branch 'default': Issue #14744: Inline unicode_writer_write_char() and unicode_write_str() http://hg.python.org/cpython/rev/6c8a117f8966 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 00:11:10 2012 From: report at bugs.python.org (Chris Bergstresser) Date: Wed, 09 May 2012 22:11:10 +0000 Subject: [issue14766] Non-naive time comparison throws naive time error Message-ID: <1336601470.15.0.633873123281.issue14766@psf.upfronthosting.co.za> New submission from Chris Bergstresser : The datetime module says: An object d of type time or datetime may be naive or aware. d is aware if d.tzinfo is not None and d.tzinfo.utcoffset(d) does not return None. If d.tzinfo is None, or if d.tzinfo is not None but d.tzinfo.utcoffset(d) returns None, d is naive. However, I can create two non-naive timezones (under this definition) which throw an exception when they're compared, because one is being considered offset-naive: >>> import pytz, datetime >>> UTC_TZ = pytz.utc >>> EASTERN_TZ = pytz.timezone('America/New_York') >>> d1 = datetime.time(10, tzinfo = UTC_TZ) >>> d1 datetime.time(10, 0, tzinfo=) >>> d1.tzinfo >>> d1.utcoffset(d1) datetime.timedelta(0) >>> d2 = datetime.time(10, tzinfo = EASTERN_TZ) >>> d2 datetime.time(10, 0, tzinfo=) >>> d2.tzinfo >>> d2.tzinfo.utcoffset(d2) datetime.timedelta(-1, 68400) >>> d1 < d2 Traceback (most recent call last): File "", line 1, in TypeError: can't compare offset-naive and offset-aware times ---------- messages: 160314 nosy: Chris.Bergstresser priority: normal severity: normal status: open title: Non-naive time comparison throws naive time error type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 00:56:33 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 09 May 2012 22:56:33 +0000 Subject: [issue14766] Non-naive time comparison throws naive time error In-Reply-To: <1336601470.15.0.633873123281.issue14766@psf.upfronthosting.co.za> Message-ID: <1336604193.53.0.509760582493.issue14766@psf.upfronthosting.co.za> R. David Murray added the comment: An equivalent test using python 3.2's datetime.timezone works fine. Are you sure it isn't a bug in pytz? ---------- nosy: +belopolsky, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 01:44:33 2012 From: report at bugs.python.org (Chris Bergstresser) Date: Wed, 09 May 2012 23:44:33 +0000 Subject: [issue14766] Non-naive time comparison throws naive time error In-Reply-To: <1336601470.15.0.633873123281.issue14766@psf.upfronthosting.co.za> Message-ID: <1336607073.97.0.662303766617.issue14766@psf.upfronthosting.co.za> Chris Bergstresser added the comment: It doesn't seem to be a bug in pytz. AFAICT, the only methods that get called during the time comparison is "utcoffset" on the UTC timezone, and "utcoffset" on the New York timezone. Looking closer at it, it seems that Python is calling d1.tzinfo.utcoffset(None), rather than d1.tzinfo.utcoffset(d1). This is a problem, because the New York timezone cannot calculate the utcoffset without knowing what date it's calculating. As a result, it returns None rather than potentially guessing wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 02:07:56 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 May 2012 00:07:56 +0000 Subject: [issue14766] Non-naive time comparison throws naive time error In-Reply-To: <1336601470.15.0.633873123281.issue14766@psf.upfronthosting.co.za> Message-ID: <1336608476.98.0.206971712607.issue14766@psf.upfronthosting.co.za> R. David Murray added the comment: Ah. datetime.timezone wouldn't have that issue since it doesn't deal with DST. The 3.3 python version of datetime calls utcoffset in the same way as you describe, and it is supposed to have the same behavior as the C version, so probably 3.2/3.3 has the bug as well. (It does look like a bug to me.) Note that 2.6 is in security fix only mode, so this can only get corrected in 2.7 and 3.2/3.3. I'm surprised this hasn't been reported before. ---------- keywords: +easy stage: -> needs patch versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 02:29:07 2012 From: report at bugs.python.org (Jeff Laing) Date: Thu, 10 May 2012 00:29:07 +0000 Subject: [issue14759] Is LICENSES.txt up to date? In-Reply-To: <1336525700.66.0.626657341837.issue14759@psf.upfronthosting.co.za> Message-ID: <1336609747.18.0.128691955039.issue14759@psf.upfronthosting.co.za> Jeff Laing added the comment: @Jes?s, as has been pointed out already, the Berkeley DB stuff is not part of Python 3 so I don't see any point in discussing this with Oracle. We don't actually use or need the bsddb module, it's just part of the standard runtime library that we ship. We will be removing the bsddb module from our distribution of the runtime library, while our app is embedding the 2.7 interpreter. Once we go to 3.0, the problem becomes moot. When discussing issues related to licensing, a visible audit trail is essential to show that one followed a genuine process in a timely fashion. When the lawyers come howling to our door, I want to be able to point at archived documentation that showed we were not knowingly continuing to violate a license condition once we became aware of it. With respect to mail.python.org mailing lists, the http://docs.python.org/bugs.html page explicitly says "if you want a more persistent record of your issue, you can use the issue tracker for documentation bugs as well". That suggested to me that there were more than just "developers" listening here. I feel like it's getting a bit meta if I raise an issue here requesting that the website be clarified to note that the documentors don't really look at issues here. :-) Thanks to all, my immediate problem is resolved, and I now know that I need to dig a lot deeper into all the documentation each time we upgrade, rather than assume that it's all consistent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 03:28:08 2012 From: report at bugs.python.org (jspenguin) Date: Thu, 10 May 2012 01:28:08 +0000 Subject: [issue14767] urllib.request.HTTPRedirectHandler raises HTTPError when Location header is relative Message-ID: <1336613288.44.0.609842734336.issue14767@psf.upfronthosting.co.za> New submission from jspenguin : If a server returns a relative URL in the 'Location:' header, HTTPRedirectHandler will fail because it checks the scheme of the URL before it calls urljoin() to convert it to an absolute URL. ---------- components: Library (Lib) files: rel_redirect.py messages: 160319 nosy: jspenguin priority: normal severity: normal status: open title: urllib.request.HTTPRedirectHandler raises HTTPError when Location header is relative type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file25513/rel_redirect.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 03:39:07 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 May 2012 01:39:07 +0000 Subject: [issue14759] BSDDB license missing from liscense page in 2.7. In-Reply-To: <1336525700.66.0.626657341837.issue14759@psf.upfronthosting.co.za> Message-ID: <1336613947.59.0.86008302784.issue14759@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, I see. No, the docs are correct, I'm the one who was mistaken. I thought the license page was on www.python.org, rather than docs.python.org. Developers *do* have full and easy access to docs.python.org, and we do track doc bugs here. As with the rest of our documentation, the license documentation page is "more complete" than the source version. (It's actually not in theory, it's just that it is collected all in one place...but the docs are shipped in the release tarballs, so the info is included in the distribution regardless). The license docs, unlike most of the rest of the docs, don't have 'version added' and 'deprecated' tags, so you have to refer to license page that relates to the specific version of python you are looking at. However, it is not clear to me (given your BSDDB example) that this is in fact the case. So I'm re-opening the issue hoping someone will be willing to do an audit. But as you say, for due diligence you do have to look at the source as well as the docs, even if we fix this. ---------- stage: committed/rejected -> needs patch status: closed -> open title: Is LICENSES.txt up to date? -> BSDDB license missing from liscense page in 2.7. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 04:25:19 2012 From: report at bugs.python.org (Bradley Froehle) Date: Thu, 10 May 2012 02:25:19 +0000 Subject: [issue14768] os.path.expanduser('~/a') doesn't works correctly when HOME is '/' Message-ID: <1336616719.53.0.0181039084053.issue14768@psf.upfronthosting.co.za> New submission from Bradley Froehle : When $HOME=/, os.path.expanduser('~/a') returns '//a' rather than '/a'. This regression was created by a partially incorrect resolution to issue #5471, and affects versions 2.7 and 3.2 (at least). $ HOME=/ python2.7 -c "import os; print os.path.expanduser('~/a')" //a $ HOME=/ python3.2 -c "import os; print(os.path.expanduser('~/a'))" //a In each case the expected result should be '/a'. ---------- components: Library (Lib) messages: 160321 nosy: bfroehle priority: normal severity: normal status: open title: os.path.expanduser('~/a') doesn't works correctly when HOME is '/' versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 04:33:12 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 10 May 2012 02:33:12 +0000 Subject: [issue14759] BSDDB license missing from liscense page in 2.7. In-Reply-To: <1336525700.66.0.626657341837.issue14759@psf.upfronthosting.co.za> Message-ID: <1336617192.24.0.699126918071.issue14759@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: If your program is not using Berkeley DB in any way, you don't need to worry about its license. The situation is similar to Berkeley DB being included in you linux distribution: if you don't use it, you don't have to worry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 04:46:36 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 10 May 2012 02:46:36 +0000 Subject: [issue5471] os.path.expanduser('~') doesnt works correctly when HOME is '/' In-Reply-To: <1236712575.55.0.379860744016.issue5471@psf.upfronthosting.co.za> Message-ID: <1336617996.16.0.149211330288.issue5471@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: See issue #14768. ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 04:48:31 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 10 May 2012 02:48:31 +0000 Subject: [issue14768] os.path.expanduser('~/a') doesn't works correctly when HOME is '/' In-Reply-To: <1336616719.53.0.0181039084053.issue14768@psf.upfronthosting.co.za> Message-ID: <1336618111.75.0.644052096655.issue14768@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I though that this situation would be happen for ANY env with $HOME ending in "/", but it is not the case: """ jcea at ubuntu:~$ echo $HOME /home/jcea jcea at ubuntu:~$ python Python 2.7.3 (default, Apr 12 2012, 13:11:53) [GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.path.expanduser("~/a") '/home/jcea/a' jcea at ubuntu:/home/jcea$ export HOME=/home/jcea/ jcea at ubuntu:/home/jcea$ echo $HOME /home/jcea/ jcea at ubuntu:/home/jcea$ python Python 2.7.3 (default, Apr 12 2012, 13:11:53) [GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.path.expanduser("~/a") '/home/jcea/a' """ Bradley, would you mind to write a patch & test? ---------- nosy: +jcea versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 04:48:44 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 10 May 2012 02:48:44 +0000 Subject: [issue14768] os.path.expanduser('~/a') doesn't works correctly when HOME is '/' In-Reply-To: <1336616719.53.0.0181039084053.issue14768@psf.upfronthosting.co.za> Message-ID: <1336618124.5.0.773433146564.issue14768@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 04:50:34 2012 From: report at bugs.python.org (Bradley Froehle) Date: Thu, 10 May 2012 02:50:34 +0000 Subject: [issue14768] os.path.expanduser('~/a') doesn't works correctly when HOME is '/' In-Reply-To: <1336616719.53.0.0181039084053.issue14768@psf.upfronthosting.co.za> Message-ID: <1336618234.91.0.801409023036.issue14768@psf.upfronthosting.co.za> Bradley Froehle added the comment: Patch (for version 2.7) attached. ---------- keywords: +patch Added file: http://bugs.python.org/file25514/issue_14768.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 05:00:36 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 10 May 2012 03:00:36 +0000 Subject: [issue14768] os.path.expanduser('~/a') doesn't works correctly when HOME is '/' In-Reply-To: <1336616719.53.0.0181039084053.issue14768@psf.upfronthosting.co.za> Message-ID: <1336618836.19.0.881554983761.issue14768@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- assignee: -> jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 05:01:39 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 10 May 2012 03:01:39 +0000 Subject: [issue14767] urllib.request.HTTPRedirectHandler raises HTTPError when Location header is relative In-Reply-To: <1336613288.44.0.609842734336.issue14767@psf.upfronthosting.co.za> Message-ID: <1336618899.37.0.0417886536311.issue14767@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- assignee: -> orsenthil nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 05:08:47 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 10 May 2012 03:08:47 +0000 Subject: [issue14651] pysetup run cmd can't handle option values in the setup.cfg In-Reply-To: <1335197984.07.0.198109730361.issue14651@psf.upfronthosting.co.za> Message-ID: <1336619327.18.0.121980242414.issue14651@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- dependencies: +Custom commands don't work _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 05:16:59 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 May 2012 03:16:59 +0000 Subject: [issue14768] os.path.expanduser('~/a') doesn't works correctly when HOME is '/' In-Reply-To: <1336616719.53.0.0181039084053.issue14768@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e472481b6d73 by Jesus Cea in branch '3.2': Closes #14768: os.path.expanduser('~/a') doesn't works correctly when HOME is '/' http://hg.python.org/cpython/rev/e472481b6d73 New changeset 299dc54ad014 by Jesus Cea in branch '2.7': Closes #14768: os.path.expanduser('~/a') doesn't works correctly when HOME is '/' http://hg.python.org/cpython/rev/299dc54ad014 New changeset ce39a4ec2906 by Jesus Cea in branch 'default': MERGE: Closes #14768: os.path.expanduser('~/a') doesn't works correctly when HOME is '/' http://hg.python.org/cpython/rev/ce39a4ec2906 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 09:07:57 2012 From: report at bugs.python.org (Chris Rebert) Date: Thu, 10 May 2012 07:07:57 +0000 Subject: [issue14187] add "annotation" entry to Glossary In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za> Message-ID: <1336633677.64.0.903795144816.issue14187@psf.upfronthosting.co.za> Chris Rebert added the comment: Any reactions to the strawman wording for the entry? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 09:31:25 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 10 May 2012 07:31:25 +0000 Subject: [issue14245] float rounding examples in FAQ are outdated In-Reply-To: <1331372112.92.0.532785259032.issue14245@psf.upfronthosting.co.za> Message-ID: <1336635085.21.0.00561429095376.issue14245@psf.upfronthosting.co.za> Mark Dickinson added the comment: Zbyszek, have you signed a contributor agreement form? [1] If not, please could you do so? Then I can apply this doc contribution. Thanks! [1] http://www.python.org/psf/contrib/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 10:42:37 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 10 May 2012 08:42:37 +0000 Subject: [issue14769] Add test to automatically detect missing format units in skipitem() Message-ID: <1336639357.09.0.810627542534.issue14769@psf.upfronthosting.co.za> New submission from Larry Hastings : I recently fixed an old bug: some time ago someone added support for a new "format unit", 'Z', to PyArg_Parse(), but neglected to add matching support for it to skipitem(). Benjamin asked for a regression test. Initially I said, okay, how the hell do I test that? A quick grep showed that there was already a test like that, for the format unit 'C'. I figured adding another one-off test was dumb, and there had to be a better way. Attached is a patch against trunk that adds a new function to _testcapimodule.c: test_skipitem_parity(). The comment at the top describes says it best: * This function brute-force tests all** ASCII characters (1 to 127 * inclusive) as format units, checking to see that * PyArg_ParseTupleAndKeywords() return consistent errors both when * the unit is attempted to be used and when it is skipped. If the * format unit doesn't exist, we'll get one of two specific error * messages (one for used, one for skipped); if it does exist we * *won't* get that error--we'll get either no error or some other * error. If we get the "does not exist" error for one test and * not for the other, there's a mismatch, and the test fails. * * ** Okay, it actually skips some ASCII characters. Some characters * have special funny semantics, and it would be difficult to * accomodate them here. I also removed the old test just for 'C', as this test subsumes that one. Right now, the test runs to completion without complaint. To test that it's really working, comment out an existing case statement in skipitem(). Or, add a new case statement, for a character that isn't otherwise supported (yet), to the top paragraph of case statements. Doing either of these will cause a failure. ... you happy now, Benjamin? ---------- assignee: larry components: Interpreter Core files: larry.test_skipitem_parity.1.diff keywords: patch messages: 160329 nosy: benjamin.peterson, larry priority: normal severity: normal stage: patch review status: open title: Add test to automatically detect missing format units in skipitem() type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25515/larry.test_skipitem_parity.1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 11:24:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 May 2012 09:24:20 +0000 Subject: [issue14767] urllib.request.HTTPRedirectHandler raises HTTPError when Location header is relative In-Reply-To: <1336613288.44.0.609842734336.issue14767@psf.upfronthosting.co.za> Message-ID: <1336641860.61.0.994236149918.issue14767@psf.upfronthosting.co.za> Antoine Pitrou added the comment: See issue12275. Seems like a common request. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 11:44:20 2012 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Thu, 10 May 2012 09:44:20 +0000 Subject: [issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper In-Reply-To: <1326892577.13.0.456815776311.issue13815@psf.upfronthosting.co.za> Message-ID: <1336643060.54.0.866618823868.issue13815@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Okay, I attached a patch that I hope we can all agree upon. It restores the ExFileObject class as a small subclass of BufferedReader as Amaury suggested. Does the documentation have to be changed, too? It states that an io.BufferedReader object is returned by extractfile() not a subclass thereof. ---------- Added file: http://bugs.python.org/file25516/tarfile-exfileobj.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 12:11:47 2012 From: report at bugs.python.org (Zbyszek Szmek) Date: Thu, 10 May 2012 10:11:47 +0000 Subject: [issue14245] float rounding examples in FAQ are outdated In-Reply-To: <1336635085.21.0.00561429095376.issue14245@psf.upfronthosting.co.za> Message-ID: <4FAB945B.5010306@in.waw.pl> Zbyszek Szmek added the comment: Done now. Thanks, Zbyszek ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 13:01:24 2012 From: report at bugs.python.org (Michael Foord) Date: Thu, 10 May 2012 11:01:24 +0000 Subject: [issue14770] Minor documentation fixes Message-ID: <1336647684.02.0.112519558227.issue14770@psf.upfronthosting.co.za> New submission from Michael Foord : A bunch of minor fixes for the documentation suggested by Kurt Robinson to the webmaster email address: Below, you will find 15 snippets from the Python 2.7.2 Library and Extension FAQ (http://docs.python.org/faq/library.html), categorized by problem type, accompanied by changes I would suggest or by questions I would have for the author. ********** Wrong word or missing word ********** (1) CURRENT TEXT: "Eventually you'll learn what's in the standard library and will able to skip this step." SUGGESTION: Change "will able" to "will be able". (2) CURRENT TEXT: "The location of the sendmail program varies between systems; sometimes it is /usr/lib/sendmail, sometime /usr/sbin/sendmail." SUGGESTION: Replace "sometime" with "sometimes". (3) CURRENT TEXT: "The Python parent can of course explicitly flush the data it sends to the child before it reads any output, but if the child is a naive C program it may have been written to never explicitly flush its output, even if it is interactive, since flushing is normally automatic." QUESTION: Is "naive C program" the intended wording or should it be "native C program"? (4) CURRENT TEXT: "[HTMLgen is] used when you are writing in Python and wish to synthesize HTML pages for generating a web or for CGI forms, etc." QUESTION: I believe "web" should be "webpage". Correct? (5) CURRENT TEXT: "The default format used by the pickle module is a slow one that results in readable pickles. Making it the default, but it would break backward compatibility." QUESTION: It looks like some words have been left out of the second sentence. What is the intended meaning there? ********** Punctuation issues ********** (6) CURRENT TEXT: "The standard Python source distribution comes with a curses module in the Modules/ subdirectory, though it's not compiled by default (note that this is not available in the Windows distribution - there is no curses module for Windows)." SUGGESTIONS: I believe the major style guides are in agreement that a complete-sentence parenthetical note falling at the end of another sentence should be punctuated as a separate sentence. I also think a semicolon would be more comfortable doing what that dash is doing, but I suppose that's a judgment call. Here's my suggested rewrite for the end of the sentence: ".though it's not compiled by default. (Note that this is not available in the Windows distribution; there is no curses module for Windows)." (7) CURRENT TEXT: "Thus, to read n bytes from a pipe p created with os.popen(), you need to use p.read(n)." SUGGESTION: Put commas before and after "p", or remove the "a" in front of "pipe". (8) CURRENT TEXT: 'For example to send name= "Guy Steele, Jr." .' SUGGESTIONS: Though it won't be apparent in this email, the quotation mark before "Guy" is a close-quote symbol (”). It should be an open-quote symbol (“). I would also put a comma after "for example". (9) CURRENT TEXT: "For example loading a half megabyte of data may take less than a third of a second." SUGGESTION: Insert a comma after "For example". ********** Ambiguity (or at least a momentary miscue) ********** (10) CURRENT TEXT: "For testing, it helps to write the program so that it may be easily tested by using good modular design." SUGGESTION: Though it will be clear for most readers that "by using good modular design" describes the writing process and not the testing process, a rewrite could avoid the miscue and improve the flow: "To get the most out of testing, you should use good modular design in your program." (11) CURRENT TEXT: "A test suite can be associated with each module which automates a sequence of tests." SUGGESTION: Though we can figure out that it's the test suite and not the module which automates a sequence of tests, a rewrite could avoid the miscue and improve readability: "A test suite that automates a sequence of tests can be associated with each module." (12) CURRENT TEXT: "Instead of trying to guess how long a time.sleep() delay will be enough, it's better to use some kind of semaphore mechanism." SUGGESTION: Insert "of" after "how long" to avoid leading to the reader down the path of "how long a time.sleep() delay will last." (13) CURRENT TEXT: "The Queue class maintains a list of objects with .put(obj) to add an item to the queue and .get() to return an item." SUGGESTIONS: Again, we can figure out that those are methods on the class not methods on the objects, but rephrasing the sentence so that it says that unambiguously makes for easier reading: "The Queue class maintains a list of objects and has a .put(obj) method, which adds items to the queue, and .get() method, which returns an item. Shifting momentarily to "content perspective", I think it could be helpful to be more specific about what .get() does. I would suggest changing "returns an item" to something like "returns the item which has been in the queue the longest". ********** Miscellaneous ********** (14) CURRENT TEXT: "This can be caused because the parent expects the child to output more text than it does, or it can be caused by data being stuck in stdio buffers due to lack of flushing." SUGGESTION: "Caused because" strikes my ear as slightly redundant and awkward, but perhaps that's just me. In any case, I think the sentence would read better if it had a more parallel structure: "This can be caused by the parent expecting the child to output more text than it does or by data being stuck in stdio buffers due to lack of flushing." (15) CURRENT TEXT: "The atexit module provides a register function that is similar to C's onexit." SUGGESTION: Change "onexit" to "onexit()". ---------- assignee: docs at python components: Documentation messages: 160333 nosy: docs at python, michael.foord priority: normal severity: normal stage: needs patch status: open title: Minor documentation fixes versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 13:28:52 2012 From: report at bugs.python.org (Joe Eaves) Date: Thu, 10 May 2012 11:28:52 +0000 Subject: [issue14457] Unattended Install doesn't populate registry In-Reply-To: <1333150946.4.0.260311652374.issue14457@psf.upfronthosting.co.za> Message-ID: <1336649332.95.0.385968390554.issue14457@psf.upfronthosting.co.za> Joe Eaves added the comment: There is an old bug report against 2.5 which dealt with a very similar problem, maybe the answers are the same? http://bugs.python.org/issue4567 Basically the location in the registry has changed from HKLM to HKCU. Here is the last message in the thread directly: http://bugs.python.org/msg78058 ---------- nosy: +Joe.Eaves _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 13:55:29 2012 From: report at bugs.python.org (Greg Weller) Date: Thu, 10 May 2012 11:55:29 +0000 Subject: [issue14766] Non-naive time comparison throws naive time error In-Reply-To: <1336601470.15.0.633873123281.issue14766@psf.upfronthosting.co.za> Message-ID: <1336650929.06.0.555177746623.issue14766@psf.upfronthosting.co.za> Greg Weller added the comment: I think this is a documentation bug. The criteria for datetime and time objects being aware are slightly different. A datetime object d is aware if d.tzinfo.utcoffset(d) does not return None, while a time object t is aware if t.tzinfo.utcoffset(None) does not return None (time objects call utcoffset with None while datetime objects call utcoffset with self). This accounts for the TypeError in the original example: >>> import pytz, datetime >>> UTC_TZ = pytz.utc >>> EASTERN_TZ = pytz.timezone('America/New_York') >>> d1 = datetime.time(10, tzinfo=UTC_TZ) >>> d2 = datetime.time(10, tzinfo=EASTERN_TZ) >>> repr(d1.tzinfo.utcoffset(None)) 'datetime.timedelta(0)' >>> repr(d2.tzinfo.utcoffset(None)) 'None' >>> d1 < d2 Traceback (most recent call last): File "", line 1, in TypeError: can't compare offset-naive and offset-aware times It looks like this example is flawed according to http://pytz.sourceforge.net/ : "Unfortunately using the tzinfo argument of the standard datetime constructors ??does not work?? with pytz for many timezones. It is safe for timezones without daylight savings trasitions though, such as UTC." (If you think about it, the error still makes sense: the UTC time is aware and the eastern time is naive -- any DST time object has to be naive -- but this has more to do with pytz). It doesn't make sense to have time objects pass self to utcoffset because utcoffset expects a datetime object. You shouldn't be able to infer what the UTC offset is from a time object unless the offset is constant, in which case you don't even need the time object. If the UTC offset isn't constant, you need the date, which a time object doesn't have. I think this is the logic behind having datetime objects call utcoffset(self) and time objects call utcoffset(None). I've attached a small patch for the documentation. ---------- keywords: +patch nosy: +greg.weller Added file: http://bugs.python.org/file25517/14766.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 14:01:58 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 10 May 2012 12:01:58 +0000 Subject: [issue14457] Unattended Install doesn't populate registry In-Reply-To: <1333150946.4.0.260311652374.issue14457@psf.upfronthosting.co.za> Message-ID: <1336651318.85.0.343546425774.issue14457@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Joe: this is indeed likely the explanation. Paul: can you confirm? Also: try adding "ALLUSERS=1" to the msiexec command line. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 14:33:22 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 May 2012 12:33:22 +0000 Subject: [issue14763] string.split maxsplit documented incorrectly In-Reply-To: <1336563037.57.0.851636000616.issue14763@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 0415ecd7b0e3 by Ezio Melotti in branch '2.7': #14763: document default maxsplit value for str.split. http://hg.python.org/cpython/rev/0415ecd7b0e3 New changeset 62659067f5b6 by Ezio Melotti in branch '3.2': #14763: document default maxsplit value for str.split. http://hg.python.org/cpython/rev/62659067f5b6 New changeset bcc964092437 by Ezio Melotti in branch 'default': #14763: merge with 3.2. http://hg.python.org/cpython/rev/bcc964092437 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 14:36:39 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 May 2012 12:36:39 +0000 Subject: [issue14763] string.split maxsplit documented incorrectly In-Reply-To: <1336563037.57.0.851636000616.issue14763@psf.upfronthosting.co.za> Message-ID: <1336653399.01.0.792234092173.issue14763@psf.upfronthosting.co.za> Ezio Melotti added the comment: I now documented it in the documentation of str.split too. I left the docstrings alone since they don't need to be as exhaustive as the official documentation, and there's normally no reason to use -1 directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 14:44:16 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 May 2012 12:44:16 +0000 Subject: [issue14759] BSDDB license missing from liscense page in 2.7. In-Reply-To: <1336525700.66.0.626657341837.issue14759@psf.upfronthosting.co.za> Message-ID: <1336653856.09.0.454508391332.issue14759@psf.upfronthosting.co.za> R. David Murray added the comment: Given the way Oracle is currently behaving, I personally think he is wise to delete it. It's optional at build-time anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 14:46:40 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 May 2012 12:46:40 +0000 Subject: [issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper In-Reply-To: <1326892577.13.0.456815776311.issue13815@psf.upfronthosting.co.za> Message-ID: <1336654000.45.0.135325434094.issue13815@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think a doc change is needed. An isinstance check based on the docs will succeed, and the rest is an implementation detail, I think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 14:52:28 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 10 May 2012 12:52:28 +0000 Subject: [issue14366] Supporting lzma compression in zip files In-Reply-To: <1332112236.1.0.964135054036.issue14366@psf.upfronthosting.co.za> Message-ID: <1336654348.46.0.0300709274097.issue14366@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Serhiy, just to be sure we communicated well: I'm not asking that all the missing features for a 6.3 level zip library must be implemented. Instead, we need to detect whether an unsupported feature is used, and raise an exception reporting what the feature is that is unsupported. This is necessary as we otherwise may return incorrect data. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 14:53:50 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 May 2012 12:53:50 +0000 Subject: [issue14766] Non-naive time comparison throws naive time error In-Reply-To: <1336601470.15.0.633873123281.issue14766@psf.upfronthosting.co.za> Message-ID: <1336654430.69.0.0272346620764.issue14766@psf.upfronthosting.co.za> R. David Murray added the comment: My, that's embarrassing. I somehow entirely missed the fact that we were dealing with times and not dates here. What you say makes sense to me, and the doc patch looks good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 15:13:15 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 May 2012 13:13:15 +0000 Subject: [issue14770] Minor documentation fixes In-Reply-To: <1336647684.02.0.112519558227.issue14770@psf.upfronthosting.co.za> Message-ID: <1336655595.4.0.451658883378.issue14770@psf.upfronthosting.co.za> Ezio Melotti added the comment: Attached a patch that addresses these problems: 1) done; 2) done; 3) I think "naive" is correct here (i.e. a naive program won't take care of flushing); 4) I remove the list of modules and left the link to the wiki page; 5) In the rst source there's a note that says "update this, default protocol is 2/3", but the pickle doc says "If a protocol is not specified, protocol 0 is used.". I left this unchanged for now; 6) done, but the dash seems ok to me, so I left it; 7) the comma sounds wrong to me, but I turned p to italic; 8) I think this is a Sphinx glitch (there might be already an issue for this somewhere). I added the comma; 9) done; 10) I rephrased the sentence; 11) done; 12) I rephrased the sentence; 13) I rephrased the sentence; 14) done; 15) done; ---------- assignee: docs at python -> ezio.melotti keywords: +patch nosy: +eric.araujo, ezio.melotti, r.david.murray, sandro.tosi stage: needs patch -> patch review type: -> enhancement Added file: http://bugs.python.org/file25518/issue14770.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 15:23:01 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 May 2012 13:23:01 +0000 Subject: [issue10765] Build regression from automation changes on windows In-Reply-To: <1293146347.8.0.828425848028.issue10765@psf.upfronthosting.co.za> Message-ID: <1336656181.81.0.978301545079.issue10765@psf.upfronthosting.co.za> Ezio Melotti added the comment: Avoiding spaces in the dir names might not be so easy, if e.g. you are trying to install it in "Program Files", "Users/Name Surname", or some other system directory that has spaces in there (sure, you could install it elsewhere, but in 2012 this shouldn't be an issue anymore). ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 16:34:12 2012 From: report at bugs.python.org (Georg Brandl) Date: Thu, 10 May 2012 14:34:12 +0000 Subject: [issue14770] Minor documentation fixes In-Reply-To: <1336647684.02.0.112519558227.issue14770@psf.upfronthosting.co.za> Message-ID: <1336660452.43.0.556527055858.issue14770@psf.upfronthosting.co.za> Georg Brandl added the comment: Re 5: the sentence needs to be rephrased in any case, because it's ungrammatical Re 8: it's not text, it's code, so it needs to go in code markup ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 16:38:11 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 May 2012 14:38:11 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding In-Reply-To: <1336327254.8.0.865225437508.issue14738@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e08c3791f035 by Antoine Pitrou in branch 'default': Issue #14738: Speed-up UTF-8 decoding on non-ASCII data. Patch by Serhiy Storchaka. http://hg.python.org/cpython/rev/e08c3791f035 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 16:38:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 May 2012 14:38:48 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding In-Reply-To: <1336327254.8.0.865225437508.issue14738@psf.upfronthosting.co.za> Message-ID: <1336660728.37.0.232697689413.issue14738@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patch is now committed. Well done and thanks for your contribution. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 17:01:30 2012 From: report at bugs.python.org (Pierre Quentel) Date: Thu, 10 May 2012 15:01:30 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1336662090.17.0.404446431927.issue11352@psf.upfronthosting.co.za> Pierre Quentel added the comment: I attach a new version after sharing thought with Glenn CGI scripts are still unable to define which encoding to use to print the strings received from the user agent. A patch was proposed #11066 but the issue is still pending. The new version documents this issue ---------- Added file: http://bugs.python.org/file25519/cgi-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 17:04:10 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 10 May 2012 15:04:10 +0000 Subject: [issue14770] Minor documentation fixes In-Reply-To: <1336647684.02.0.112519558227.issue14770@psf.upfronthosting.co.za> Message-ID: <1336662250.09.0.47928903237.issue14770@psf.upfronthosting.co.za> Ezio Melotti added the comment: Addressed 5) and 8). ---------- Added file: http://bugs.python.org/file25520/issue14770-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 17:13:32 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 May 2012 15:13:32 +0000 Subject: [issue14753] multiprocessing treats negative timeouts differently from before In-Reply-To: <1336489087.9.0.014285533368.issue14753@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 99ef4501205b by Richard Oudkerk in branch 'default': Issue #14753: Make multiprocessing treat negative timeouts as it did in 3.2 http://hg.python.org/cpython/rev/99ef4501205b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 17:14:47 2012 From: report at bugs.python.org (Chris Bergstresser) Date: Thu, 10 May 2012 15:14:47 +0000 Subject: [issue14766] Non-naive time comparison throws naive time error In-Reply-To: <1336601470.15.0.633873123281.issue14766@psf.upfronthosting.co.za> Message-ID: <1336662887.99.0.966996479319.issue14766@psf.upfronthosting.co.za> Chris Bergstresser added the comment: That patch fixes the documentation there, but the description at the top of the distinction between naive and aware time objects at the top datetime module is still wrong. Here it is: ----------------- There are two kinds of date and time objects: ?naive? and ?aware?. This distinction refers to whether the object has any notion of time zone, daylight saving time, or other kind of algorithmic or political time adjustment. Whether a naive datetime object represents Coordinated Universal Time (UTC), local time, or time in some other timezone is purely up to the program, just like it?s up to the program whether a particular number represents metres, miles, or mass. Naive datetime objects are easy to understand and to work with, at the cost of ignoring some aspects of reality. ------------------ The distinction is not whether the object has any notion of "time zone, daylight saving time, or other kind of algorithmic or political time adjustment", but instead whether, in the context it's being used, it can calculate an offset to UTC. A naive time can be used to create an aware datetime. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 17:37:20 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 10 May 2012 15:37:20 +0000 Subject: [issue14187] add "annotation" entry to Glossary In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za> Message-ID: <1336664240.53.0.00728299220111.issue14187@psf.upfronthosting.co.za> ?ric Araujo added the comment: Looks good to me, with the proviso that it should be ?function annotation?. ---------- versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 17:41:41 2012 From: report at bugs.python.org (Tom Pinckney) Date: Thu, 10 May 2012 15:41:41 +0000 Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za> Message-ID: <1336664501.35.0.577981915.issue13241@psf.upfronthosting.co.za> Tom Pinckney added the comment: FWIW, clang from Xcode 4.3.2 build 4E2002 w/ command line tools built everything fine for me too (i.e., ./configure CC=clang). LM-SJN-00377886:cpython tom$ uname -a Darwin LM-SJN-00377886 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64 LM-SJN-00377886:cpython tom$ /usr/bin/clang --version Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn) Target: x86_64-apple-darwin11.3.0 Thread model: posix LM-SJN-00377886:cpython tom$ hg summary parent: 76839:bb30116024ac tip Minor fix for test_multiprocessing branch: default commit: (clean) update: (current) ---------- nosy: +thomaspinckney3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 18:02:07 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 May 2012 16:02:07 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1336665727.27.0.39337322371.issue9260@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I had forgotten to tackle threadless builds, this patch fixes it. ---------- Added file: http://bugs.python.org/file25521/module_locks9.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 19:12:06 2012 From: report at bugs.python.org (Tom Pinckney) Date: Thu, 10 May 2012 17:12:06 +0000 Subject: [issue1508475] transparent gzip compression in urllib Message-ID: <1336669926.23.0.176905412563.issue1508475@psf.upfronthosting.co.za> Tom Pinckney added the comment: What if this gzip decompression was optional and controlled via a flag or handler instead of making it automagic? It's not entirely trivial to implement so it is nice to have the option of this happening automatically if one wishes. Then, the caller would be aware that Content-length / Accept-encoding / Content-encoding etc have been modified iff they requested gzip decompression. ---------- nosy: +thomaspinckney3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 20:11:29 2012 From: report at bugs.python.org (Tom Pinckney) Date: Thu, 10 May 2012 18:11:29 +0000 Subject: [issue6696] Profile objects should be documented In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za> Message-ID: <1336673489.73.0.0266622139109.issue6696@psf.upfronthosting.co.za> Tom Pinckney added the comment: Looking at the current docs for 3.3, it looks like there are a bunch of other ways that the docs could be clarified: 1) Proper documentation of the complete profile.Profile() and cProfile.Profile() interfaces. 2) Adding other examples to the quick start section at the top for how to process the resulting stats without printing them to stdout or writing them to a file. I'll take a stab at this. ---------- nosy: +thomaspinckney3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 20:19:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 May 2012 18:19:13 +0000 Subject: [issue14771] Occasional failure in test_ioctl Message-ID: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This happens from time to time on my desktop computer: [151/354/1] test_ioctl test test_ioctl failed -- Traceback (most recent call last): File "/home/antoine/cpython/32/Lib/test/test_ioctl.py", line 36, in test_ioctl self.assertIn(rpgrp, ids) AssertionError: 25242 not found in (23865, 23615) ---------- components: Library (Lib), Tests messages: 160357 nosy: neologix, pitrou priority: low severity: normal status: open title: Occasional failure in test_ioctl type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 20:20:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 May 2012 18:20:57 +0000 Subject: [issue14157] time.strptime without a year fails on Feb 29 In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f2ea7505c0d7 by Antoine Pitrou in branch '3.2': Issue #14157: Fix time.strptime failing without a year on February 29th. http://hg.python.org/cpython/rev/f2ea7505c0d7 New changeset a5a254e8a291 by Antoine Pitrou in branch 'default': Issue #14157: Fix time.strptime failing without a year on February 29th. http://hg.python.org/cpython/rev/a5a254e8a291 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 20:23:04 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 May 2012 18:23:04 +0000 Subject: [issue14157] time.strptime without a year fails on Feb 29 In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 69d407b016c1 by Antoine Pitrou in branch '2.7': Issue #14157: Fix time.strptime failing without a year on February 29th. http://hg.python.org/cpython/rev/69d407b016c1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 20:24:17 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 May 2012 18:24:17 +0000 Subject: [issue14157] time.strptime without a year fails on Feb 29 In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za> Message-ID: <1336674257.52.0.596805450377.issue14157@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Patch committed and pushed, thank you! ---------- assignee: belopolsky -> resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 20:28:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 May 2012 18:28:26 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za> Message-ID: <1336674506.65.0.516976055092.issue14082@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patch looks ok, but it would be nice if someone with non-broken xattr support could test it. Although I suppose you did run the test suite, Hynek? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 21:06:41 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 10 May 2012 19:06:41 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za> Message-ID: <1336676801.74.0.477883402889.issue14082@psf.upfronthosting.co.za> Hynek Schlawack added the comment: I did. The only error I got was ERROR: test_idna (test.test_socket.GeneralModuleTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/vagrant/p2/Lib/test/test_socket.py", line 1182, in test_idna socket.gethostbyname('?????????.python.org') socket.gaierror: [Errno -3] Temporary failure in name resolution I presume it's unrelated. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 21:26:27 2012 From: report at bugs.python.org (Brian Curtin) Date: Thu, 10 May 2012 19:26:27 +0000 Subject: [issue14772] Return destination values in some shutil functions Message-ID: <1336677987.7.0.16571427099.issue14772@psf.upfronthosting.co.za> New submission from Brian Curtin : Attached is a patch to return the final destination of files or directories sent through shutil's copy, copy2, and move functions. This removes the need to construct the destination path on your own. This is especially useful for copy/copy2 where you copy a file into a directory and need to know that resulting path. Rather than calling os.path.join(dest, os.path.basename(source)) you could get that path from copy/copy2 (which does that join internally). Patch has docs and tests. ---------- assignee: brian.curtin components: Library (Lib) files: shutil_return_values.diff keywords: needs review, patch messages: 160363 nosy: brian.curtin priority: normal severity: normal stage: patch review status: open title: Return destination values in some shutil functions type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25522/shutil_return_values.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 21:28:40 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 10 May 2012 19:28:40 +0000 Subject: [issue14773] fwalk breaks on dangling symlinks Message-ID: <1336678120.54.0.411663637267.issue14773@psf.upfronthosting.co.za> New submission from Hynek Schlawack : I'm implementing a safe rmtree using fwalk. Everything works perfectly except for one thing: if the directory contains dangling symlinks, fwalk goes belly-up: $ ls -l test/ total 0 lrwxrwxrwx 1 vagrant vagrant 4 May 10 16:36 doesntwork -> this $ ./python Python 3.3.0a3+ (default:b32baa5b7626+, May 10 2012, 14:56:20) [GCC 4.6.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os [71253 refs] >>> list(os.fwalk('test')) Traceback (most recent call last): File "", line 1, in File "/home/vagrant/p/Lib/os.py", line 342, in fwalk for x in _fwalk(topfd, top, topdown, onerror, followlinks): File "/home/vagrant/p/Lib/os.py", line 361, in _walk if st.S_ISDIR(fstatat(topfd, name).st_mode): FileNotFoundError: [Errno 2] No such file or directory Unfortunately this makes it impossible to implement rmtree. The reason is the following code: for name in names: # Here, we don't use AT_SYMLINK_NOFOLLOW to be consistent with # walk() which reports symlinks to directories as directories. We do # however check for symlinks before recursing into a subdirectory. if st.S_ISDIR(fstatat(topfd, name).st_mode): dirs.append(name) else: nondirs.append(name) The "unsafe" walk tree uses os.path.isdir() instead of os.fstatat() and handles this case gracefully. A simple try-except protection with a symlink check fixes it and the tests pass. This is a blocker for #4489. I have expanded the test of the WalkerTests suite. Tested on Linux (= works) and OS X (= skipped). ---------- assignee: hynek components: Library (Lib) files: make-fwalk-handle-dangling-symlinks.diff keywords: patch messages: 160364 nosy: hynek, neologix priority: normal severity: normal stage: patch review status: open title: fwalk breaks on dangling symlinks type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file25523/make-fwalk-handle-dangling-symlinks.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 21:30:55 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 10 May 2012 19:30:55 +0000 Subject: [issue14772] Return destination values in some shutil functions In-Reply-To: <1336677987.7.0.16571427099.issue14772@psf.upfronthosting.co.za> Message-ID: <1336678255.01.0.0624599750628.issue14772@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 21:32:00 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 10 May 2012 19:32:00 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1336678320.01.0.936087440561.issue4489@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- assignee: tarek -> dependencies: +fwalk breaks on dangling symlinks keywords: -patch stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 21:42:10 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 10 May 2012 19:42:10 +0000 Subject: [issue14753] multiprocessing treats negative timeouts differently from before In-Reply-To: <1336489087.9.0.014285533368.issue14753@psf.upfronthosting.co.za> Message-ID: <1336678930.92.0.142531685993.issue14753@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 21:44:36 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 10 May 2012 19:44:36 +0000 Subject: [issue14769] Add test to automatically detect missing format units in skipitem() In-Reply-To: <1336639357.09.0.810627542534.issue14769@psf.upfronthosting.co.za> Message-ID: <1336679076.64.0.771711205906.issue14769@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Can you see if you can write that test in Python? Perhaps simply providing a wrapper to cal PyArg_Parse with the arguments you want. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 21:47:34 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 10 May 2012 19:47:34 +0000 Subject: [issue14774] _sysconfigdata.py doesn't support multiple build configurations Message-ID: <1336679254.12.0.498386228703.issue14774@psf.upfronthosting.co.za> New submission from Dave Malcolm : When building from source, if I create multiple configuration directories and build from there e.g.: mkdir configs cd configs mkdir config-A cd config-A ../../configure make cd .. mkdir config-B cd config-B ../../configure --enable-shared make cd ../config-A ./python -c "import sysconfig; print(sysconfig.get_config_var('CONFIG_ARGS') then sysconfig's settings are the same for *every* config, reflecting those of the last build (config-B above, rathern than those of config-A). This turns out to be due to this: ./python -SE -m sysconfig --generate-posix-vars This generates $(srcdir)/Lib/_sysconfigdata.py for whichever config was last Is there a way of fixing this whilst keeping it a python file? Or do we need to build from a C file, perhaps? ---------- components: Build messages: 160366 nosy: dmalcolm priority: normal severity: normal status: open title: _sysconfigdata.py doesn't support multiple build configurations type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 21:55:25 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 10 May 2012 19:55:25 +0000 Subject: [issue14774] _sysconfigdata.py doesn't support multiple build configurations In-Reply-To: <1336679254.12.0.498386228703.issue14774@psf.upfronthosting.co.za> Message-ID: <1336679725.18.0.393757753717.issue14774@psf.upfronthosting.co.za> Dave Malcolm added the comment: Note to self: workaround is to rm ../../Lib/_sysconfigdata.py || make ../../Lib/_sysconfigdata.py before running my tests in either configuration, to force the file to be regenerated using what "make" thinks the settings are ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 22:03:54 2012 From: report at bugs.python.org (stw) Date: Thu, 10 May 2012 20:03:54 +0000 Subject: [issue14775] Slow unpickling of certain dictionaries in python 2.7 vs python 2.6 Message-ID: <1336680234.2.0.688892312973.issue14775@psf.upfronthosting.co.za> New submission from stw : I've found that unpickling a certain kind of dictionary is substantially slower in python 2.7 compared to python 2.6. The dictionary has keys that are tuples of strings - a 1-tuple is enough to see the effect. The problem seems to be caused by garbage collection, as turning it off eliminates the slowdown. Both pickle and cPickle modules are affected. I've attached two files to demonstrate this. The file 'make_file.py' creates a dictionary of specified size, with keys containing 1-tuples of random strings. It then dumps the dictionary to a pickle file using a specified pickle module. The file 'load_file.py' unpickles the file created by 'make_file.py', using a specified pickle module, and prints the time taken. The code can be run with garbage collection either on or off. The results below are for a dictionary of 200000 entries. Each entry is the time taken in seconds with garbage collection on / garbage collection off. The row headings are the module used to pickle the data, the column headings the module used to unpickle it. python 2.6, n = 200000 size pickle cPickle pickle 4.3M 3.02/2.65 0.786/0.559 cPickle 3.4M 2.27/2.04 0.66/0.443 python 2.7, n = 200000 size pickle cPickle pickle 4.3M 10.5/2.67 6.62/0.563 cPickle 2.4M 1.45/1.39 0.362/0.325 When pickle is used to pickle the data, there is a significant slowdown in python 2.7 compared to python 2.6 with garbage collection on. With garbage collection off the times in python 2.7 are essentially identical to those in python 2.6. When cPickle is used to pickle the data, both unpicklers are faster in python 2.7 than in python 2.6. Presumably the speedup is due to the dictionary optimizations introduced from issue #5670. Both pickle and cPickle show a slowdown when data pickled in python 2.6 is unpickled in python 2.7: pickled in python 2.6, unpickled in python 2.7, n = 200000 size pickle (2.7) cPickle (2.7) pickle (2.6) 4.3M 10.4/2.66 6.64/0.56 cPickle (2.6) 3.4M 8.73/2.08 6.1/0.452 I don't know enough about the internals of the pickle modules or garbage collector to offer an explanation/fix. The list of optimizations for python 2.7 indicates changes to both pickle modules (issues #5670 and #5084) and the garbage collector (issues #4074 and #4688). It seems possible that the slowdown is the result of some interaction between these changes. Further notes: 1. System details: python 2.6.5 and python 2.7.3 on Ubuntu 10.04, 1.73GHz Pentium M processor. 2. Only pickle files created with protocols 1 and 2 are affected. Pickling with protocol 0 gives similar timings on python 2.6 and 2.7. 3. The fact that the dictionary's keys are tuples is relevant, although the length of the tuple is not. Unpickling a dictionary whose keys are strings does not show any slowdown. ---------- files: make_file.py messages: 160368 nosy: stw priority: normal severity: normal status: open title: Slow unpickling of certain dictionaries in python 2.7 vs python 2.6 type: performance versions: Python 2.7 Added file: http://bugs.python.org/file25524/make_file.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 22:04:48 2012 From: report at bugs.python.org (stw) Date: Thu, 10 May 2012 20:04:48 +0000 Subject: [issue14775] Slow unpickling of certain dictionaries in python 2.7 vs python 2.6 In-Reply-To: <1336680234.2.0.688892312973.issue14775@psf.upfronthosting.co.za> Message-ID: <1336680288.68.0.289851362591.issue14775@psf.upfronthosting.co.za> Changes by stw : Added file: http://bugs.python.org/file25525/load_file.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 22:15:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 May 2012 20:15:20 +0000 Subject: [issue14775] Slow unpickling of certain dictionaries in python 2.7 vs python 2.6 In-Reply-To: <1336680234.2.0.688892312973.issue14775@psf.upfronthosting.co.za> Message-ID: <1336680920.83.0.390654845588.issue14775@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > When pickle is used to pickle the data, there is a significant slowdown > Both pickle and cPickle show a slowdown when data pickled in python 2.6 is unpickled in python 2.7: This sounds rather weird. Presumably the structure of the pickle streams shouldn't have changed from 2.6 to 2.7. You can use the pickletools.dis() function to disassemble a pickle stream, and examine whether there are any differences between the various files. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 22:27:52 2012 From: report at bugs.python.org (Brian Curtin) Date: Thu, 10 May 2012 20:27:52 +0000 Subject: [issue14772] Return destination values in some shutil functions In-Reply-To: <1336677987.7.0.16571427099.issue14772@psf.upfronthosting.co.za> Message-ID: <1336681672.23.0.910205478749.issue14772@psf.upfronthosting.co.za> Brian Curtin added the comment: Here's a patch that fixes the trailing whitespace Hynek noticed as well as adds an additional test case for copy/copy2. ---------- Added file: http://bugs.python.org/file25526/issue14772.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 22:41:51 2012 From: report at bugs.python.org (Brian Curtin) Date: Thu, 10 May 2012 20:41:51 +0000 Subject: [issue14772] Return destination values in some shutil functions In-Reply-To: <1336677987.7.0.16571427099.issue14772@psf.upfronthosting.co.za> Message-ID: <1336682511.53.0.277119042728.issue14772@psf.upfronthosting.co.za> Brian Curtin added the comment: Added another test using move as renaming the destination file. ---------- Added file: http://bugs.python.org/file25527/issue14772_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 22:45:53 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 10 May 2012 20:45:53 +0000 Subject: [issue14772] Return destination values in some shutil functions In-Reply-To: <1336677987.7.0.16571427099.issue14772@psf.upfronthosting.co.za> Message-ID: <1336682753.29.0.121045718021.issue14772@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Code LGTM, a deeper discussion happened on IRC. :) I'd still suggest for the sake of consistency to return the destination from copytree() too, but that can be done separately. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 22:47:25 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 May 2012 20:47:25 +0000 Subject: [issue14366] Supporting lzma compression in zip files In-Reply-To: <1336654348.46.0.0300709274097.issue14366@psf.upfronthosting.co.za> Message-ID: <1336682989.2920.16.camel@raxxla> Serhiy Storchaka added the comment: I understand you, Martin. The time it took me to read the specification and understand where should be the checks in the module. The patch updated. The list of compression methods extended (in the future it can be used for detailed output in the printdir()), flag of strict encryption is checked directly, encrypted or compressed central directory just will not be found (BadZipFile will be raised). ---------- Added file: http://bugs.python.org/file25528/lzma_in_zip_3.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r e08c3791f035 Doc/library/zipfile.rst --- a/Doc/library/zipfile.rst Thu May 10 16:36:02 2012 +0200 +++ b/Doc/library/zipfile.rst Thu May 10 23:17:48 2012 +0300 @@ -97,12 +97,20 @@ .. versionadded:: 3.3 +.. data:: ZIP_LZMA + + The numeric constant for the LZMA compression method. This requires the + lzma module. + + .. versionadded:: 3.3 + .. note:: The ZIP file format specification has included support for bzip2 compression - since 2001. However, some tools (including older Python releases) do not - support it, and may either refuse to process the ZIP file altogether, or - fail to extract individual files. + since 2001, and for LZMA compression since 2006. However, some tools + (including older Python releases) do not support these compression + methods, and may either refuse to process the ZIP file altogether, + or fail to extract individual files. .. seealso:: @@ -133,11 +141,11 @@ adding a ZIP archive to another file (such as :file:`python.exe`). If *mode* is ``a`` and the file does not exist at all, it is created. *compression* is the ZIP compression method to use when writing the archive, - and should be :const:`ZIP_STORED`, :const:`ZIP_DEFLATED`; or - :const:`ZIP_DEFLATED`; unrecognized - values will cause :exc:`RuntimeError` to be raised. If :const:`ZIP_DEFLATED` or - :const:`ZIP_BZIP2` is specified but the corresponded module - (:mod:`zlib` or :mod:`bz2`) is not available, :exc:`RuntimeError` + and should be :const:`ZIP_STORED`, :const:`ZIP_DEFLATED`, + :const:`ZIP_BZIP2` or :const:`ZIP_LZMA`; unrecognized + values will cause :exc:`RuntimeError` to be raised. If :const:`ZIP_DEFLATED`, + :const:`ZIP_BZIP2` or :const:`ZIP_LZMA` is specified but the corresponded module + (:mod:`zlib`, :mod:`bz2` or :mod:`lzma`) is not available, :exc:`RuntimeError` is also raised. The default is :const:`ZIP_STORED`. If *allowZip64* is ``True`` zipfile will create ZIP files that use the ZIP64 extensions when the zipfile is larger than 2 GB. If it is false (the default) :mod:`zipfile` @@ -161,7 +169,7 @@ Added the ability to use :class:`ZipFile` as a context manager. .. versionchanged:: 3.3 - Added support for :mod:`bzip2` compression. + Added support for :mod:`bzip2` and :mod:`lzma` compression. .. method:: ZipFile.close() diff -r e08c3791f035 Lib/test/support.py --- a/Lib/test/support.py Thu May 10 16:36:02 2012 +0200 +++ b/Lib/test/support.py Thu May 10 23:17:48 2012 +0300 @@ -45,6 +45,11 @@ except ImportError: bz2 = None +try: + import lzma +except ImportError: + lzma = None + __all__ = [ "Error", "TestFailed", "ResourceDenied", "import_module", "verbose", "use_resources", "max_memuse", "record_original_stdout", @@ -62,7 +67,7 @@ "get_attribute", "swap_item", "swap_attr", "requires_IEEE_754", "TestHandler", "Matcher", "can_symlink", "skip_unless_symlink", "import_fresh_module", "requires_zlib", "PIPE_MAX_SIZE", "failfast", - "anticipate_failure", "run_with_tz", "requires_bz2" + "anticipate_failure", "run_with_tz", "requires_bz2", "requires_lzma" ] class Error(Exception): @@ -513,6 +518,8 @@ requires_bz2 = unittest.skipUnless(bz2, 'requires bz2') +requires_lzma = unittest.skipUnless(lzma, 'requires lzma') + is_jython = sys.platform.startswith('java') # Filename used for testing diff -r e08c3791f035 Lib/test/test_zipfile.py --- a/Lib/test/test_zipfile.py Thu May 10 16:36:02 2012 +0200 +++ b/Lib/test/test_zipfile.py Thu May 10 23:17:48 2012 +0300 @@ -13,7 +13,7 @@ from random import randint, random from unittest import skipUnless -from test.support import TESTFN, run_unittest, findfile, unlink, requires_zlib, requires_bz2 +from test.support import TESTFN, run_unittest, findfile, unlink, requires_zlib, requires_bz2, requires_lzma TESTFN2 = TESTFN + "2" TESTFNDIR = TESTFN + "d" @@ -361,6 +361,55 @@ self.assertEqual(openobj.read(1), b'1') self.assertEqual(openobj.read(1), b'2') + @requires_lzma + def test_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_open_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_open_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_random_open_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_random_open_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_readline_read_lzma(self): + # Issue #7610: calls to readline() interleaved with calls to read(). + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_readline_read_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_readline_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_readline_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_readlines_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_readlines_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_iterlines_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_iterlines_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_low_compression_lzma(self): + """Check for cases where compressed data is larger than original.""" + # Create the ZIP archive + with zipfile.ZipFile(TESTFN2, "w", zipfile.ZIP_LZMA) as zipfp: + zipfp.writestr("strfile", '12') + + # Get an open object for strfile + with zipfile.ZipFile(TESTFN2, "r", zipfile.ZIP_LZMA) as zipfp: + with zipfp.open("strfile") as openobj: + self.assertEqual(openobj.read(1), b'1') + self.assertEqual(openobj.read(1), b'2') + def test_absolute_arcnames(self): with zipfile.ZipFile(TESTFN2, "w", zipfile.ZIP_STORED) as zipfp: zipfp.write(TESTFN, "/absolute") @@ -508,6 +557,13 @@ info = zipfp.getinfo('b.txt') self.assertEqual(info.compress_type, zipfile.ZIP_BZIP2) + @requires_lzma + def test_writestr_compression_lzma(self): + zipfp = zipfile.ZipFile(TESTFN2, "w") + zipfp.writestr("b.txt", "hello world", compress_type=zipfile.ZIP_LZMA) + info = zipfp.getinfo('b.txt') + self.assertEqual(info.compress_type, zipfile.ZIP_LZMA) + def zip_test_writestr_permissions(self, f, compression): # Make sure that writestr creates files with mode 0600, # when it is passed a name rather than a ZipInfo instance. @@ -686,6 +742,11 @@ for f in (TESTFN2, TemporaryFile(), io.BytesIO()): self.zip_test(f, zipfile.ZIP_BZIP2) + @requires_lzma + def test_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_test(f, zipfile.ZIP_LZMA) + def test_absolute_arcnames(self): with zipfile.ZipFile(TESTFN2, "w", zipfile.ZIP_STORED, allowZip64=True) as zipfp: @@ -826,6 +887,16 @@ b'\x00 \x80\x80\x81\x00\x00\x00\x00afilePK' b'\x05\x06\x00\x00\x00\x00\x01\x00\x01\x003\x00\x00\x00[\x00' b'\x00\x00\x00\x00'), + zipfile.ZIP_LZMA: ( + b'PK\x03\x04\x14\x03\x00\x00\x0e\x00nu\x0c=FA' + b'KE\x1b\x00\x00\x00n\x00\x00\x00\x05\x00\x00\x00af' + b'ile\t\x04\x05\x00]\x00\x00\x00\x04\x004\x19I' + b'\xee\x8d\xe9\x17\x89:3`\tq!.8\x00PK' + b'\x01\x02\x14\x03\x14\x03\x00\x00\x0e\x00nu\x0c=FA' + b'KE\x1b\x00\x00\x00n\x00\x00\x00\x05\x00\x00\x00\x00\x00' + b'\x00\x00\x00\x00 \x80\x80\x81\x00\x00\x00\x00afil' + b'ePK\x05\x06\x00\x00\x00\x00\x01\x00\x01\x003\x00\x00' + b'\x00>\x00\x00\x00\x00\x00'), } def test_unsupported_version(self): @@ -1104,6 +1175,10 @@ def test_testzip_with_bad_crc_bzip2(self): self.check_testzip_with_bad_crc(zipfile.ZIP_BZIP2) + @requires_lzma + def test_testzip_with_bad_crc_lzma(self): + self.check_testzip_with_bad_crc(zipfile.ZIP_LZMA) + def check_read_with_bad_crc(self, compression): """Tests that files with bad CRCs raise a BadZipFile exception when read.""" zipdata = self.zips_with_bad_crc[compression] @@ -1136,6 +1211,10 @@ def test_read_with_bad_crc_bzip2(self): self.check_read_with_bad_crc(zipfile.ZIP_BZIP2) + @requires_lzma + def test_read_with_bad_crc_lzma(self): + self.check_read_with_bad_crc(zipfile.ZIP_LZMA) + def check_read_return_size(self, compression): # Issue #9837: ZipExtFile.read() shouldn't return more bytes # than requested. @@ -1160,6 +1239,10 @@ def test_read_return_size_bzip2(self): self.check_read_return_size(zipfile.ZIP_BZIP2) + @requires_lzma + def test_read_return_size_lzma(self): + self.check_read_return_size(zipfile.ZIP_LZMA) + def test_empty_zipfile(self): # Check that creating a file in 'w' or 'a' mode and closing without # adding any files to the archives creates a valid empty ZIP file @@ -1306,6 +1389,11 @@ for f in (TESTFN2, TemporaryFile(), io.BytesIO()): self.zip_test(f, zipfile.ZIP_BZIP2) + @requires_lzma + def test_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_test(f, zipfile.ZIP_LZMA) + def zip_open_test(self, f, compression): self.make_test_archive(f, compression) @@ -1351,6 +1439,11 @@ for f in (TESTFN2, TemporaryFile(), io.BytesIO()): self.zip_open_test(f, zipfile.ZIP_BZIP2) + @requires_lzma + def test_open_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_open_test(f, zipfile.ZIP_LZMA) + def zip_random_open_test(self, f, compression): self.make_test_archive(f, compression) @@ -1384,6 +1477,11 @@ for f in (TESTFN2, TemporaryFile(), io.BytesIO()): self.zip_random_open_test(f, zipfile.ZIP_BZIP2) + @requires_lzma + def test_random_open_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.zip_random_open_test(f, zipfile.ZIP_LZMA) + @requires_zlib class TestsWithMultipleOpens(unittest.TestCase): @@ -1628,6 +1726,31 @@ for f in (TESTFN2, TemporaryFile(), io.BytesIO()): self.iterlines_test(f, zipfile.ZIP_BZIP2) + @requires_lzma + def test_read_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.read_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_readline_read_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.readline_read_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_readline_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.readline_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_readlines_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.readlines_test(f, zipfile.ZIP_LZMA) + + @requires_lzma + def test_iterlines_lzma(self): + for f in (TESTFN2, TemporaryFile(), io.BytesIO()): + self.iterlines_test(f, zipfile.ZIP_LZMA) + def tearDown(self): for sep, fn in self.arcfiles.items(): os.remove(fn) diff -r e08c3791f035 Lib/zipfile.py --- a/Lib/zipfile.py Thu May 10 16:36:02 2012 +0200 +++ b/Lib/zipfile.py Thu May 10 23:17:48 2012 +0300 @@ -27,8 +27,13 @@ except ImportError: bz2 = None +try: + import lzma # We may need its compression method +except ImportError: + lzma = None + __all__ = ["BadZipFile", "BadZipfile", "error", - "ZIP_STORED", "ZIP_DEFLATED", "ZIP_BZIP2", + "ZIP_STORED", "ZIP_DEFLATED", "ZIP_BZIP2", "ZIP_LZMA", "is_zipfile", "ZipInfo", "ZipFile", "PyZipFile", "LargeZipFile"] class BadZipFile(Exception): @@ -52,13 +57,15 @@ ZIP_STORED = 0 ZIP_DEFLATED = 8 ZIP_BZIP2 = 12 +ZIP_LZMA = 14 # Other ZIP compression methods not supported DEFAULT_VERSION = 20 ZIP64_VERSION = 45 BZIP2_VERSION = 46 +LZMA_VERSION = 63 # we recognize (but not necessarily support) all features up to that version -MAX_EXTRACT_VERSION = 46 +MAX_EXTRACT_VERSION = 63 # Below are some formats and associated data for reading/writing headers using # the struct module. The names and structures of headers/records are those used @@ -367,6 +374,8 @@ if self.compress_type == ZIP_BZIP2: min_version = max(BZIP2_VERSION, min_version) + elif self.compress_type == ZIP_LZMA: + min_version = max(LZMA_VERSION, min_version) self.extract_version = max(min_version, self.extract_version) self.create_version = max(min_version, self.create_version) @@ -480,6 +489,77 @@ return c +class LZMACompressor: + + def __init__(self): + self._comp = None + + def _init(self): + props = lzma.encode_filter_properties({'id': lzma.FILTER_LZMA1}) + self._comp = lzma.LZMACompressor(lzma.FORMAT_RAW, filters=[ + lzma.decode_filter_properties(lzma.FILTER_LZMA1, props) + ]) + return struct.pack(' New submission from Dave Malcolm : I'm attaching a patch which adds static markers for SystemTap for two probeable events within CPython's bytecode interpreter, along with test cases and documentation. I'm hoping to get this merged for 3.3; is this PEP-worthy, or can this be done through patch review? Note: issue #4111 was originally opened on 2008-10-12 as "Add DTrace probes", and was generalized on 2009-12-08 to "Add Systemtap/DTrace probes". That issue was closed on 2011-11-14 to be superceded by issue #13405 ("Add DTrace probes"), hence I'm opening this as a separate issue. I believe that although DTrace and SystemTap are similar, they are sufficiently different from each other that it's going to take separate work to support one or the other (and that the maintainers of the support for each within CPython are likely to be different people). I hope that once one of them is merged, the other will become a lot easier to merge. Potentially other markers could be added for other events (the DTrace patch in issue #13405 has gained some), but I wanted to start small for now. ---------- components: Interpreter Core files: cpython-systemtap-2012-05-10-001.patch keywords: needs review, patch messages: 160374 nosy: dmalcolm priority: normal severity: normal stage: patch review status: open title: Add SystemTap static markers type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25529/cpython-systemtap-2012-05-10-001.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 23:08:00 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 10 May 2012 21:08:00 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1336684080.91.0.0326239733282.issue13405@psf.upfronthosting.co.za> Dave Malcolm added the comment: I've refreshed my SystemTap patch, and opened a new issue, issue #14776 to cover SystemTap. Issue #4111 was originally opened on 2008-10-12 as "Add DTrace probes", and was generalized on 2009-12-08 to "Add Systemtap/DTrace probes". That issue was closed on 2011-11-14 to be superceded by issue #13405 ("Add DTrace probes"), hence I opened the SystemTap RFE as a separate issue to this one. As noted in issue #14776: I believe that although DTrace and SystemTap are similar, they are sufficiently different from each other that it's going to take separate work to support one or the other (and that the maintainers of the support for each within CPython are likely to be different people). I hope that once one of them is merged, the other will become a lot easier to merge. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 10 23:20:56 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 10 May 2012 21:20:56 +0000 Subject: [issue13734] Add a generic directory walker method to avoid symlink attacks In-Reply-To: <1325981643.51.0.923790442233.issue13734@psf.upfronthosting.co.za> Message-ID: <1336684856.55.0.156045803992.issue13734@psf.upfronthosting.co.za> Benjamin Peterson added the comment: It would be nice if the documentation of fwalk() explained why you would want to use it over walk(). ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 00:24:06 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 May 2012 22:24:06 +0000 Subject: [issue10376] ZipFile unzip is unbuffered In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za> Message-ID: <1336688646.86.0.522953899714.issue10376@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is not because zipfile module is unbuffered. This is the difference between expensive function call and cheap bytes slicing. Replace `zf.open(namelist [0])` to `io.BufferedReader(zf.open(namelist [0]))` to see the effect of a good buffering. In 3.2 zipfile read() implemented not optimal, so it slower (twice), but in 3.3 it will be almost as fast as using io.BufferedReader. It is still several times more slowly than bytes slicing, but there's nothing you can do with it. Here is a patch, which is speeds up (+20%) the reading from a zip file by small chunks. Microbenchmark: ./python -m zipfile -c test.zip python ./python -m timeit -n 1 -s "import zipfile;zf=zipfile.ZipFile('test.zip')" "with zf.open('python') as f:" " while f.read(1):pass" Python 3.3 (vanilla): 1 loops, best of 3: 36.4 sec per loop Python 3.3 (patched): 1 loops, best of 3: 30.1 sec per loop Python 3.3 (with io.BufferedReader): 1 loops, best of 3: 30.2 sec per loop And, for comparison, Python 3.2: 1 loops, best of 3: 74.5 sec per loop ---------- components: -Documentation keywords: +patch versions: -Python 2.7, Python 3.2 Added file: http://bugs.python.org/file25530/zipfile_optimize_read.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 00:26:06 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 May 2012 22:26:06 +0000 Subject: [issue10376] ZipFile unzip is unbuffered In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za> Message-ID: <1336688766.93.0.996437711743.issue10376@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 00:47:57 2012 From: report at bugs.python.org (Thomas Kluyver) Date: Thu, 10 May 2012 22:47:57 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly Message-ID: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> New submission from Thomas Kluyver : With the text 'abc?' copied to the clipboard, on Linux, where UTF-8 is the default encoding: Python 3.2.3 (default, Apr 12 2012, 21:55:50) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import tkinter >>> root = tkinter.Tk() >>> root.clipboard_get() 'abc?\x82?' >>> 'abc?'.encode('utf-8').decode('latin-1') 'abc?\x82?' I see the same behaviour in 2.7.3 as well (it returns a unicode string u'abc\xe2\x82\xac'). If the clipboard is only accessible at a bytes level, I think clipboard_get should return a bytes object. But I can reliably copy and paste non-ascii characters between programs, so it looks like it's possible to return unicode. ---------- components: Tkinter messages: 160378 nosy: takluyver priority: normal severity: normal status: open title: Tkinter clipboard_get() decodes characters incorrectly type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 01:09:13 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 May 2012 23:09:13 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336691353.79.0.880277409662.issue14777@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Still worse. I get 'abc?'. Linux, Python 3.1, 3.2, and 3.3, UTF-8 locale. ---------- nosy: +storchaka versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 01:10:39 2012 From: report at bugs.python.org (Greg Weller) Date: Thu, 10 May 2012 23:10:39 +0000 Subject: [issue14766] Non-naive time comparison throws naive time error In-Reply-To: <1336601470.15.0.633873123281.issue14766@psf.upfronthosting.co.za> Message-ID: <1336691439.51.0.0358287626958.issue14766@psf.upfronthosting.co.za> Greg Weller added the comment: I agree that the language in the quoted paragraph makes it sound as if any object with a non-None tzinfo is aware, which isn't the case. I've changed the first couple sentences to, I think, better reflect what characterizes an object as being aware. ---------- Added file: http://bugs.python.org/file25531/14766.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 01:14:01 2012 From: report at bugs.python.org (Nick Wilson) Date: Thu, 10 May 2012 23:14:01 +0000 Subject: [issue14778] IrrationalVersionError should include the project name Message-ID: <1336691641.31.0.00520688122933.issue14778@psf.upfronthosting.co.za> New submission from Nick Wilson : IrrationalVersionError in packaging/distutils2 should include the name of the project responsible for the error. It currently only includes the version: >>> import packaging.pypi.xmlrpc >>> client = packaging.pypi.xmlrpc.Client() >>> client.search_projects('req') Irrational version error found: 0.0.0-prealpha Irrational version error found: 0.1dev-20110502 ... ---------- assignee: eric.araujo components: Distutils2 messages: 160381 nosy: alexis, eric.araujo, njwilson, tarek priority: normal severity: normal status: open title: IrrationalVersionError should include the project name versions: 3rd party, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 01:20:55 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 10 May 2012 23:20:55 +0000 Subject: [issue14779] test_buffer fails on OS X universal 64-/32-bit builds Message-ID: <1336692055.13.0.571191399969.issue14779@psf.upfronthosting.co.za> New submission from Ned Deily : test_buffer can fail when run on an OS X 64-/32-bit universal build of Python is run in 32-bit mode. $ /usr/local/bin/python3.3 -m test test_buffer [1/1] test_buffer 1 test OK. $ /usr/local/bin/python3.3-32 -m test -v test_buffer == CPython 3.3.0a3 (v3.3.0a3:0b53b70a40a0, May 1 2012, 11:39:35) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] == Darwin-11.4.0-x86_64-i386-64bit little-endian == /private/var/folders/fm/9wjgctqx61n796zt88qmmnxc0000gn/T/test_python_56263 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_buffer [...] test_memoryview_construction (test.test_buffer.TestBufferProtocol) ... FAIL test_ndarray_format_shape (test.test_buffer.TestBufferProtocol) ... FAIL test_ndarray_format_strides (test.test_buffer.TestBufferProtocol) ... FAIL test_ndarray_getbuf (test.test_buffer.TestBufferProtocol) ... FAIL test_ndarray_multidim (test.test_buffer.TestBufferProtocol) ... FAIL test_ndarray_slice_assign_single (test.test_buffer.TestBufferProtocol) ... FAIL [...] The test is incorrectly testing a compile-time configuration variable which is not meaningful for universal builds since each architecture can have different values. Further, the platform.architecture fallback test is also unreliable; as noted in the docs for the platform module, sys.maxsize should be used for run-time tests. The attached patch fixes the test for OS X. ---------- files: issueXXXXX_test_buffer.patch keywords: patch messages: 160382 nosy: ned.deily, skrah priority: normal severity: normal stage: patch review status: open title: test_buffer fails on OS X universal 64-/32-bit builds versions: Python 3.3 Added file: http://bugs.python.org/file25532/issueXXXXX_test_buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 01:40:47 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 10 May 2012 23:40:47 +0000 Subject: [issue14778] IrrationalVersionError should include the project name In-Reply-To: <1336691641.31.0.00520688122933.issue14778@psf.upfronthosting.co.za> Message-ID: <1336693247.36.0.255333324674.issue14778@psf.upfronthosting.co.za> ?ric Araujo added the comment: Setting to easy for the next sprints. To do: add an argument to the IrrationalVersion constructor, add a test to make sure the result of __str__ includes it, and adapt the rest of the codebase to pass the project name when the exception is raised. ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 01:42:05 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 10 May 2012 23:42:05 +0000 Subject: [issue6696] Profile objects should be documented In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za> Message-ID: <1336693325.83.0.110626158795.issue6696@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 01:43:07 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 10 May 2012 23:43:07 +0000 Subject: [issue1508475] transparent gzip compression in urllib Message-ID: <1336693387.97.0.150771148402.issue1508475@psf.upfronthosting.co.za> ?ric Araujo added the comment: Enabled by default with a knob to turn it off sounds good. Maybe the original headers could be preserved in some object. ---------- keywords: -easy, patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 01:43:38 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 10 May 2012 23:43:38 +0000 Subject: [issue14774] _sysconfigdata.py doesn't support multiple build configurations In-Reply-To: <1336679254.12.0.498386228703.issue14774@psf.upfronthosting.co.za> Message-ID: <1336693418.82.0.852492235466.issue14774@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 01:44:18 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 10 May 2012 23:44:18 +0000 Subject: [issue14774] _sysconfigdata.py doesn't support multiple build configurations In-Reply-To: <1336679254.12.0.498386228703.issue14774@psf.upfronthosting.co.za> Message-ID: <1336693458.16.0.680725179084.issue14774@psf.upfronthosting.co.za> ?ric Araujo added the comment: Would always recreating _sysconfigdata.py solve the problem? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 01:45:43 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 10 May 2012 23:45:43 +0000 Subject: [issue14772] Return destination values in some shutil functions In-Reply-To: <1336677987.7.0.16571427099.issue14772@psf.upfronthosting.co.za> Message-ID: <1336693543.18.0.102006523121.issue14772@psf.upfronthosting.co.za> ?ric Araujo added the comment: packaging/distutils2 definitely needs that; the similar functions in distutils.file_util used to return the file paths, this was lost in the conversion to shutil, and there is at least one open bug that needs it back. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 01:48:20 2012 From: report at bugs.python.org (Brian Curtin) Date: Thu, 10 May 2012 23:48:20 +0000 Subject: [issue14772] Return destination values in some shutil functions In-Reply-To: <1336677987.7.0.16571427099.issue14772@psf.upfronthosting.co.za> Message-ID: <1336693700.03.0.746086363592.issue14772@psf.upfronthosting.co.za> Brian Curtin added the comment: When you say "needs that", do you mean the patch as-is, or Hynek's suggestion to return consistently? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 01:49:06 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 10 May 2012 23:49:06 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1336693746.65.0.990292124112.issue14776@psf.upfronthosting.co.za> ?ric Araujo added the comment: I think the doc may be more at home in the Developer?s Guide (like the doc about GDB) rather that the new-user-oriented ?Setup and Usage? doc. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 01:51:17 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 10 May 2012 23:51:17 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1336693877.62.0.449370151905.issue14776@psf.upfronthosting.co.za> ?ric Araujo added the comment: BTW if you don?t get feedback in a week or two you could go to python-dev; if there is no controversy nor implications on third-party code this will likely not require a PEP, only agreement between the core devs. Good luck! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 01:57:10 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 10 May 2012 23:57:10 +0000 Subject: [issue14772] Return destination values in some shutil functions In-Reply-To: <1336677987.7.0.16571427099.issue14772@psf.upfronthosting.co.za> Message-ID: <1336694230.31.0.426264666108.issue14772@psf.upfronthosting.co.za> ?ric Araujo added the comment: I meant that packaging needs some shutil functions to return the destination, but haven?t checked to see if that includes copytree. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 02:06:32 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 May 2012 00:06:32 +0000 Subject: [issue14770] Minor documentation fixes In-Reply-To: <1336647684.02.0.112519558227.issue14770@psf.upfronthosting.co.za> Message-ID: <1336694792.08.0.171455145923.issue14770@psf.upfronthosting.co.za> ?ric Araujo added the comment: A lot of good editions! +``$PATH``:: Would it be worth using :envvar:`PATH` here? Python-specific envvars (e.g. PYTHONPATH) are documented and can be linked to, maybe a small entry to explain common envvars like HOME and PATH would be a useful addition for novice programmers. +module in the :file:`Modules` subdirectory, You can also use :source:`Modules` to generate a link to the repo; for people who don?t know how to get a Python clone or source distribution (or don?t want to), a link is better than just a file name. +When run, this will produce the following output:: Using ?.. code-block:: none? here would avoid misleading colorization. -Thus, to read n bytes from a pipe p created with :func:`os.popen`, you need to +Thus, to read n bytes from a pipe *p* created with :func:`os.popen`, you need to I?d mark up *n* too. +varies between systems; sometimes it is ``/usr/lib/sendmail``, sometimes That?s a program name too, so for consistency you could use :program:, although I?m not sure that role is worth using. +By default :mod:`pickle` uses a relatively old and slow format for backward +compatibility. I trust you will update that comment for the 3.x version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 02:12:14 2012 From: report at bugs.python.org (James Oakley) Date: Fri, 11 May 2012 00:12:14 +0000 Subject: [issue14780] SSL should use OpenSSL-defined default certificate store if ca_certs parameter is omitted Message-ID: <1336695133.95.0.45377603567.issue14780@psf.upfronthosting.co.za> New submission from James Oakley : OpenSSL provides a method, SSL_CTX_set_default_verify_paths(), for loading a default certificate store, which is used by many distributions. In openSUSE, the default store is not a bundle, but a directory-based store, which is not supported at all by the SSL module in Python 2.7. A bug related to this was assigned to me here: https://bugzilla.novell.com/show_bug.cgi?id=761501 I created patches for the Python 2.7.3 and 3.2.3 SSL modules that will load the distribution-specific store if ca_certs is omitted. ---------- components: Library (Lib) files: python-2.7.3-ssl_default_certs.patch keywords: patch messages: 160392 nosy: jfunk priority: normal severity: normal status: open title: SSL should use OpenSSL-defined default certificate store if ca_certs parameter is omitted type: enhancement Added file: http://bugs.python.org/file25533/python-2.7.3-ssl_default_certs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 02:13:13 2012 From: report at bugs.python.org (James Oakley) Date: Fri, 11 May 2012 00:13:13 +0000 Subject: [issue14780] SSL should use OpenSSL-defined default certificate store if ca_certs parameter is omitted In-Reply-To: <1336695133.95.0.45377603567.issue14780@psf.upfronthosting.co.za> Message-ID: <1336695193.19.0.0901142680215.issue14780@psf.upfronthosting.co.za> James Oakley added the comment: Here's the patch for Python 3. ---------- Added file: http://bugs.python.org/file25534/python-3.2.3-ssl_default_certs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 03:02:55 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 11 May 2012 01:02:55 +0000 Subject: [issue14588] PEP 3115 compliant dynamic class creation In-Reply-To: <1334535798.87.0.826104374353.issue14588@psf.upfronthosting.co.za> Message-ID: <1336698175.11.0.873349534992.issue14588@psf.upfronthosting.co.za> Nick Coghlan added the comment: Based on the python-dev thread [1], the proposed name for this API is now "types.new_class()". This parallels the existing imp.new_module() naming scheme and avoids various problems with the idea of using a static method on type itself (descriptors on type behave strangely, and the type namespace is accessible through *all* type objects, which would be weird in this case). Since types is a Python module, we now have to choose between 3 implementation strategies: - reimplement in pure Python (my preferred choice) - implement in terms of __build_class__ (would work, but may not be portable to other implementations and/or serves as a de facto promotion of __build_class__ up to being part of the language specification) - move Daniel's existing operator module based solution over to a new _types C extension module (again, may not help other implementations) The reason I find the idea of a pure Python reimplementation appealing is that it can then serve as a cross-check for any other implementations implementing PEP 3115 for their class statements. [1] http://mail.python.org/pipermail/python-dev/2012-May/119318.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 03:14:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 May 2012 01:14:33 +0000 Subject: [issue14662] shutil.move doesn't handle ENOTSUP raised by chflags on OS X In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e12efebc3ba6 by Ned Deily in branch '2.7': Issue #14662: Prevent shutil failures on OS X when destination does not http://hg.python.org/cpython/rev/e12efebc3ba6 New changeset ae141eebcf96 by Ned Deily in branch '3.2': Issue #14662: Prevent shutil failures on OS X when destination does not http://hg.python.org/cpython/rev/ae141eebcf96 New changeset 93599d5e0a23 by Ned Deily in branch 'default': Issue #14662: Prevent shutil failures on OS X when destination does not http://hg.python.org/cpython/rev/93599d5e0a23 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 03:20:48 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 11 May 2012 01:20:48 +0000 Subject: [issue14662] shutil.move doesn't handle ENOTSUP raised by chflags on OS X In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1336699248.29.0.934362446228.issue14662@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the patch! Tested with an NFS-mounted file system on OS X. Applied for 2.7.4, 3.2.4, and 3.3.0. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 06:42:37 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 May 2012 04:42:37 +0000 Subject: [issue14780] SSL should use OpenSSL-defined default certificate store if ca_certs parameter is omitted In-Reply-To: <1336695133.95.0.45377603567.issue14780@psf.upfronthosting.co.za> Message-ID: <1336711357.56.0.826892796266.issue14780@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, this is basically a change in behaviour, so it could only go in the default branch (3.3). But 3.3 already has SSLContext.set_default_verify_paths(), so it's not obvious why the patch is needed. (furthermore, automatically selecting the system-wide certificates could be surprising. There may be applications where you don't want to trust them.) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 06:44:24 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 May 2012 04:44:24 +0000 Subject: [issue14780] SSL should use OpenSSL-defined default certificate store if ca_certs parameter is omitted In-Reply-To: <1336695133.95.0.45377603567.issue14780@psf.upfronthosting.co.za> Message-ID: <1336711464.06.0.459506113583.issue14780@psf.upfronthosting.co.za> Antoine Pitrou added the comment: By the way, I see that the original bug is against the python-requests library? Perhaps it would be better to advocate the use of load_verify_locations() there, since it's a more adequate place for a policy decision. (that said, Python's own urllib.request could perhaps grow a similar option) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 06:44:47 2012 From: report at bugs.python.org (James Henstridge) Date: Fri, 11 May 2012 04:44:47 +0000 Subject: [issue12029] ABC registration of Exceptions In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336711487.98.0.933182018634.issue12029@psf.upfronthosting.co.za> James Henstridge added the comment: The documentation for ABCMeta.register() says that it makes the other class a "virtual subclass". That would make the ABC a "virtual base class". So whether the current behaviour is correct depends on whether you consider a "virtual base" to count as a base. From the reasoning behind the introduction of ABCs, it certainly sounds like it should count. Also, this is a feature that works correctly in Pyton 2.7, so could trip people up who are trying to move to Python 3. ---------- nosy: +jamesh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 06:53:31 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 May 2012 04:53:31 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1336712011.69.0.21304580621.issue14776@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, at least it looks much cleaner that the dtrace patch. Two comments still: - is pysystemtap.h meant to be a public header? otherwise it should perhaps not end up in Include (I'm not sure what our policy is here) - perhaps get_frame_marker_info() and friends could still be a in separate ceval-systemtap.h file? that way the only added complication in ceval.c would be a couple of includes, and the two `if`s in the eval loop ---------- nosy: +jcea, loewis, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 07:04:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 May 2012 05:04:46 +0000 Subject: [issue14774] _sysconfigdata.py doesn't support multiple build configurations In-Reply-To: <1336679254.12.0.498386228703.issue14774@psf.upfronthosting.co.za> Message-ID: <1336712686.24.0.995361173628.issue14774@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Is there a way of fixing this whilst keeping it a python file? Or do > we need to build from a C file, perhaps? Well I hope we don't make it a C file just for that reason. It would complicate the generation code quite a bit (right now it's just 3 lines long). I tend to use separate clones myself (actually, I use "hg share" to avoid multiple pulls). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 08:19:59 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 11 May 2012 06:19:59 +0000 Subject: [issue4841] io's close() not handling errors correctly In-Reply-To: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za> Message-ID: <1336717199.8.0.403384110413.issue4841@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 10:56:15 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 11 May 2012 08:56:15 +0000 Subject: [issue14779] test_buffer fails on OS X universal 64-/32-bit builds In-Reply-To: <1336692055.13.0.571191399969.issue14779@psf.upfronthosting.co.za> Message-ID: <1336726575.76.0.996392053534.issue14779@psf.upfronthosting.co.za> Stefan Krah added the comment: The sysconfig docs say: "configuration variables relevant for the current platform" If get_config_var('SIZEOF_VOID_P') is meaningless for universal builds, then IMO it should return None. None would then mean either "not found" or "irrelevant". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 11:00:36 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 11 May 2012 09:00:36 +0000 Subject: [issue14743] on terminating, Pdb debugs itself In-Reply-To: <1336420111.44.0.550150061213.issue14743@psf.upfronthosting.co.za> Message-ID: <1336726836.83.0.687440308356.issue14743@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The previous patch only fixed the problem when the debugger is started from its main function. Uploaded new patch pdb_botframe_default_3.patch that fixes pdb.main and the pdb.run* function. This patch also corrects pdb.runcall(): in the following session, the 3.1 debugger starts the debugging session at the second line of foo() and not at the --Call-- event. A test case for this problem is also included in the patch. === main.py ================================= import pdb, sys print(sys.version) def foo(): pass pdb.runcall(foo) ================================================= $ python3.1 main.py 3.1.2 (r312:79147, Apr 4 2010, 17:46:48) [GCC 4.3.2] > /path_to/main.py(5)foo() -> pass (Pdb) quit ================================================= ---------- Added file: http://bugs.python.org/file25535/pdb_botframe_default_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 12:54:35 2012 From: report at bugs.python.org (Matthias Meyer) Date: Fri, 11 May 2012 10:54:35 +0000 Subject: [issue14781] strptime fails for year 0 Message-ID: <1336733675.67.0.302475509156.issue14781@psf.upfronthosting.co.za> New submission from Matthias Meyer : Hi folks, What I did: import time time.strptime('0000-10-03T15:35:05Z','%Y-%m-%dT%H:%M:%SZ') What I expected: time.struct_time(tm_year=0, tm_mon=10, tm_mday=3, tm_hour=15, tm_min=35, tm_sec=5, tm_wday=2, tm_yday=276, tm_isdst=-1) What I got: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/_strptime.py", line 454, in _strptime_time return _strptime(data_string, format)[0] File "/usr/lib/python2.7/_strptime.py", line 440, in _strptime datetime_date(year, 1, 1).toordinal() + 1 ValueError: year is out of range Environment: Ubuntu 12.04 x64 python --version: 2.7.3 If you need more information, please let me know... ---------- components: Library (Lib) messages: 160404 nosy: Matthias.Meyer priority: normal severity: normal status: open title: strptime fails for year 0 type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 13:20:15 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 May 2012 11:20:15 +0000 Subject: [issue14779] test_buffer fails on OS X universal 64-/32-bit builds In-Reply-To: <1336692055.13.0.571191399969.issue14779@psf.upfronthosting.co.za> Message-ID: <1336735215.83.0.012358676969.issue14779@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, no need to ever use SIZEOF_VOID_P. sys.maxsize should always tell you whether the build is 32-bit or 64-bit. ---------- nosy: +mark.dickinson, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 13:20:34 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 11 May 2012 11:20:34 +0000 Subject: [issue14781] strptime fails for year 0 In-Reply-To: <1336733675.67.0.302475509156.issue14781@psf.upfronthosting.co.za> Message-ID: <1336735234.09.0.481111972757.issue14781@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Hello Matthias, %Y for strptime is defined as: "Year with century as a decimal number [0001,9999] (strptime), [?]" so it works as specified. And actually that's correct as there was no year zero (http://en.wikipedia.org/wiki/0_(year)). :) ---------- nosy: +hynek resolution: -> invalid _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 13:29:15 2012 From: report at bugs.python.org (Matthias Meyer) Date: Fri, 11 May 2012 11:29:15 +0000 Subject: [issue14781] strptime fails for year 0 In-Reply-To: <1336733675.67.0.302475509156.issue14781@psf.upfronthosting.co.za> Message-ID: <1336735755.73.0.119721997765.issue14781@psf.upfronthosting.co.za> Matthias Meyer added the comment: but ISO 8601 specifies year 0 to be identical with 1 BC. Shouldn't it default to that, then? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 13:31:55 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 May 2012 11:31:55 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336735915.54.0.65083762222.issue12029@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- title: ABC registration of Exceptions -> Catching virtual subclasses in except clauses versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 13:40:54 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 May 2012 11:40:54 +0000 Subject: [issue14772] Return destination values in some shutil functions In-Reply-To: <1336677987.7.0.16571427099.issue14772@psf.upfronthosting.co.za> Message-ID: <1336736454.62.0.324562309853.issue14772@psf.upfronthosting.co.za> ?ric Araujo added the comment: In distutils, both copy_file and copy_tree return the destination path(s), which is needed by many commands. In packaging there is code to compute and return those paths, as shutil functions return None; I?d love to remove that code. The bug I was thinking about is actually about copy(_)file parameters, not return value: #13336. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 13:41:51 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 May 2012 11:41:51 +0000 Subject: [issue14588] PEP 3115 compliant dynamic class creation In-Reply-To: <1334535798.87.0.826104374353.issue14588@psf.upfronthosting.co.za> Message-ID: <1336736511.4.0.162933110449.issue14588@psf.upfronthosting.co.za> ?ric Araujo added the comment: Implementing in pure Python seems to have a lot of pros and no con to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 13:52:24 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 11 May 2012 11:52:24 +0000 Subject: [issue14781] Default to year 1 in strptime if year 0 has been specified In-Reply-To: <1336733675.67.0.302475509156.issue14781@psf.upfronthosting.co.za> Message-ID: <1336737144.8.0.91083963249.issue14781@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Well, that's what C's strptime does. But that would be a feature request (if it works as documented, it's no bug). :) I've transformed this issue accordingly. But as a feature request, it won't go into 2.7 unless I'm missing something. ---------- nosy: +belopolsky, benjamin.peterson, lemburg priority: normal -> low resolution: invalid -> stage: -> needs patch title: strptime fails for year 0 -> Default to year 1 in strptime if year 0 has been specified type: crash -> enhancement versions: +Python 3.2, Python 3.3 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 14:16:03 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 11 May 2012 12:16:03 +0000 Subject: [issue14781] Default to year 1 in strptime if year 0 has been specified In-Reply-To: <1336733675.67.0.302475509156.issue14781@psf.upfronthosting.co.za> Message-ID: <1336738563.99.0.836070035888.issue14781@psf.upfronthosting.co.za> Hynek Schlawack added the comment: I have to correct myself: It's _not_ what C's strptime does. C's strptime returns via "struct tm" which saves only "years since 1900" in the "tm_year" field. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 14:16:26 2012 From: report at bugs.python.org (w.pettersson) Date: Fri, 11 May 2012 12:16:26 +0000 Subject: [issue14782] Tabcompletion of classes with static methods and __call__ has extra bracket Message-ID: <1336738586.42.0.602618902889.issue14782@psf.upfronthosting.co.za> New submission from w.pettersson : With tab completion enabled via rlcompleter and readline, tab-completion will assume anything that is callable (by callable(val)) is going to be called. For example, the below code defines a class "CCC" that is callable and has a static function. However, typing >>> CC and then pressing tab results in the following. >>> CCC( Note the extra parentheses. It would be nice if these weren't added if the object also has some other reasonable choices. However, I don't know what would be "reasonable" here. Somehow we'd have to detect whether a callable class has static methods, possibly via dir() or directly checking class.__dict__ but at this point I am not comfortable enough with python to suggest decent solutions. >>> class CCC: ... def __call__(self): ... print "call" ... @staticmethod ... def f(a): ... print "Static",a ... >>>CC >>>CCC( ---------- components: Library (Lib) messages: 160412 nosy: wpettersson priority: normal severity: normal status: open title: Tabcompletion of classes with static methods and __call__ has extra bracket type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 14:39:23 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 11 May 2012 12:39:23 +0000 Subject: [issue14779] test_buffer fails on OS X universal 64-/32-bit builds In-Reply-To: <1336735215.83.0.012358676969.issue14779@psf.upfronthosting.co.za> Message-ID: <20120511123922.GA13478@sleipnir.bytereef.org> Stefan Krah added the comment: The tests for arrays with suboffsets literally need sizeof(void *). I don't think C guarantees SIZEOF_VOID_P == SIZEOF_SIZE_T. If HAVE_SSIZE_T is defined in pyport.h, AFAICS no such check is made. Of course these concerns may be entirely theoretical. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 16:55:00 2012 From: report at bugs.python.org (Mark Wielaard) Date: Fri, 11 May 2012 14:55:00 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1336748100.85.0.289227269782.issue14776@psf.upfronthosting.co.za> Changes by Mark Wielaard : ---------- nosy: +mjw _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 17:02:35 2012 From: report at bugs.python.org (Mark Wielaard) Date: Fri, 11 May 2012 15:02:35 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1336748555.8.0.415719026418.issue14776@psf.upfronthosting.co.za> Mark Wielaard added the comment: Just a comment that newer [eu]-readelf -n will provide a nicer view of the sdt ELF notes. You might want to suggest that in the documentation. e.g. $ eu-readelf -n /usr/lib64/libpython2.7.so Note section [ 1] '.note.gnu.build-id' of 36 bytes at offset 0x190: Owner Data size Type GNU 20 GNU_BUILD_ID Build ID: a28f8db1b224530b0d38ad7b82a249cf7c3f18d6 Note section [27] '.note.stapsdt' of 184 bytes at offset 0x1ae884: Owner Data size Type stapsdt 70 Version: 3 PC: 0xe0d3a, Base: 0x14b150, Semaphore: 0x3ae882 Provider: python, Name: function__return, Args: '8@%rbx 8@%r13 -4@%eax' stapsdt 69 Version: 3 PC: 0xe0f37, Base: 0x14b150, Semaphore: 0x3ae880 Provider: python, Name: function__entry, Args: '8@%rbx 8@%r13 -4@%eax' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 17:12:17 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 May 2012 15:12:17 +0000 Subject: [issue14764] importlib.test.benchmark broken In-Reply-To: <1336565393.03.0.0926288176672.issue14764@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e1d0535372d0 by Brett Cannon in branch 'default': Issue #14764: Update importlib.test.benchmark to work in a world where http://hg.python.org/cpython/rev/e1d0535372d0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 17:12:41 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 May 2012 15:12:41 +0000 Subject: [issue14764] importlib.test.benchmark broken In-Reply-To: <1336565393.03.0.0926288176672.issue14764@psf.upfronthosting.co.za> Message-ID: <1336749161.14.0.215202597404.issue14764@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 17:50:13 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 May 2012 15:50:13 +0000 Subject: [issue14783] Update int() docstring from manual Message-ID: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za> New submission from Terry J. Reedy : int.__doc__ starts "int(x[, base]) -> integer". That is not exactly correct as x is not required and base is only allowed if x is a string. The 3.3 manual fixes both problems with "int([number | string[, base]])" I actually think the rest of the docstring might be replaced with the more accurate and informative manual entry. It might be condensed, but I am not sure what might be omitted. ---------- keywords: easy messages: 160416 nosy: terry.reedy priority: low severity: normal status: open title: Update int() docstring from manual versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 18:26:08 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 May 2012 16:26:08 +0000 Subject: [issue14728] trace function not set, causing some Pdb commands to fail In-Reply-To: <1336214625.48.0.950841547459.issue14728@psf.upfronthosting.co.za> Message-ID: <1336753568.8.0.971994008833.issue14728@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since this pdb issue is a continuation of #13183 and repeals a part of that issue's patch, I nosy'ed the contributors to that issue. ---------- nosy: +georg.brandl, loewis, neologix, orsenthil, terry.reedy stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 18:37:40 2012 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 11 May 2012 16:37:40 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336754260.69.0.631822965906.issue12029@psf.upfronthosting.co.za> Guido van Rossum added the comment: I agree it's a bug and should be fixed. It's too confusing that there would be two slightly different interpretations of isinstance/issubclass where the isinstance() and issubclass() would be using the extended interpretation but the except clause would use the narrow interpretation. The exception matching done by the except clause ought to be explainable in terms of issubclass/isinstance. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 18:39:00 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 May 2012 16:39:00 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336754340.94.0.806161035344.issue14777@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 3.3, Win 7, Idle >>> root.clipboard_get() 'abc?' after cut from here ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 18:41:10 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 May 2012 16:41:10 +0000 Subject: [issue14782] Tab-completion of classes displays opening paren In-Reply-To: <1336738586.42.0.602618902889.issue14782@psf.upfronthosting.co.za> Message-ID: <1336754470.24.0.236538289071.issue14782@psf.upfronthosting.co.za> ?ric Araujo added the comment: This annoys me too, for all callable objects actually (e.g. I type "help(someprefix" then Tab then I have to delete the "(" before typing ")" and Enter), but I think it was a deliberate change. I may have the original bug report open in a browser tab at home, I?ll check. ---------- nosy: +eric.araujo title: Tabcompletion of classes with static methods and __call__ has extra bracket -> Tab-completion of classes displays opening paren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 18:41:32 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 May 2012 16:41:32 +0000 Subject: [issue14782] Tab-completion of callables displays opening paren In-Reply-To: <1336738586.42.0.602618902889.issue14782@psf.upfronthosting.co.za> Message-ID: <1336754492.69.0.725351283404.issue14782@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- title: Tab-completion of classes displays opening paren -> Tab-completion of callables displays opening paren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 18:42:00 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 May 2012 16:42:00 +0000 Subject: [issue14781] Default to year 1 in strptime if year 0 has been specified In-Reply-To: <1336733675.67.0.302475509156.issue14781@psf.upfronthosting.co.za> Message-ID: <1336754520.5.0.903234336208.issue14781@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 18:42:02 2012 From: report at bugs.python.org (James Oakley) Date: Fri, 11 May 2012 16:42:02 +0000 Subject: [issue14780] SSL should use OpenSSL-defined default certificate store if ca_certs parameter is omitted In-Reply-To: <1336695133.95.0.45377603567.issue14780@psf.upfronthosting.co.za> Message-ID: <1336754522.08.0.366861253058.issue14780@psf.upfronthosting.co.za> James Oakley added the comment: load_verify_locations() is not available in Python 2.x. It was added in 3.x. Also, there is no way to load a directory-based certificate store at all in Python 2.x, which is why the bug was opened. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 18:44:04 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 May 2012 16:44:04 +0000 Subject: [issue14780] SSL should use OpenSSL-defined default certificate store if ca_certs parameter is omitted In-Reply-To: <1336695133.95.0.45377603567.issue14780@psf.upfronthosting.co.za> Message-ID: <1336754644.71.0.849706869262.issue14780@psf.upfronthosting.co.za> ?ric Araujo added the comment: Sorry, by our policy this change is a new feature and cannot go into stable versions. ---------- nosy: +eric.araujo versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 18:44:47 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 May 2012 16:44:47 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336754687.14.0.705152395247.issue12029@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- stage: -> needs patch versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 18:55:25 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 May 2012 16:55:25 +0000 Subject: [issue14732] PEP 3121 Refactoring applied to _csv module In-Reply-To: <1336247238.98.0.79082288942.issue14732@psf.upfronthosting.co.za> Message-ID: <1336755325.4.0.499687827338.issue14732@psf.upfronthosting.co.za> ?ric Araujo added the comment: Skip: I used the nosy field autocomplete which is based on the experts file in the devguide; I can mark you "retired" in that file so that your name does not show up in autocomplete (but humans will still know that you might be contacted when all else fails, unless you prefer your name to be fully removed). ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 18:57:39 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 May 2012 16:57:39 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336755459.24.0.98812505663.issue12029@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson type: behavior -> enhancement versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 18:59:02 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 May 2012 16:59:02 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b81ddaf0db47 by Brett Cannon in branch 'default': Issue #13959: Deprecate imp.get_suffixes() for new attributes on http://hg.python.org/cpython/rev/b81ddaf0db47 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 19:03:36 2012 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 11 May 2012 17:03:36 +0000 Subject: [issue14732] PEP 3121 Refactoring applied to _csv module In-Reply-To: <1336755325.4.0.499687827338.issue14732@psf.upfronthosting.co.za> Message-ID: Skip Montanaro added the comment: > Skip: I used the nosy field autocomplete which is based on the experts file in the devguide; I can mark you "retired" in that file so that your name does not show up in autocomplete (but humans will still know that you might be contacted when all else fails, unless you prefer your name to be fully removed). Thanks. That would be great. I don't mind the occasional question, but don't want people thinking I am going to jump in feet first any time I'm made nosy on a ticket. S ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 19:04:53 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 11 May 2012 17:04:53 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336755893.14.0.697731292877.issue12029@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think being able to catch exception with ABCs is esssentially useless. The originally stated "usecase" can be simply solved by putting classes into a tuple and putting that in the except clause. In general, the whole abc machinary causes lots of code which expects instance and subclass checks to be side-effect free to be able to execute arbitrary code, which creates messes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 19:09:00 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 May 2012 17:09:00 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336756140.57.0.116231246477.issue12029@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Perhaps ABCMeta could raise a UserWarning when creating an Exception subclass? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 19:20:32 2012 From: report at bugs.python.org (andrew cooke) Date: Fri, 11 May 2012 17:20:32 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336756832.49.0.38523105993.issue12029@psf.upfronthosting.co.za> andrew cooke added the comment: perhaps it could just work in a simple, consistent way? in my original report i wondered whether there was a significant performance hit. but so far the objections against fixing this seem to be (1) a lawyer could be convinced the current behaviour is consistent with the docs (2) python 3 should remain compatible with python 2 (3) abcmeta is the sucksorz. those don't seem like great arguments against making it just work right, to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 19:22:13 2012 From: report at bugs.python.org (andrew cooke) Date: Fri, 11 May 2012 17:22:13 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336756933.6.0.921563767727.issue12029@psf.upfronthosting.co.za> Changes by andrew cooke : ---------- nosy: -acooke _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 19:24:01 2012 From: report at bugs.python.org (James Oakley) Date: Fri, 11 May 2012 17:24:01 +0000 Subject: [issue14780] SSL should use OpenSSL-defined default certificate store if ca_certs parameter is omitted In-Reply-To: <1336695133.95.0.45377603567.issue14780@psf.upfronthosting.co.za> Message-ID: <1336757041.54.0.288915480722.issue14780@psf.upfronthosting.co.za> James Oakley added the comment: Fair enough. What about a patch to handle a directory store passed through the ca_certs parameter? As it stands now, it's impossible to load the distribution-supplied cert store on openSUSE. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 19:32:28 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 May 2012 17:32:28 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336757548.94.0.37818027473.issue12029@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > perhaps it could just work in a simple, consistent way? That would be best obviously. But as Benjamin explained it's quite delicate to make it work while avoiding pitfalls where code involved in exception checking may itself fail with arbitrary errors - say, enter an infinite recursion. It's also why I think it would be a bad idea to fix it in 3.2 (the bugfix branch). In 3.3 we can take riskier decisions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 19:34:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 May 2012 17:34:03 +0000 Subject: [issue14780] SSL should use OpenSSL-defined default certificate store if ca_certs parameter is omitted In-Reply-To: <1336695133.95.0.45377603567.issue14780@psf.upfronthosting.co.za> Message-ID: <1336757643.07.0.859542986352.issue14780@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > What about a patch to handle a directory store passed through the > ca_certs parameter? As it stands now, it's impossible to load the > distribution-supplied cert store on openSUSE. I'm afraid it would still be a new feature, unsuitable for a bugfix release. Other distros simply have both a directory-based cert store and a cert bundle. In Mageia I see both /etc/pki/tls/rootcerts/ (a directory-based cert store) and /etc/pki/tls/certs/ca-bundle.crt (a single file cert bundle). (yes, I hope they're synchronized :)) Generally, the only reason we would add a new feature in a bugfix release is if it's necessary to fix a security issue (such as the hash randomization feature). Here it's not necessary: you could simply ship a cert bundle in addition to the cert store. I suppose its generation is easily automated with a script. (and, yes, the ssl module has long lacked important features; its history is a bit bumpy) Again, for 3.3, a patch allowing urllib.request to call load_default_verify_locations() could be a good idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 19:37:21 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 11 May 2012 17:37:21 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336757841.02.0.237716039686.issue12029@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Basically, someone needs to produce a patch and we can go from there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 19:41:24 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 11 May 2012 17:41:24 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1336758084.54.0.838310308028.issue13959@psf.upfronthosting.co.za> Eric Snow added the comment: Question on this one: @@ -126,7 +131,7 @@ def load_compiled(name, pathname, file=N # XXX deprecate def load_package(name, path): if os.path.isdir(path): - extensions = _bootstrap._SOURCE_SUFFIXES + [_bootstrap._BYTECODE_SUFFIX] + extensions = machinery.SOURCE_SUFFIXES[:] + [machinery.BYTECODE_SUFFIXES] for extension in extensions: path = os.path.join(path, '__init__'+extension) if os.path.exists(path): Should that be the following? extensions = machinery.SOURCE_SUFFIXES[:] + machinery.BYTECODE_SUFFIXES[:] Also, why the "[:]"? Finally, in a couple spots you use the first element of the list (like the old case of "machinery.SOURCE_SUFFIXES[0]" in source_from_cache() and the new one in find_module()). Will this be a problem where the source file has one of the other suffixes? I'm not sure it's a big enough deal for the moment to worry about, but thought I'd ask. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 19:42:10 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 11 May 2012 17:42:10 +0000 Subject: [issue14783] Update int() docstring from manual In-Reply-To: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za> Message-ID: <1336758130.73.0.694438118737.issue14783@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 19:47:50 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 May 2012 17:47:50 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1336758470.43.0.10659815959.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: Yes. And the [:] copies the list so I don't accidentally mutate in-place (did that once already, so now I'm just being paranoid; I doubt I need it hardly anywhere I don't do +=). As for using SOURCE_SUFFIXES[0], I'm done following the ported code. I really don't care if .pyw isn't supported in that case. But in general people shouldn't assume just .py (or .py at all). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 19:47:58 2012 From: report at bugs.python.org (=?utf-8?q?George-Cristian_B=C3=AErzan?=) Date: Fri, 11 May 2012 17:47:58 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336758478.15.0.624242902023.issue12029@psf.upfronthosting.co.za> George-Cristian B?rzan added the comment: I posted on python dev that this would slow exception checking considerably so that is a concern. As for possible bugs, this has been working in the 2 branch for a while now, so I don't think that is the biggest issue. As for possible use cases, writing a wrapper around backend, each with its own exceptions and still being able to catch a 'base' exception in your code while still having the ability to catch specific exceptions, without doing awkward stuff like looking at __cause__ (let alone that you have to reraise that in 2 for code that has to run on both branches). Yes, you could patch the exceptions' bases but that is what Abc was created to avoid. Sorry for the mistakes and weird phrasing, posting this off my phone. ---------- nosy: +gcbirzan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 19:49:48 2012 From: report at bugs.python.org (=?utf-8?q?George-Cristian_B=C3=AErzan?=) Date: Fri, 11 May 2012 17:49:48 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336758588.96.0.459700325443.issue12029@psf.upfronthosting.co.za> George-Cristian B?rzan added the comment: I have a patch, with tests, but no Internet on my computer so going out, will post it when I get back/my Internet comes back ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 20:06:26 2012 From: report at bugs.python.org (James Oakley) Date: Fri, 11 May 2012 18:06:26 +0000 Subject: [issue14780] SSL should use OpenSSL-defined default certificate store if ca_certs parameter is omitted In-Reply-To: <1336695133.95.0.45377603567.issue14780@psf.upfronthosting.co.za> Message-ID: <1336759586.44.0.817991229384.issue14780@psf.upfronthosting.co.za> James Oakley added the comment: Something like this perhaps? --- a/Lib/urllib/request.py Fri May 11 13:11:02 2012 -0400 +++ b/Lib/urllib/request.py Fri May 11 11:03:02 2012 -0700 @@ -135,16 +135,19 @@ _opener = None def urlopen(url, data=None, timeout=socket._GLOBAL_DEFAULT_TIMEOUT, - *, cafile=None, capath=None): + *, cafile=None, capath=None, cadefault=True): global _opener if cafile or capath: if not _have_ssl: raise ValueError('SSL support not available') context = ssl.SSLContext(ssl.PROTOCOL_SSLv23) context.options |= ssl.OP_NO_SSLv2 - if cafile or capath: + if cafile or capath or cadefault: context.verify_mode = ssl.CERT_REQUIRED - context.load_verify_locations(cafile, capath) + if cafile or capath: + context.load_verify_locations(cafile, capath) + else: + context.load_default_verify_locations() check_hostname = True else: check_hostname = False ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 20:41:50 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 May 2012 18:41:50 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336761710.48.0.840821948421.issue14777@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This issue can be reproduced by pure Tcl/Tk: $ wish % clipboard get abc? % clipboard get -type STRING abc? % clipboard get -type UTF8_STRING abc? Use `root.clipboard_get(type='UTF8_STRING')` in Python. I don't know whether it should just be documented (UTF8_STRING is not even mentioned in the clipboard_get docstring), or do we need to change the default behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 20:48:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 May 2012 18:48:50 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 626d5c6fbd95 by Brett Cannon in branch 'default': Issue #13959: Have http://hg.python.org/cpython/rev/626d5c6fbd95 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 21:09:54 2012 From: report at bugs.python.org (Thomas Kluyver) Date: Fri, 11 May 2012 19:09:54 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336763394.06.0.21628104101.issue14777@psf.upfronthosting.co.za> Thomas Kluyver added the comment: On this computer, I see this from Tcl: $ wish % clipboard get abc\u20ac But here Python's following suit: >>> root.clipboard_get() 'abc\\u20ac' Which is odd, because as far as I know, my two computers run the same OS (Ubuntu 12.04) in the same configuration. I briefly thought the presence of xsel might be affecting it, but uninstalling it doesn't seem to make any difference. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 21:24:14 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 11 May 2012 19:24:14 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336764254.66.0.383943257034.issue14777@psf.upfronthosting.co.za> Ned Deily added the comment: As is often the case with Tcl/Tk issues, there are platform differences. On OS X, with the two native Tcl/Tk implementations (Aqua Cocoa and Aqua Carbon), the examples work appear to work as is *and* type "UTF8_STRING" does not exist. The less commonly used X11 Tcl/Tk on OS X does support and require "UTF8_STRING" for the example given. So any doc change needs to be carefully worded. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 21:24:30 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 May 2012 19:24:30 +0000 Subject: [issue14624] Faster utf-16 decoder In-Reply-To: <1334869141.17.0.802149162715.issue14624@psf.upfronthosting.co.za> Message-ID: <1336764270.79.0.758001162168.issue14624@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch updated to stylistic conformity of the UTF-8 decoder. The decoding of the UCS2 non-surrogate characters a little speed up (+15%). ---------- Added file: http://bugs.python.org/file25536/decode_utf16_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 21:24:55 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 May 2012 19:24:55 +0000 Subject: [issue14625] Faster utf-32 decoder In-Reply-To: <1334869197.32.0.159275934867.issue14625@psf.upfronthosting.co.za> Message-ID: <1336764295.4.0.606718043314.issue14625@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patches updated to stylistic conformity of the UTF-8 decoder. Patch B is significantly accelerated for aligned input data (i. e. almost always), especially for natural order. The UTF-32 decoder can now be faster than ASCII decoder! May be it is time to change the title to "Amazingly faster UTF-32 decoding"? ;) Py3.2 Py3.3 patchA patchB utf-32le 'A'*10000 162 (+462%) 100 (+810%) 391 (+133%) 910 utf-32le 'A'*9999+'\x80' 162 (+411%) 99 (+736%) 377 (+120%) 828 utf-32le 'A'*9999+'\u0100' 162 (+277%) 95 (+543%) 324 (+89%) 611 utf-32le 'A'*9999+'\u8000' 162 (+278%) 95 (+545%) 324 (+89%) 613 utf-32le 'A'*9999+'\U00010000' 162 (+280%) 95 (+547%) 322 (+91%) 615 utf-32le '\x80'*10000 162 (+436%) 94 (+823%) 389 (+123%) 868 utf-32le '\x80'+'A'*9999 162 (+441%) 94 (+832%) 388 (+126%) 876 utf-32le '\x80'*9999+'\u0100' 162 (+273%) 90 (+571%) 320 (+89%) 604 utf-32le '\x80'*9999+'\u8000' 162 (+271%) 90 (+568%) 319 (+88%) 601 utf-32le '\x80'*9999+'\U00010000' 162 (+268%) 90 (+562%) 318 (+87%) 596 utf-32le '\u0100'*10000 161 (+445%) 83 (+958%) 405 (+117%) 878 utf-32le '\u0100'+'A'*9999 162 (+440%) 83 (+954%) 403 (+117%) 875 utf-32le '\u0100'+'\x80'*9999 162 (+444%) 83 (+963%) 403 (+119%) 882 utf-32le '\u0100'*9999+'\u8000' 162 (+441%) 83 (+955%) 404 (+117%) 876 utf-32le '\u0100'*9999+'\U00010000' 162 (+259%) 79 (+637%) 325 (+79%) 582 utf-32le '\u8000'*10000 162 (+441%) 83 (+955%) 404 (+117%) 876 utf-32le '\u8000'+'A'*9999 162 (+441%) 83 (+955%) 404 (+117%) 876 utf-32le '\u8000'+'\x80'*9999 161 (+448%) 83 (+964%) 403 (+119%) 883 utf-32le '\u8000'+'\u0100'*9999 161 (+443%) 83 (+954%) 402 (+118%) 875 utf-32le '\u8000'*9999+'\U00010000' 162 (+262%) 79 (+643%) 325 (+81%) 587 utf-32le '\U00010000'*10000 149 (+483%) 83 (+947%) 390 (+123%) 869 utf-32le '\U00010000'+'A'*9999 162 (+444%) 83 (+963%) 389 (+127%) 882 utf-32le '\U00010000'+'\x80'*9999 162 (+430%) 83 (+935%) 389 (+121%) 859 utf-32le '\U00010000'+'\u0100'*9999 162 (+429%) 83 (+933%) 389 (+120%) 857 utf-32le '\U00010000'+'\u8000'*9999 162 (+431%) 83 (+937%) 388 (+122%) 861 utf-32be 'A'*10000 162 (+199%) 100 (+384%) 393 (+23%) 484 utf-32be 'A'*9999+'\x80' 162 (+186%) 99 (+368%) 376 (+23%) 463 utf-32be 'A'*9999+'\u0100' 162 (+138%) 95 (+306%) 323 (+20%) 386 utf-32be 'A'*9999+'\u8000' 162 (+139%) 95 (+307%) 323 (+20%) 387 utf-32be 'A'*9999+'\U00010000' 162 (+138%) 95 (+305%) 322 (+20%) 385 utf-32be '\x80'*10000 161 (+196%) 94 (+407%) 389 (+23%) 477 utf-32be '\x80'+'A'*9999 161 (+197%) 94 (+409%) 387 (+24%) 478 utf-32be '\x80'*9999+'\u0100' 161 (+137%) 90 (+324%) 321 (+19%) 382 utf-32be '\x80'*9999+'\u8000' 162 (+135%) 89 (+328%) 320 (+19%) 381 utf-32be '\x80'*9999+'\U00010000' 162 (+134%) 89 (+326%) 318 (+19%) 379 utf-32be '\u0100'*10000 161 (+196%) 83 (+473%) 404 (+18%) 476 utf-32be '\u0100'+'A'*9999 161 (+196%) 83 (+475%) 402 (+19%) 477 utf-32be '\u0100'+'\x80'*9999 162 (+196%) 83 (+477%) 403 (+19%) 479 utf-32be '\u0100'*9999+'\u8000' 161 (+196%) 83 (+473%) 404 (+18%) 476 utf-32be '\u0100'*9999+'\U00010000' 162 (+131%) 79 (+373%) 325 (+15%) 374 utf-32be '\u8000'*10000 161 (+195%) 83 (+472%) 404 (+18%) 475 utf-32be '\u8000'+'A'*9999 161 (+197%) 83 (+476%) 402 (+19%) 478 utf-32be '\u8000'+'\x80'*9999 161 (+197%) 83 (+476%) 403 (+19%) 478 utf-32be '\u8000'+'\u0100'*9999 162 (+194%) 83 (+473%) 403 (+18%) 476 utf-32be '\u8000'*9999+'\U00010000' 161 (+133%) 79 (+375%) 325 (+15%) 375 utf-32be '\U00010000'*10000 148 (+222%) 83 (+473%) 391 (+22%) 476 utf-32be '\U00010000'+'A'*9999 161 (+198%) 83 (+477%) 389 (+23%) 479 utf-32be '\U00010000'+'\x80'*9999 162 (+194%) 83 (+473%) 389 (+22%) 476 utf-32be '\U00010000'+'\u0100'*9999 162 (+194%) 83 (+475%) 389 (+23%) 477 utf-32be '\U00010000'+'\u8000'*9999 161 (+196%) 83 (+475%) 389 (+23%) 477 ---------- Added file: http://bugs.python.org/file25537/decode_utf32_a_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 21:25:28 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 May 2012 19:25:28 +0000 Subject: [issue14625] Faster utf-32 decoder In-Reply-To: <1334869197.32.0.159275934867.issue14625@psf.upfronthosting.co.za> Message-ID: <1336764328.4.0.267229302508.issue14625@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file25538/decode_utf32_b_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 21:31:33 2012 From: report at bugs.python.org (Thomas Kluyver) Date: Fri, 11 May 2012 19:31:33 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336764693.43.0.999857931154.issue14777@psf.upfronthosting.co.za> Thomas Kluyver added the comment: OK, after a quick bit of reading, I see why I'm confused: the clipboard actually works by requesting the text from the source program, so where you copy it from makes a difference. In my case, copying from firefox gives 'abc\\u20ac', and copying from Geany gives u'abc\xe2\x82\xac'. However, I still think there's something that can be improved in Python. As Serhiy points out, specifying type='UTF8_STRING' makes it work properly from both programs. The Tcl documentation recommends this as the best option for "modern X11 systems"[1]. >From what Ned says, we can't make UTF8_STRING the default everywhere, but is there a way to detect if we're inside X11, and use UTF8_STRING by default there? [1] http://www.tcl.tk/man/tcl/TkCmd/clipboard.htm ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 21:31:57 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 May 2012 19:31:57 +0000 Subject: [issue14419] Faster ascii decoding In-Reply-To: <1332795378.48.0.327832712874.issue14419@psf.upfronthosting.co.za> Message-ID: <1336764717.86.0.41792005131.issue14419@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Since the patch commited as part of new UTF-8 decoder, this issue can be closed (issue14738). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 21:40:16 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 May 2012 19:40:16 +0000 Subject: [issue14784] Re-importing _warnings changes warnings.filters Message-ID: <1336765216.03.0.0611996113989.issue14784@psf.upfronthosting.co.za> New submission from Brett Cannon : If you run test.test_warnings it reports that warnings.filters changed. If you comment out the import of c_warnings in that module, the warning goes away (this happens with running on tests). It looks like _PyWarnings_Init() itself doesn't trigger a reprocessing of the sys.warnoptions as an import of warnings.py does, and thus the change in warnings.filter. ---------- components: Library (Lib) messages: 160446 nosy: brett.cannon priority: low severity: normal stage: test needed status: open title: Re-importing _warnings changes warnings.filters type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 21:45:44 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 May 2012 19:45:44 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding In-Reply-To: <1336327254.8.0.865225437508.issue14738@psf.upfronthosting.co.za> Message-ID: <1336765544.62.0.241618712685.issue14738@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Martin for review, which has allowed me to make a quality patch, and for promotion of further research. Thanks Antoine for review, benchmarks, commit, and for the original optimization, which served as the basis for my patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 21:46:24 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 May 2012 19:46:24 +0000 Subject: [issue14624] Faster utf-16 decoder In-Reply-To: <1334869141.17.0.802149162715.issue14624@psf.upfronthosting.co.za> Message-ID: <1336765584.25.0.437102177108.issue14624@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Unicode nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 21:46:42 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 May 2012 19:46:42 +0000 Subject: [issue14625] Faster utf-32 decoder In-Reply-To: <1334869197.32.0.159275934867.issue14625@psf.upfronthosting.co.za> Message-ID: <1336765602.96.0.163587473909.issue14625@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Unicode nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 22:17:09 2012 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 11 May 2012 20:17:09 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336767429.78.0.472444167082.issue12029@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +Yury.Selivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 22:49:55 2012 From: report at bugs.python.org (Dave Malcolm) Date: Fri, 11 May 2012 20:49:55 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1336769395.48.0.610481572826.issue14776@psf.upfronthosting.co.za> Dave Malcolm added the comment: Thanks Eric, Antoine and Mark. I'm attaching two new patches: a replacement patch for cpython, and a new patch for the devguide I've moved the docs to the dev guide, starting a new "Debugging and Instrumentation" section there. Changes to the cpython patch: * fixed a bug in configure.in that was enabling systemtap support even without --with-systemtap (if the devel toolchain was present) * I added an initial check to test_systemtap to skip the tests unless Python was configured --with-systemtap * pysystemtap.h is not meant to be public, so I've moved the source pysystemtap.d and generated header pysystemtap.h from Include/ to Python/. I also simplified pysystemtap.d (removed the #pragma lines, since I believe they're DTrace-specific). * I've introduced a Python/ceval_systemtap.h private header as suggested by Antoine, moving things in there to simplify the changes to Python/ceval.c Changes to the devguide docs: * removed the ".. impl-detail" as this only seems to work (and be appropriate) in the cpython Doc build, not in devguide. * added "eu-readelf -n" example from Mark The docs refer to the low-level way of doing things (using the markers directly), but don't yet spell out the higher-level way (creating a tapset). I've left this out of the patches for now to keep the patches simpler. ---------- Added file: http://bugs.python.org/file25539/cpython-systemtap-2012-05-11-001.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 22:50:26 2012 From: report at bugs.python.org (Dave Malcolm) Date: Fri, 11 May 2012 20:50:26 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1336769426.32.0.18506229272.issue14776@psf.upfronthosting.co.za> Changes by Dave Malcolm : Added file: http://bugs.python.org/file25540/devguide-systemtap-2012-05-11-001.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 22:59:48 2012 From: report at bugs.python.org (Dave Malcolm) Date: Fri, 11 May 2012 20:59:48 +0000 Subject: [issue4111] Add Systemtap/DTrace probes In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za> Message-ID: <1336769988.97.0.580313683671.issue4111@psf.upfronthosting.co.za> Dave Malcolm added the comment: Issue #13405 covers DTrace; I've taken the liberty of also opening issue #14776 to cover SystemTap. I hope that once one of these is in the tree it will be easier to get the other one in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 23:02:01 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 May 2012 21:02:01 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336770121.77.0.338573422626.issue14777@psf.upfronthosting.co.za> Terry J. Reedy added the comment: There are definitely platform differences. As I noted, the original example works fine on Windows. However >>> root.clipboard_get(type='STRING') 'abc?' >>> root.clipboard_get(type='UTF8_STRING') Traceback (most recent call last): File "", line 1, in root.clipboard_get(type='UTF8_STRING') File "C:\Programs\Python33\lib\tkinter\__init__.py", line 549, in clipboard_get return self.tk.call(('clipboard', 'get') + self._options(kw)) _tkinter.TclError: CLIPBOARD selection doesn't exist or form "UTF8_STRING" not defined Of course, on Windows I suspect that the unicode string is not copied to clipboard as utf8 bytes, so if clipboard contents are tagged, there would not be such a thing. Perhaps clipboards work differently on diffferent OSes. >>> help(root.clipboard_get) ... The type keyword specifies the form in which the data is to be returned and should be an atom name such as STRING or FILE_NAME. Type defaults to STRING. (Actually, FILE_NAME give the same exception as UTF8_STRING.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 23:19:02 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 11 May 2012 21:19:02 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336771142.17.0.805767089452.issue14777@psf.upfronthosting.co.za> Ned Deily added the comment: Most likely the best way to determine the windowing system is to use the "tk windowingsystem" command (http://www.tcl.tk/man/tcl8.5/TkCmd/tk.htm#M10), so something like this: root = tkinter.Tk() root.call(('tk', 'windowingsystem')) As documented, the call returns 'x11' for X11-based systems, 'win32' for Windows, and 'aqua' for the native OS X implementations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 23:25:43 2012 From: report at bugs.python.org (Thomas Kluyver) Date: Fri, 11 May 2012 21:25:43 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336771543.13.0.989255606419.issue14777@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Thanks, Ned. Does it seem like a good idea to test the windowing system like that, and default to UTF8_STRING if it's x11? So far, I've not found any case on X where STRING works but UTF8_STRING doesn't. If it seems reasonable, I'm happy to have a go at making a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 23:32:16 2012 From: report at bugs.python.org (stefan brunthaler) Date: Fri, 11 May 2012 21:32:16 +0000 Subject: [issue14757] INCA: Inline Caching meets Quickening in Python 3.3 In-Reply-To: <1336498675.39.0.776636251166.issue14757@psf.upfronthosting.co.za> Message-ID: <1336771936.77.0.365193401768.issue14757@psf.upfronthosting.co.za> stefan brunthaler added the comment: This is the updated patch file that fixes the performance issues measurable using the official perf.py py3k test suite. ---------- Added file: http://bugs.python.org/file25541/20120511-inca.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 23:34:03 2012 From: report at bugs.python.org (stefan brunthaler) Date: Fri, 11 May 2012 21:34:03 +0000 Subject: [issue14757] INCA: Inline Caching meets Quickening in Python 3.3 In-Reply-To: <1336498675.39.0.776636251166.issue14757@psf.upfronthosting.co.za> Message-ID: <1336772043.32.0.289255488759.issue14757@psf.upfronthosting.co.za> Changes by stefan brunthaler : Added file: http://bugs.python.org/file25542/20120511-inca-perf.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 23:35:04 2012 From: report at bugs.python.org (stefan brunthaler) Date: Fri, 11 May 2012 21:35:04 +0000 Subject: [issue14757] INCA: Inline Caching meets Quickening in Python 3.3 In-Reply-To: <1336498675.39.0.776636251166.issue14757@psf.upfronthosting.co.za> Message-ID: <1336772104.17.0.138174580936.issue14757@psf.upfronthosting.co.za> Changes by stefan brunthaler : Added file: http://bugs.python.org/file25543/20120510-vanilla-perf.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 23:50:46 2012 From: report at bugs.python.org (Chris Rebert) Date: Fri, 11 May 2012 21:50:46 +0000 Subject: [issue14187] add "annotation" entry to Glossary In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za> Message-ID: <1336773046.16.0.222613366565.issue14187@psf.upfronthosting.co.za> Chris Rebert added the comment: Here's an actual patch. ---------- keywords: +patch Added file: http://bugs.python.org/file25544/func_annotation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 23:58:15 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 May 2012 21:58:15 +0000 Subject: [issue14419] Faster ascii decoding In-Reply-To: <1332795378.48.0.327832712874.issue14419@psf.upfronthosting.co.za> Message-ID: <1336773495.0.0.465783440514.issue14419@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Okay, thank you! ---------- dependencies: +Amazingly faster UTF-8 decoding resolution: -> duplicate stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 11 23:58:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 11 May 2012 21:58:22 +0000 Subject: [issue14419] Faster ascii decoding In-Reply-To: <1332795378.48.0.327832712874.issue14419@psf.upfronthosting.co.za> Message-ID: <1336773502.69.0.547007239707.issue14419@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- dependencies: -Amazingly faster UTF-8 decoding superseder: -> Amazingly faster UTF-8 decoding _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 00:02:25 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 11 May 2012 22:02:25 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336773745.35.0.00517374448982.issue14777@psf.upfronthosting.co.za> Ned Deily added the comment: A patch would be great. I don't have a strong opinion about the issue one way or another. I suppose it would simplify things for Python 3 users if the clipboard results were returned properly in the default case when no 'type' argument is passed to clipboard_get(). For Python 2, changing things seems a little more questionable but, as long as it was already returning a unicode object in that case, it sounds like a bug fix rather than a feature. Martin, Andrew: any opinions on this? ---------- nosy: +asvetlov, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 00:14:52 2012 From: report at bugs.python.org (stefan brunthaler) Date: Fri, 11 May 2012 22:14:52 +0000 Subject: [issue14757] INCA: Inline Caching meets Quickening in Python 3.3 In-Reply-To: <1336498675.39.0.776636251166.issue14757@psf.upfronthosting.co.za> Message-ID: <1336774492.93.0.662185862617.issue14757@psf.upfronthosting.co.za> stefan brunthaler added the comment: So I took a close look to what the performance problem was. Many of the benchmarks used by the perf.py py3k benchmarks use function calls for which there are no optimized derivatives available. In this case the function trying to do the quickening (aptly called "quickening_call_function") did not have a proper target instruction. Therefore, it was "stuck" with the additional quickening code in "quickening_call_function." This causes some overhead, or at least ate away some of the benefits of quickening. The new patch takes care of quickening to another function, if no better target is available, the only optimization being to have one instruction for calling a C function or a Python function/method (instruction labels being INCA_C_CALL, and INCA_PYTHON_CALL respectively. The new interpreter dispatch loop therefore has 208 instructions.) Furthermore, I have also added a baseline evaluation of running perf.py on my system, where I measure the vanilla Python 3.3 version against itself. I see quite some noise there, with some benchmarks showing up to 10pct outliers. On average, my interpretation is that around five percent variance needs to be accounted for. The new patch shows an overall improvement. For the slower ones, I guess that's within the error margin demonstrated by the baseline evaluation run. The remaining speedups are acceptable, even though I could tune the code generator to have more optimized derivatives in place. I took a closer look at the float benchmark, because my experience with the computer language benchmarks game the INCA optimization performs quite well there. These are the dynamic instruction frequencies for the two most frequently executed functions: maximize: --------- Freq. |pos | instruction | arg 1999900: 0: LOAD_FAST 0 1999900: 3: LOAD_ATTR 0 1999900: 6: LOAD_FAST 1 1999900: 9: LOAD_ATTR 0 1999900: 12: INCA_CMP_FLOAT 4 1999900: 15: POP_JUMP_IF_FALSE 27 1996400: 18: LOAD_FAST 0 1996400: 21: LOAD_ATTR 0 1996400: 24: JUMP_FORWARD 6 3500: 27: LOAD_FAST 1 3500: 30: LOAD_ATTR 0 1999900: 33: LOAD_FAST 0 1999900: 36: STORE_ATTR 0 1999900: 39: LOAD_FAST 0 1999900: 42: LOAD_ATTR 1 1999900: 45: LOAD_FAST 1 1999900: 48: LOAD_ATTR 1 1999900: 51: INCA_CMP_FLOAT 4 1999900: 54: POP_JUMP_IF_FALSE 66 1999900: 57: LOAD_FAST 0 1999900: 60: LOAD_ATTR 1 1999900: 63: JUMP_FORWARD 6 1999900: 72: LOAD_FAST 0 1999900: 75: STORE_ATTR 1 1999900: 78: LOAD_FAST 0 1999900: 81: LOAD_ATTR 2 1999900: 84: LOAD_FAST 1 1999900: 87: LOAD_ATTR 2 1999900: 90: INCA_CMP_FLOAT 4 1999900: 93: POP_JUMP_IF_FALSE 105 1993800: 96: LOAD_FAST 0 1993800: 99: LOAD_ATTR 2 1993800: 102: JUMP_FORWARD 6 6100: 105: LOAD_FAST 1 6100: 108: LOAD_ATTR 2 1999900: 111: LOAD_FAST 0 1999900: 114: STORE_ATTR 2 1999900: 117: LOAD_CONST 0 1999900: 120: RETURN_VALUE 0 normalize: ---------- Freq. |pos | instruction | arg 2000000: 0: LOAD_GLOBAL 0 2000000: 3: LOAD_FAST 0 2000000: 6: LOAD_ATTR 1 2000000: 9: LOAD_CONST 1 2000000: 12: INCA_FLOAT_POWER 1 2000000: 13: LOAD_FAST 0 2000000: 16: LOAD_ATTR 2 2000000: 19: LOAD_CONST 1 2000000: 22: INCA_FLOAT_POWER 1 2000000: 23: INCA_FLOAT_ADD 1 2000000: 24: LOAD_FAST 0 2000000: 27: LOAD_ATTR 3 2000000: 30: LOAD_CONST 1 2000000: 33: INCA_FLOAT_POWER 1 2000000: 34: INCA_FLOAT_ADD 1 2000000: 35: FAST_C_ONE 1 (call?) 2000000: 38: STORE_FAST 1 2000000: 41: LOAD_FAST 0 2000000: 44: LOAD_ATTR 1 2000000: 47: LOAD_FAST 1 2000000: 50: INCA_FLOAT_TRUE_DIVIDE 1 2000000: 51: LOAD_FAST 0 2000000: 54: STORE_ATTR 1 2000000: 57: LOAD_FAST 0 2000000: 60: LOAD_ATTR 2 2000000: 63: LOAD_FAST 1 2000000: 66: INCA_FLOAT_TRUE_DIVIDE 1 2000000: 67: LOAD_FAST 0 2000000: 70: STORE_ATTR 2 2000000: 73: LOAD_FAST 0 2000000: 76: LOAD_ATTR 3 2000000: 79: LOAD_FAST 1 2000000: 82: INCA_FLOAT_TRUE_DIVIDE 1 2000000: 83: LOAD_FAST 0 2000000: 86: STORE_ATTR 3 2000000: 89: LOAD_CONST 0 2000000: 92: RETURN_VALUE 0 It is clear from these data that INCA_FLOAT_POWER and INCA_FLOAT_TRUE_DIVIDE are the most frequently executed float operations during run time. However, the code-gen only inlines the simple cases of INCA_FLOAT_{ADD, SUBTRACT, and MULT}. In consequence, we see a lower optimization potential around here. One solution to improving this benchmarks' performance would be to inline the POWER and TRUE_DIVIDE operations into the corresponding derivatives (for TRUE_DIVIDE this is easy, I'll try and run the numbers again.) The dynamic instruction frequencies show that there are many data movement instructions interleaved. If I find some spare time somewhere hidden in some future weekend, I'm going to focus on getting partial-stack-frame-caching to work, too, as this should have a noticeable impact on such code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 00:33:07 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 11 May 2012 22:33:07 +0000 Subject: [issue14187] add "function annotation" entry to Glossary In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za> Message-ID: <1336775587.72.0.41839149582.issue14187@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks, LGTM. ---------- title: add "annotation" entry to Glossary -> add "function annotation" entry to Glossary _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 00:40:31 2012 From: report at bugs.python.org (Dave Malcolm) Date: Fri, 11 May 2012 22:40:31 +0000 Subject: [issue14785] Add sys._debugmallocstats() Message-ID: <1336776030.63.0.471450530302.issue14785@psf.upfronthosting.co.za> New submission from Dave Malcolm : I'm attaching a patch which generalizes the at-exit PYTHONMALLOCSTATS memory usage report, so that it's available in a regular build and can be triggered from Python, by calling: sys._debugmallocstats() This can be useful when debugging memory usage issues: a script can call the debug hook before and after certain activities, and the before/after amounts can be compared. The patch moves this arena-accouting code when a new arena is allocated: ++ntimes_arena_allocated; if (narenas_currently_allocated > narenas_highwater) narenas_highwater = narenas_currently_allocated; from out of the #ifdef PYMALLOC_DEBUG guard and into all PYMALLOC configurations, so that this data is available within the dump. Given how much activity happens when a new arena is allocated, I believe this doesn't impact performance. It changes _PyObject_DebugMallocStats() to take an arbitrary FILE*, rather than assuming stderr (which was handy for my original use-case of debugging a web server). This function is already marked with PyAPI_FUNC() but not documented (albeit only present in a debug build). Tested with --with-pymalloc, --without-pymalloc, and --with-pydebug FWIW, Red Hat has been using a version of this patch in RHEL 5 as of RHEL 5.6 (http://rhn.redhat.com/errata/RHSA-2011-0027.html), and also in Fedora since September 2011 with python-2.7.2-15 and python3-3.2.2-6 (for the forthcoming Fedora 17). ---------- files: add-debug-malloc-stats.patch keywords: needs review, patch messages: 160459 nosy: dmalcolm priority: normal severity: normal stage: patch review status: open title: Add sys._debugmallocstats() type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25545/add-debug-malloc-stats.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 00:47:25 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 May 2012 22:47:25 +0000 Subject: [issue14187] add "function annotation" entry to Glossary In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za> Message-ID: <1336776445.03.0.90814619419.issue14187@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The third paragraph should be dropped. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 02:54:28 2012 From: report at bugs.python.org (James Henstridge) Date: Sat, 12 May 2012 00:54:28 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336784068.41.0.623539997579.issue12029@psf.upfronthosting.co.za> James Henstridge added the comment: Benjamin: if you are after a use case for this feature, see https://code.djangoproject.com/ticket/15901 In Django, there are multiple database backends, each of which currently catch the adapter's DatabaseError and reraise it as Django's DatabaseError so that Django code can handle database errors in a standard way without having to care about which backend they came from. Unfortunately, this loses some information from the exception. My idea for solving that bug was to make Django's DatabaseError an ABC. By registering the various adapter's DatabaseErrors with the ABC, it would not be necessary to catch and reraise them in the backends while still preserving the ability to catch the generic errors in the core. This works fine in Python 2.x, but it was pointed out that it would cause compatibility problems when porting to Python 3.2. ---------- type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 03:09:05 2012 From: report at bugs.python.org (James Henstridge) Date: Sat, 12 May 2012 01:09:05 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336784945.06.0.128170906155.issue12029@psf.upfronthosting.co.za> Changes by James Henstridge : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 09:09:09 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 12 May 2012 07:09:09 +0000 Subject: [issue14738] Amazingly faster UTF-8 decoding In-Reply-To: <1336765544.62.0.241618712685.issue14738@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: If the commit makes Python 3.3 faster than Python 3.2, it is an optimisation that should be documented in the What's New in Python 3.3 document. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 10:10:08 2012 From: report at bugs.python.org (Yugang LIU) Date: Sat, 12 May 2012 08:10:08 +0000 Subject: [issue14786] htmlparser with tag br Message-ID: <1336810208.34.0.533779581931.issue14786@psf.upfronthosting.co.za> New submission from Yugang LIU : Hi, I parse html source with htmlparser. I catch a tag, br, issue. my code :
aaaa
parse result: begin tag: div begin tag: br end tag: div So I can't find end tag of 'br'. I know it is invalid text, '
', it set htmlparser parameter, strict, to 'False', it can't help me also. Please help fix it. Thanks. ---------- components: None messages: 160463 nosy: liuyug priority: normal severity: normal status: open title: htmlparser with tag br versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 11:01:11 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 12 May 2012 09:01:11 +0000 Subject: [issue14787] pkgutil.walk_packages returns extra modules Message-ID: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za> New submission from Chris Jerdonek : pkgutil.walk_packages(paths) seems to return incorrect results when the name of a subpackage of a path in paths matches the name of a package in the standard library. It both excludes modules it should include, and includes modules it should exclude. Here is an example: > mkdir temp > touch temp/__init__.py > touch temp/foo.py > mkdir temp/logging > touch temp/logging/__init__.py > touch temp/logging/bar.py > python Python 3.2.3 (default, Apr 29 2012, 01:19:06) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from pkgutil import walk_packages >>> for info in walk_packages(['temp']): ... print(info[1], info[0].path) ... foo temp logging temp logging.config /opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/logging logging.handlers /opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/logging >>> Observe that logging.bar is absent from the list, and logging.config and logging.handlers are included. ---------- components: Library (Lib) messages: 160464 nosy: cjerdonek priority: normal severity: normal status: open title: pkgutil.walk_packages returns extra modules type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 11:37:35 2012 From: report at bugs.python.org (alon horev) Date: Sat, 12 May 2012 09:37:35 +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: <1336815455.74.0.190600781946.issue7317@psf.upfronthosting.co.za> alon horev added the comment: how does one get his patch reviewed? (it's been 6 months) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 11:49:17 2012 From: report at bugs.python.org (Daniel Urban) Date: Sat, 12 May 2012 09:49:17 +0000 Subject: [issue14588] PEP 3115 compliant dynamic class creation In-Reply-To: <1334535798.87.0.826104374353.issue14588@psf.upfronthosting.co.za> Message-ID: <1336816157.89.0.455184861234.issue14588@psf.upfronthosting.co.za> Daniel Urban added the comment: Here is my first attempt at creating a pure Python version of the operator.build_class function (in my previous patch) as types.new_class. The three added functions (two private and one public) correspond to the following functions in my previous patch: types.new_class -> operator.build_class types._prepare_ns -> prepare_namespace in typeobject.c types._calculate_mcls -> calculate_metaclass in typeobject.c (currently _PyType_CalculateMetaclass) (In Python these functions are quite short, so they may be merged. But this separation may be better for documentation purposes...) The tests are mostly the same as in my previous patch. ---------- components: +Library (Lib) Added file: http://bugs.python.org/file25546/types_new_class.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 12:07:37 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 12 May 2012 10:07:37 +0000 Subject: [issue14788] Pdb debugs itself after ^C and a breakpoint is set anywhere Message-ID: <1336817257.9.0.505200749782.issue14788@psf.upfronthosting.co.za> New submission from Xavier de Gaye : When a breakpoint is set anywhere (in which case the global system's trace function is set), interrupting the debuggee causes Pdb to stop into its own code. See the following pdb session run with python on the current head of the default branch from the repo. === main.py ================================= import time def bar(): i = 1 while i: time.sleep(.100) bar() ================================================= $ python -m pdb main.py > /path_to/main.py(1)() -> import time (Pdb) import sys; print(sys.version) 3.3.0a3+ (default:4e9680570be8, May 11 2012, 12:09:15) [GCC 4.3.2] (Pdb) break bar Breakpoint 1 at /path_to/main.py:2 (Pdb) continue > /path_to/main.py(3)bar() -> i = 1 (Pdb) continue ^C Program interrupted. (Use 'cont' to resume). --Call-- > /home/xavier/src/cpython/cpython-hg-default/Lib/bdb.py(212)set_trace() -> def set_trace(self, frame=None): (Pdb) where /home/xavier/src/cpython/cpython-hg-default/Lib/bdb.py(405)run() -> exec(cmd, globals, locals) (1)() /path_to/main.py(7)() -> bar() /path_to/main.py(5)bar() -> time.sleep(.100) /home/xavier/src/cpython/cpython-hg-default/Lib/pdb.py(196)sigint_handler() -> self.set_trace(frame) > /home/xavier/src/cpython/cpython-hg-default/Lib/bdb.py(212)set_trace() -> def set_trace(self, frame=None): (Pdb) quit ================================================= The attached patch fixes the problem and includes a test case. This fix is the same as the one proposed at issue 14743 to fix another problem, except that the set_step call is moved at the end of the sigint_handler method for the sake of robustness. ---------- components: Library (Lib) files: pdb_default.patch keywords: patch messages: 160467 nosy: xdegaye priority: normal severity: normal status: open title: Pdb debugs itself after ^C and a breakpoint is set anywhere type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file25547/pdb_default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 12:48:57 2012 From: report at bugs.python.org (=?utf-8?q?George-Cristian_B=C3=AErzan?=) Date: Sat, 12 May 2012 10:48:57 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1336819737.67.0.976173172134.issue12029@psf.upfronthosting.co.za> George-Cristian B?rzan added the comment: As promissed the patch. It doesn't break any tests, and it passes the ones I added. I have a pybench one as well, which even though trivial, does point to the fact that there is a degradation in performance, but not sure it's worth posting here. ---------- keywords: +patch Added file: http://bugs.python.org/file25548/issue12029.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 15:32:23 2012 From: report at bugs.python.org (Gennadiy Zlobin) Date: Sat, 12 May 2012 13:32:23 +0000 Subject: [issue14787] pkgutil.walk_packages returns extra modules In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za> Message-ID: <1336829543.65.0.59941583299.issue14787@psf.upfronthosting.co.za> Gennadiy Zlobin added the comment: I confirm this behavior in 2.7 and 3.2 versions. In my 3.3.0a3+ it actually outputs nothing. Also note that if you rename logging to logging2, you actually get foo temp logging2 temp ---------- nosy: +gennad versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 15:54:12 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 12 May 2012 13:54:12 +0000 Subject: [issue14789] after continue, Pdb stops at a line without a breakpoint Message-ID: <1336830852.57.0.923770658038.issue14789@psf.upfronthosting.co.za> New submission from Xavier de Gaye : In the following test run with python on the current head of the default branch, Pdb stops at line 3 where there is no breakpoint after two breakpoints have been set on the same function (setting two bps on the same location is useful, for example one bp to print a value without stopping and the other one with an ignore count). === main.py ================================= def bar(): x = 1 x = 2 bar() ================================================= $ python -m pdb main.py > /path_to/main.py(1)() -> def bar(): (Pdb) import sys; print(sys.version) 3.3.0a3+ (default:4e9680570be8, May 11 2012, 12:09:15) [GCC 4.3.2] (Pdb) break bar Breakpoint 1 at /path_to/main.py:1 (Pdb) break bar Breakpoint 2 at /path_to/main.py:1 (Pdb) continue > /path_to/main.py(2)bar() -> x = 1 (Pdb) continue > /path_to/main.py(3)bar() -> x = 2 (Pdb) quit ================================================= The attached patch fixes the problem. This patch also fixes the following problems that are caused by the same bug: * when more than one breakpoint is set on the same line, only the command of the first effective breakpoint is run, and only the hit count and the ignore count of the first effective breakpoint are updated The patch includes a test case for all those problems. ---------- components: Library (Lib) files: pdb_default.patch keywords: patch messages: 160470 nosy: xdegaye priority: normal severity: normal status: open title: after continue, Pdb stops at a line without a breakpoint type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25549/pdb_default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 17:04:04 2012 From: report at bugs.python.org (Sandro Tosi) Date: Sat, 12 May 2012 15:04:04 +0000 Subject: [issue14187] add "function annotation" entry to Glossary In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za> Message-ID: <1336835044.75.0.784447287723.issue14187@psf.upfronthosting.co.za> Sandro Tosi added the comment: I agree with Raymond that last paragraph should be removed; +1 for the remaining part ---------- nosy: +sandro.tosi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 17:06:14 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 12 May 2012 15:06:14 +0000 Subject: [issue13734] Add a generic directory walker method to avoid symlink attacks In-Reply-To: <1336684856.55.0.156045803992.issue13734@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > It would be nice if the documentation of fwalk() explained why you would > want to use it over walk(). How does the attached patch look? ---------- Added file: http://bugs.python.org/file25550/fwalk-doc.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff --git a/Doc/library/os.rst b/Doc/library/os.rst --- a/Doc/library/os.rst +++ b/Doc/library/os.rst @@ -2356,6 +2356,9 @@ *dirpath*, *dirnames* and *filenames* are identical to :func:`walk` output, and *dirfd* is a file descriptor referring to the directory *dirpath*. + It can be used, for example, to walk a directory tree in a way that is + immune to symlink attacks. + .. note:: Since :func:`fwalk` yields file descriptors, those are only valid until From report at bugs.python.org Sat May 12 17:16:58 2012 From: report at bugs.python.org (anatoly techtonik) Date: Sat, 12 May 2012 15:16:58 +0000 Subject: [issue1635217] Add example of distutils setup() with "requires" argument Message-ID: <1336835818.07.0.744431194732.issue1635217@psf.upfronthosting.co.za> anatoly techtonik added the comment: I still need requires example - here. http://docs.python.org/distutils/setupscript.html#relationships-between-distributions-and-packages - after "Dependencies.." paragraph. =) setup(..., requires=["somepackage (>1.0, !=1.5)"], provides=["mypkg (1.1)"] ) ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 17:57:23 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 12 May 2012 15:57:23 +0000 Subject: [issue14773] fwalk breaks on dangling symlinks In-Reply-To: <1336678120.54.0.411663637267.issue14773@psf.upfronthosting.co.za> Message-ID: <1336838243.67.0.748928469107.issue14773@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: I'm not sure we really need to check for a dangling symlink in case of FileNotFoundError: whether it's a dangling symlink, or the file disappeared in-between-, skipping it is OK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 18:22:53 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 12 May 2012 16:22:53 +0000 Subject: [issue14790] use packaging in setup.py Message-ID: <1336839772.98.0.460402187973.issue14790@psf.upfronthosting.co.za> New submission from Antoine Pitrou : setup.py should use packaging, not distutils. ---------- components: Build messages: 160475 nosy: eric.araujo, pitrou, tarek priority: normal severity: normal status: open title: use packaging in setup.py type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 18:27:18 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 12 May 2012 16:27:18 +0000 Subject: [issue14790] use packaging in setup.py In-Reply-To: <1336839772.98.0.460402187973.issue14790@psf.upfronthosting.co.za> Message-ID: <1336840038.06.0.212124977406.issue14790@psf.upfronthosting.co.za> ?ric Araujo added the comment: I?d rather wait for a more stable version, so 3.4. ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 18:32:43 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 12 May 2012 16:32:43 +0000 Subject: [issue14790] use packaging in setup.py In-Reply-To: <1336839772.98.0.460402187973.issue14790@psf.upfronthosting.co.za> Message-ID: <1336840363.42.0.381293697365.issue14790@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'd rather not wait. If packaging is not able to reliably build Python itself, we shouldn't release Python 3.3 until it is (or withdraw packaging from the standard library altogether). ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 18:33:20 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 12 May 2012 16:33:20 +0000 Subject: [issue14790] use packaging in setup.py In-Reply-To: <1336839772.98.0.460402187973.issue14790@psf.upfronthosting.co.za> Message-ID: <1336840400.41.0.203366996089.issue14790@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: +Python 3.3 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 18:34:05 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 12 May 2012 16:34:05 +0000 Subject: [issue14790] use packaging in setup.py In-Reply-To: <1336839772.98.0.460402187973.issue14790@psf.upfronthosting.co.za> Message-ID: <1336840445.88.0.581643012046.issue14790@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 18:40:43 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 12 May 2012 16:40:43 +0000 Subject: [issue14791] setup.py only adds /prefix/lib, not /prefix/lib64 Message-ID: <1336840843.09.0.565460268003.issue14791@psf.upfronthosting.co.za> New submission from Antoine Pitrou : setup.py adds /lib to the list of directories where libraries are looked for, but not /lib64. Patch attached. ---------- components: Build files: setup_lib64.patch keywords: patch messages: 160478 nosy: dmalcolm, pitrou priority: low severity: normal stage: patch review status: open title: setup.py only adds /prefix/lib, not /prefix/lib64 type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25551/setup_lib64.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 18:41:38 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 12 May 2012 16:41:38 +0000 Subject: [issue14790] use packaging in setup.py In-Reply-To: <1336840363.42.0.381293697365.issue14790@psf.upfronthosting.co.za> Message-ID: <1336840766.3361.11.camel@localhost.localdomain> Antoine Pitrou added the comment: > I'd rather not wait. If packaging is not able to reliably build Python > itself, we shouldn't release Python 3.3 until it is (or withdraw > packaging from the standard library altogether). Indeed, this is exactly the reason I entered this enhancement request. Eating our own dogfood is a good way of detecting issues :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 18:45:53 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 12 May 2012 16:45:53 +0000 Subject: [issue14785] Add sys._debugmallocstats() In-Reply-To: <1336776030.63.0.471450530302.issue14785@psf.upfronthosting.co.za> Message-ID: <1336841153.13.0.61063532795.issue14785@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Nice idea. I don't see any obvious problem with the patch, except that the test should reuse test.script_helper.assert_python_ok(). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 18:51:14 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 12 May 2012 16:51:14 +0000 Subject: [issue14786] htmlparser with tag br In-Reply-To: <1336810208.34.0.533779581931.issue14786@psf.upfronthosting.co.za> Message-ID: <1336841474.91.0.684060031665.issue14786@psf.upfronthosting.co.za> Ezio Melotti added the comment: The HTML you pasted looks valid to me -- the br element doesn't have an end tag and the HTML 4.01 standard explicitly says "Start tag: required, End tag: forbidden" [0]. Why do you think this is a problem? [0]: http://www.w3.org/TR/html401/struct/text.html#edef-BR ---------- assignee: -> ezio.melotti components: +Library (Lib) -None nosy: +ezio.melotti resolution: -> invalid _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 18:54:38 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 12 May 2012 16:54:38 +0000 Subject: [issue14790] use packaging in setup.py In-Reply-To: <1336839772.98.0.460402187973.issue14790@psf.upfronthosting.co.za> Message-ID: <1336841678.06.0.698230908458.issue14790@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 19:00:22 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 12 May 2012 17:00:22 +0000 Subject: [issue1294959] Problems with /usr/lib64 builds. Message-ID: <1336842022.22.0.192907118309.issue1294959@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: I currently think that sys.libdir should be only basename of libdir (e.g. "lib" or "lib64") to allow to easily use it with something else than sys.prefix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 19:02:48 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 12 May 2012 17:02:48 +0000 Subject: [issue14791] setup.py only adds /prefix/lib, not /prefix/lib64 In-Reply-To: <1336840843.09.0.565460268003.issue14791@psf.upfronthosting.co.za> Message-ID: <1336842168.29.0.90781498961.issue14791@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: It would be better to fix issue #1294959 and use os.path.join(sys.prefix, sys.libdir). IIRC some mips architectures need "/usr/lib32", while x32 architecture needs "/usr/libx32". ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 19:05:07 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 May 2012 17:05:07 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 85824b819bcb by Antoine Pitrou in branch 'default': Issue #14082: shutil.copy2() now copies extended attributes, if possible. http://hg.python.org/cpython/rev/85824b819bcb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 19:05:56 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 12 May 2012 17:05:56 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za> Message-ID: <1336842356.07.0.133604986821.issue14082@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Pushed now. Hopefully the buildbots won't moan. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 19:13:47 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 12 May 2012 17:13:47 +0000 Subject: [issue14784] Re-importing _warnings changes warnings.filters In-Reply-To: <1336765216.03.0.0611996113989.issue14784@psf.upfronthosting.co.za> Message-ID: <1336842827.85.0.854630282572.issue14784@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 19:21:22 2012 From: report at bugs.python.org (Thomas Kluyver) Date: Sat, 12 May 2012 17:21:22 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336843282.53.0.649568967295.issue14777@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Here's a patch that makes UTF8_STRING the default type for clipboard_get and selection_get when running in X11. ---------- keywords: +patch Added file: http://bugs.python.org/file25552/x11-clipboard-utf8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 19:25:12 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 12 May 2012 17:25:12 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za> Message-ID: <1336843512.8.0.653354692011.issue14082@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looks like we have our first buildbot failure: ====================================================================== FAIL: test_copyxattr (test.test_shutil.TestShutil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/test_shutil.py", line 346, in test_copyxattr self.assertEqual(['user.bar'], os.listxattr(dst)) AssertionError: Lists differ: ['user.bar'] != ['security.selinux', 'user.bar... First differing element 0: user.bar security.selinux Second list contains 1 additional elements. First extra element 1: user.bar - ['user.bar'] + ['security.selinux', 'user.bar'] ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 20:13:50 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 12 May 2012 18:13:50 +0000 Subject: [issue14773] fwalk breaks on dangling symlinks In-Reply-To: <1336678120.54.0.411663637267.issue14773@psf.upfronthosting.co.za> Message-ID: <1336846430.23.0.662117973516.issue14773@psf.upfronthosting.co.za> Hynek Schlawack added the comment: But if it is a dangling symlink, you want to add it to nondirs while missing files could be skipped, no? You can't skip dangling symlinks if you want to implement rmtree. The normal walk() doesn't too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 21:50:48 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 12 May 2012 19:50:48 +0000 Subject: [issue14792] setting a bp on current function, Pdb stops at next line although no bp Message-ID: <1336852248.64.0.23937639047.issue14792@psf.upfronthosting.co.za> New submission from Xavier de Gaye : Setting a breakpoint on a function from within that functions makes pdb to stop at the following line (where no breakpoint is set) after a continue command. In the following test pdb stops at line 3 where there is no breakpoint. === main.py ================================= def foo(): x = 1 x = 2 foo() ================================================= $ python -m pdb main.py > /path_to/main.py(1)() -> def foo(): (Pdb) import sys; print(sys.version) 3.3.0a3+ (default:4e9680570be8, May 11 2012, 12:09:15) [GCC 4.3.2] (Pdb) break 2 Breakpoint 1 at /path_to/main.py:2 (Pdb) continue > /path_to/main.py(2)foo() -> x = 1 (Pdb) break foo Breakpoint 2 at /path_to/main.py:1 (Pdb) continue > /path_to/main.py(3)foo() -> x = 2 (Pdb) where /home/xavier/src/cpython/cpython-hg-default/Lib/bdb.py(405)run() -> exec(cmd, globals, locals) (1)() /path_to/main.py(5)() -> foo() > /path_to/main.py(3)foo() -> x = 2 (Pdb) quit ================================================= The attached patch fixes the problem. The patch includes a test case. ---------- components: Library (Lib) files: pdb_default.patch keywords: patch messages: 160489 nosy: xdegaye priority: normal severity: normal status: open title: setting a bp on current function, Pdb stops at next line although no bp type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25553/pdb_default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 21:52:12 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 12 May 2012 19:52:12 +0000 Subject: [issue13734] Add a generic directory walker method to avoid symlink attacks In-Reply-To: Message-ID: Benjamin Peterson added the comment: 2012/5/12 Charles-Fran?ois Natali : > > Charles-Fran?ois Natali added the comment: > >> It would be nice if the documentation of fwalk() explained why you would >> want to use it over walk(). > > How does the attached patch look? Okay, but explain what a "symlink attack" is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 22:15:36 2012 From: report at bugs.python.org (Daniel Swanson) Date: Sat, 12 May 2012 20:15:36 +0000 Subject: [issue14672] Windows installer: add desktop shortcut(s) In-Reply-To: <1335414011.97.0.984037154974.issue14672@psf.upfronthosting.co.za> Message-ID: <1336853736.28.0.759771389157.issue14672@psf.upfronthosting.co.za> Daniel Swanson added the comment: What's the start menu? hahaha I think that this issue is pointless, it takes 3 clicks to make a desktop shortcut (if have a lot of programs on your computer, maybe 4) any Windows user should know how to do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 23:14:00 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 May 2012 21:14:00 +0000 Subject: [issue14779] test_buffer fails on OS X universal 64-/32-bit builds In-Reply-To: <1336692055.13.0.571191399969.issue14779@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 8f22e5be18c8 by Stefan Krah in branch 'default': Issue #14779: Do not use get_config_var('SIZEOF_VOID_P') on OS X 64-/32-bit http://hg.python.org/cpython/rev/8f22e5be18c8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 23:43:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 May 2012 21:43:33 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 7bf8ac742d2f by Brett Cannon in branch 'default': Issue #13959: Introduce importlib.find_loader(). http://hg.python.org/cpython/rev/7bf8ac742d2f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 23:44:39 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 12 May 2012 21:44:39 +0000 Subject: [issue14779] test_buffer fails on OS X universal 64-/32-bit builds In-Reply-To: <1336692055.13.0.571191399969.issue14779@psf.upfronthosting.co.za> Message-ID: <1336859079.76.0.759628470638.issue14779@psf.upfronthosting.co.za> Stefan Krah added the comment: Apparently the AS/400 had 128 bit pointers and IBM's "System i" still has them: http://comments.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/651 http://www-01.ibm.com/support/docview.wss?uid=swg27019425 So I'll leave the SIZEOF_VOID_P test as the preferred method. Perhaps the best way to sidestep all these issues would be to write a small C module for getting type sizes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 23:49:58 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 12 May 2012 21:49:58 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1336859398.27.0.822579057077.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: I have importlib.find_loader() coded up, but getting rid of find_module() is going to be a pain thanks to pkgutil, multiprocessing.forking, modulefinder, and idlelib.EditorWindow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 23:52:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 May 2012 21:52:58 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 10e8b97d0fd7 by Antoine Pitrou in branch 'default': Make the reference counting of dictkeys objects participate in refleak hunting http://hg.python.org/cpython/rev/10e8b97d0fd7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 23:53:07 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 12 May 2012 21:53:07 +0000 Subject: [issue14793] broken grammar in Built-in Types doc Message-ID: <1336859587.23.0.399081915323.issue14793@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- assignee: docs at python components: Documentation files: grammar.diff keywords: patch nosy: docs at python, tshepang priority: normal severity: normal status: open title: broken grammar in Built-in Types doc versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25554/grammar.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 12 23:59:28 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 12 May 2012 21:59:28 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za> Message-ID: <1336859968.76.0.456826404984.issue14082@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hynek's patch (communicated over IRC, committed in 8d85f9920878) seems to have fixed the failure. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 00:25:37 2012 From: report at bugs.python.org (Tom Pinckney) Date: Sat, 12 May 2012 22:25:37 +0000 Subject: [issue6696] Profile objects should be documented In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za> Message-ID: <1336861537.77.0.651670043068.issue6696@psf.upfronthosting.co.za> Tom Pinckney added the comment: I took a stab at updating the docs based on the current profiler source. See attached patch for a first draft. This is my first doc patch so would appreciate any feedback on style and substance of my changes. I tried to document more of the modules (for example the internal Profile object), logically arrange things a better better IMHO, and generally be more precise about what is happening. ---------- keywords: +patch Added file: http://bugs.python.org/file25555/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 00:36:19 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 12 May 2012 22:36:19 +0000 Subject: [issue14779] test_buffer fails on OS X universal 64-/32-bit builds In-Reply-To: <1336692055.13.0.571191399969.issue14779@psf.upfronthosting.co.za> Message-ID: <1336862179.14.0.338344107804.issue14779@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 00:37:09 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 12 May 2012 22:37:09 +0000 Subject: [issue14773] fwalk breaks on dangling symlinks In-Reply-To: <1336678120.54.0.411663637267.issue14773@psf.upfronthosting.co.za> Message-ID: <1336862229.86.0.616238688671.issue14773@psf.upfronthosting.co.za> Hynek Schlawack added the comment: So I've changed the patch to ignore everything missing except for dangling links (which throw unfortunately the same exception). Just to stress it once more: a fwalk that _ignores_ dangling symlinks is worthless for rmtree. And wasn't rmtree the initial reason to implement fwalk in the first place? ;) ---------- Added file: http://bugs.python.org/file25556/fwalk-ignore-missing-files.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 00:51:38 2012 From: report at bugs.python.org (Paul Upchurch) Date: Sat, 12 May 2012 22:51:38 +0000 Subject: [issue14794] slice.indices raises OverflowError Message-ID: <1336863098.54.0.753598684211.issue14794@psf.upfronthosting.co.za> New submission from Paul Upchurch : To reproduce the error: Python 3.2.2 (default, Sep 5 2011, 22:09:30) [GCC 4.6.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> slice(0,90000,None).indices(12600000000) Traceback (most recent call last): File "", line 1, in OverflowError: cannot fit 'int' into an index-sized integer >>> The correct behaviour is to return (0, 90000, 1). >>> slice(0,90000,None).indices(600000000) (0, 90000, 1) This is related to http://bugs.python.org/issue1456470. ---------- components: Interpreter Core messages: 160500 nosy: Paul.Upchurch priority: normal severity: normal status: open title: slice.indices raises OverflowError type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 00:57:56 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 12 May 2012 22:57:56 +0000 Subject: [issue14794] slice.indices raises OverflowError In-Reply-To: <1336863098.54.0.753598684211.issue14794@psf.upfronthosting.co.za> Message-ID: <1336863476.44.0.603161426332.issue14794@psf.upfronthosting.co.za> Hynek Schlawack added the comment: This seems to have been fixed as of 3.2.3 (as shipped with Ubuntu Precise): Python 3.2.3 (default, Apr 12 2012, 19:08:59) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> slice(0,90000,None).indices(12600000000) (0, 90000, 1) Current tip works fine too: Python 3.3.0a3+ (default:b32baa5b7626+, May 10 2012, 14:56:20) [GCC 4.6.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> slice(0,90000,None).indices(12600000000) (0, 90000, 1) I'd close this bug unless I'm missing something? ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 01:13:25 2012 From: report at bugs.python.org (Paul Upchurch) Date: Sat, 12 May 2012 23:13:25 +0000 Subject: [issue14794] slice.indices raises OverflowError In-Reply-To: <1336863098.54.0.753598684211.issue14794@psf.upfronthosting.co.za> Message-ID: <1336864405.54.0.112675909373.issue14794@psf.upfronthosting.co.za> Paul Upchurch added the comment: Sorry. I didn't realize there was a 3.2.3 out. I'll close it as fixed. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 04:26:49 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 13 May 2012 02:26:49 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336428561.46.0.842580483885.issue14744@psf.upfronthosting.co.za> Message-ID: <1336876009.15.0.759788654308.issue14744@psf.upfronthosting.co.za> STINNER Victor added the comment: To prepare a deeper change, here is a first simple patch. Change how the size of the _PyUnicodeWriter buffer is handled: * overallocate by 100% (instead of 25%) and allocate at least 100 characters * don't overallocate when possible It is possible to not overallocate when the format string has no prefix nor suffix and when there is only one argument. For example, "%s" % "abc" does directly allocate the exact buffer size and so don't need to call realloc() at the end. The patch does also micro-optimize (cleanup?) _PyUnicodeWriter_Finish. When it's possible to not overallocate, the speed up is around 10% for short strings (I suppose that it's much better to longer strings). -- Output of the attached benchmark.py script: Linux-3.3.2-1.fc16.x86_64-x86_64-with-fedora-16-Verne Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz === 3.3 === 16 ms: N=200; fmt="{0}-"*N; arg="abc"; fmt.format(arg) 5.77 ms: N=200; L=3; fmt="%s"*N; args=("a"*L,)*N; fmt % args 648 ns: s="The {k1} is {k2} the {k3}."; args={"k1": "x", "k2": "y", "k3": "z"}; s.format(**args) 427 ns: s="The %(k1)s is %(k2)s the %(k3)s."; args={"k1":"x","k2":"y","k3":"z",}; s%args 531 ns: s="x={}, y={}, z={}"; args=(123, 456, 789); s.format(*args) 453 ns: s="x=%s, y=%u, z=%x"; args=(123, 456, 789); s%args 180 ns: fmt="{}"; arg="abc"; fmt.format(arg) 228 ns: fmt="{}"; arg=123; fmt.format(arg) 196 ns: fmt="x={}"; arg="abc"; fmt.format(arg) 244 ns: fmt="x={}"; arg=123; fmt.format(arg) 175 ns: str(12345) 233 ns: '{}'.format(12345) 243 ns: 'A{}'.format(12345) 276 ns: '\x80{}'.format(12345) 292 ns: '\u0100{}'.format(12345) 285 ns: '\U00010000{}'.format(12345) 417 ns: '{:-10}'.format(12345) 425 ns: 'A{:-10}'.format(12345) 461 ns: '\x80{:-10}'.format(12345) 488 ns: '\u0100{:-10}'.format(12345) 461 ns: '\U00010000{:-10}'.format(12345) 403 ns: '{:,}'.format(12345) 416 ns: 'A{:,}'.format(12345) 455 ns: '\x80{:,}'.format(12345) 469 ns: '\u0100{:,}'.format(12345) 448 ns: '\U00010000{:,}'.format(12345) 108 ns: fmt="%s"; arg="abc"; fmt % arg 163 ns: fmt="%s"; arg=123; fmt % arg 121 ns: fmt="%s:"; arg="abc"; fmt % arg === 3.3 + dont_overallocate.patch === 15.5 ms: N=200; fmt="{0}-"*N; arg="abc"; fmt.format(arg) 6 ms: N=200; L=3; fmt="%s"*N; args=("a"*L,)*N; fmt % args 599 ns: s="The {k1} is {k2} the {k3}."; args={"k1": "x", "k2": "y", "k3": "z"}; s.format(**args) 424 ns: s="The %(k1)s is %(k2)s the %(k3)s."; args={"k1":"x","k2":"y","k3":"z",}; s%args 531 ns: s="x={}, y={}, z={}"; args=(123, 456, 789); s.format(*args) 441 ns: s="x=%s, y=%u, z=%x"; args=(123, 456, 789); s%args 155 ns: fmt="{}"; arg="abc"; fmt.format(arg) 206 ns: fmt="{}"; arg=123; fmt.format(arg) 204 ns: fmt="x={}"; arg="abc"; fmt.format(arg) 247 ns: fmt="x={}"; arg=123; fmt.format(arg) 172 ns: str(12345) 209 ns: '{}'.format(12345) 248 ns: 'A{}'.format(12345) 257 ns: '\x80{}'.format(12345) 265 ns: '\u0100{}'.format(12345) 263 ns: '\U00010000{}'.format(12345) 354 ns: '{:-10}'.format(12345) 404 ns: 'A{:-10}'.format(12345) 415 ns: '\x80{:-10}'.format(12345) 457 ns: '\u0100{:-10}'.format(12345) 430 ns: '\U00010000{:-10}'.format(12345) 369 ns: '{:,}'.format(12345) 418 ns: 'A{:,}'.format(12345) 437 ns: '\x80{:,}'.format(12345) 459 ns: '\u0100{:,}'.format(12345) 448 ns: '\U00010000{:,}'.format(12345) 76 ns: fmt="%s"; arg="abc"; fmt % arg 133 ns: fmt="%s"; arg=123; fmt % arg 118 ns: fmt="%s:"; arg="abc"; fmt % arg ---------- Added file: http://bugs.python.org/file25557/dont_overallocate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 04:27:04 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 13 May 2012 02:27:04 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336428561.46.0.842580483885.issue14744@psf.upfronthosting.co.za> Message-ID: <1336876024.73.0.115526030667.issue14744@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file25558/benchmark.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 04:55:21 2012 From: report at bugs.python.org (Julien Courteau) Date: Sun, 13 May 2012 02:55:21 +0000 Subject: [issue13400] packaging: build command should have options to control byte-compilation In-Reply-To: <1321281623.21.0.854677924579.issue13400@psf.upfronthosting.co.za> Message-ID: <1336877721.24.0.664663036943.issue13400@psf.upfronthosting.co.za> Julien Courteau added the comment: Here is the last proposition of Eric done at the last Montreal Sprint (May 12): --no-byte-compile -> No *.pyc and *.pyo --byte-compile=b -> Only *.pyc --byte-compile=b,o -> *.pyc and *.pyo (with docstrings) --byte-compile=b,oo -> *.pyc and *.pyo (without docstrings) --byte-compile=o -> Only *.pyo (with docstrings) --byte-compile=oo -> Only *.pyo (without docstrings) --byte-compile=o,oo -> Error The parameters are symetric with the -B, -o and -oo of the python command. ---------- nosy: +Julien.Courteau _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 06:16:46 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 13 May 2012 04:16:46 +0000 Subject: [issue13857] Add textwrap.indent() as counterpart to textwrap.dedent() In-Reply-To: <1327462635.84.0.618726818638.issue13857@psf.upfronthosting.co.za> Message-ID: <1336882606.92.0.181589243421.issue13857@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I'd like to see this enhancement as well. It seems that not even a TextWrapper is capable of a simple indent (because TextWrapper methods operate on "paragraphs" rather than lines). ---------- nosy: +cjerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 07:01:09 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 13 May 2012 05:01:09 +0000 Subject: [issue14794] slice.indices raises OverflowError In-Reply-To: <1336863098.54.0.753598684211.issue14794@psf.upfronthosting.co.za> Message-ID: <1336885269.18.0.0468175372552.issue14794@psf.upfronthosting.co.za> ?ric Araujo added the comment: > This seems to have been fixed as of 3.2.3 (as shipped with Ubuntu Precise) Just a note: you can?t really trust the behavior of Python shipped by Debian or derivative systems because doko (the Debian Python maintainer) backports changes to released versions, which means that Debian?s 3.2.3 may not always behave as python.org?s 3.2.3. ---------- nosy: +eric.araujo resolution: fixed -> out of date stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 07:12:36 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 13 May 2012 05:12:36 +0000 Subject: [issue13857] Add textwrap.indent() as counterpart to textwrap.dedent() In-Reply-To: <1327462635.84.0.618726818638.issue13857@psf.upfronthosting.co.za> Message-ID: <1336885956.46.0.730679424206.issue13857@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Should the function work for strings with non-Unix line endings? http://docs.python.org/dev/py3k/reference/lexical_analysis.html#physical-lines For example, should indent("abc\r\n", "") return the same string, and should "\r\n" get indented by default? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 10:02:22 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 May 2012 08:02:22 +0000 Subject: [issue9120] Reduce pickle size for an empty set In-Reply-To: <1277839720.0.0.346517516652.issue9120@psf.upfronthosting.co.za> Message-ID: <1336896142.2.0.47159835153.issue9120@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ok, so I'm closing it. ---------- nosy: +loewis resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 10:06:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 May 2012 08:06:45 +0000 Subject: [issue14366] Supporting lzma compression in zip files In-Reply-To: <1332112236.1.0.964135054036.issue14366@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset fccdcd83708a by Martin v. L?wis in branch 'default': Issue #14366: Support lzma compression in zip files. http://hg.python.org/cpython/rev/fccdcd83708a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 10:07:17 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 May 2012 08:07:17 +0000 Subject: [issue14366] Supporting lzma compression in zip files In-Reply-To: <1332112236.1.0.964135054036.issue14366@psf.upfronthosting.co.za> Message-ID: <1336896437.37.0.126088443854.issue14366@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 11:04:01 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 May 2012 09:04:01 +0000 Subject: [issue14793] broken grammar in Built-in Types doc Message-ID: New submission from Roundup Robot : New changeset e0dcd732055f by Sandro Tosi in branch '3.2': Issue #14793: fix grammar in bytes object paragraph; patch by Tshepang Lekhonkhobe http://hg.python.org/cpython/rev/e0dcd732055f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 11:05:51 2012 From: report at bugs.python.org (Sandro Tosi) Date: Sun, 13 May 2012 09:05:51 +0000 Subject: [issue14793] broken grammar in Built-in Types doc In-Reply-To: Message-ID: <1336899951.71.0.536383324421.issue14793@psf.upfronthosting.co.za> Sandro Tosi added the comment: Committed, thanks for the patch. For next times, please invest even a small amount of time describing why you opened the issue and what the patch fixes: it's definitely nicer not having to infer it from the diff. ---------- nosy: +sandro.tosi resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 11:56:38 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 13 May 2012 09:56:38 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336876009.15.0.759788654308.issue14744@psf.upfronthosting.co.za> Message-ID: <1336902865.3347.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > When it's possible to not overallocate, the speed up is around 10% for > short strings (I suppose that it's much better to longer strings). Well, please post a benchmark for long strings, then :-) I think 10% on a micro-benchmark is not worth the complication. This code is already complicated enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 12:11:07 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sun, 13 May 2012 10:11:07 +0000 Subject: [issue14732] PEP 3121 Refactoring applied to _csv module In-Reply-To: <1336247238.98.0.79082288942.issue14732@psf.upfronthosting.co.za> Message-ID: <1336903867.94.0.816360765642.issue14732@psf.upfronthosting.co.za> Changes by Robin Schreiber : Added file: http://bugs.python.org/file25559/csv_pep3121_fix1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 12:12:57 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 May 2012 10:12:57 +0000 Subject: [issue14366] Supporting lzma compression in zip files In-Reply-To: <1336896437.37.0.126088443854.issue14366@psf.upfronthosting.co.za> Message-ID: <1336904062.3172.8.camel@raxxla> Serhiy Storchaka added the comment: Thank you, Martin. Both of these patches basically your merit. Maybe take a look also at the small patches to issue14315 and issue10376? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 12:52:36 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 13 May 2012 10:52:36 +0000 Subject: [issue14773] fwalk breaks on dangling symlinks In-Reply-To: <1336678120.54.0.411663637267.issue14773@psf.upfronthosting.co.za> Message-ID: <1336906356.66.0.778590240811.issue14773@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: > Just to stress it once more: a fwalk that _ignores_ dangling symlinks is worthless for rmtree. And wasn't rmtree the initial reason to implement fwalk in the first place? ;) Indeed, my bad :-) > So I've changed the patch to ignore everything missing except for dangling links (which throw unfortunately the same exception). Looks good to me. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 14:29:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 May 2012 12:29:43 +0000 Subject: [issue14732] PEP 3121 Refactoring applied to _csv module In-Reply-To: <1336247238.98.0.79082288942.issue14732@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 90cf321615e5 by Antoine Pitrou in branch 'default': Remove Skip from the csv experts (see issue #14732). http://hg.python.org/devguide/rev/90cf321615e5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 17:25:57 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 13 May 2012 15:25:57 +0000 Subject: [issue14795] Pdb incorrectly handles a method breakpoint when module not imported Message-ID: <1336922756.85.0.281707317817.issue14795@psf.upfronthosting.co.za> New submission from Xavier de Gaye : In the following test, breakpoint 2 is set incorrectly at line 1 and pdb does not know how to set a breakpoint on method C.c_foo. However setting those two breakpoints on both methods is ok after the class definition has been executed. === main.py ================================= def foo(): pass class C: def c_foo(self): pass def foo(self): pass foo() ================================================= $ python3.1 -m pdb main.py > /path_to/main.py(1)() -> def foo(): (Pdb) import sys; print(sys.version) 3.1.2 (r312:79147, Apr 4 2010, 17:46:48) [GCC 4.3.2] (Pdb) break foo Breakpoint 1 at /path_to/main.py:1 (Pdb) break C.foo Breakpoint 2 at /path_to/main.py:1 (Pdb) break C.c_foo *** The specified object 'C.c_foo' is not a function or was not found along sys.path. (Pdb) break 10 Breakpoint 3 at /path_to/main.py:10 (Pdb) continue > /path_to/main.py(10)() -> foo() (Pdb) break C.foo Breakpoint 4 at /path_to/main.py:7 (Pdb) break C.c_foo Breakpoint 5 at /path_to/main.py:5 (Pdb) quit ================================================= The attached patch fixes the problem. The patch includes a test case. ---------- components: Library (Lib) files: pdb_default.patch keywords: patch messages: 160517 nosy: xdegaye priority: normal severity: normal status: open title: Pdb incorrectly handles a method breakpoint when module not imported type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25560/pdb_default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 17:30:04 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 13 May 2012 15:30:04 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1331810146.14.0.995585507713.issue14315@psf.upfronthosting.co.za> Message-ID: <1336923004.37.0.803895428558.issue14315@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 17:48:50 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 13 May 2012 15:48:50 +0000 Subject: [issue14751] Pdb does not stop at a breakpoint In-Reply-To: <1336482018.48.0.822650830886.issue14751@psf.upfronthosting.co.za> Message-ID: <1336924130.39.0.0508376598271.issue14751@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Uploaded pdb_default_2.patch that corrects the initial patch: the trace function must be set in all frames whose co_filename is the breakpoint file name and not just the first frame of this set. ---------- Added file: http://bugs.python.org/file25561/pdb_default_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 18:06:11 2012 From: report at bugs.python.org (Oleg Plakhotnyuk) Date: Sun, 13 May 2012 16:06:11 +0000 Subject: [issue14796] Calendar module test coverage improved Message-ID: <1336925171.3.0.599615693844.issue14796@psf.upfronthosting.co.za> New submission from Oleg Plakhotnyuk : I've improved calendar.py test coverage a bit. Before: 410 71% calendar (.../Lib/calendar.py) After: 410 77% calendar (.../Lib/calendar.py) ---------- components: Tests files: test_calendar.patch keywords: patch messages: 160519 nosy: Oleg.Plakhotnyuk, giampaolo.rodola, ncoghlan, rhettinger priority: normal severity: normal status: open title: Calendar module test coverage improved versions: Python 3.3 Added file: http://bugs.python.org/file25562/test_calendar.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 18:19:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 May 2012 16:19:45 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 38d7d944370e by Brian Curtin in branch 'default': Fix #13210. Port the Windows build from VS2008 to VS2010. http://hg.python.org/cpython/rev/38d7d944370e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 18:26:34 2012 From: report at bugs.python.org (Brian Curtin) Date: Sun, 13 May 2012 16:26:34 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1336926394.2.0.450973745048.issue13210@psf.upfronthosting.co.za> Brian Curtin added the comment: What I just pushed has functioning debug and release builds for both 32 and 64 bit, and the tests introduce no new failures. As noted on python-dev, we may not have build slaves setup for this change yet, so the Windows builds may appear broken. I'll leave this open a bit until the infrastructure has caught up, and until any documentation is completed, which I may open a separate issue for. ---------- resolution: -> fixed stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 18:28:53 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 13 May 2012 16:28:53 +0000 Subject: [issue14796] Calendar module test coverage improved In-Reply-To: <1336925171.3.0.599615693844.issue14796@psf.upfronthosting.co.za> Message-ID: <1336926534.0.0.359551647714.issue14796@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 18:32:09 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 13 May 2012 16:32:09 +0000 Subject: [issue14797] Deprecate imp.find_module()/load_module() Message-ID: <1336926729.01.0.715234386918.issue14797@psf.upfronthosting.co.za> New submission from Brett Cannon : With importlib.find_loader() now implemented, imp.find_module() (and its companion, imp.load_module()) can go away and stop inflicting their bad API upon the world. The trick, though, is fixing code that uses the API. That means pkgutil, multiprocessing.forking, modulefinder, and idlelib.EditorWindow all need to be patched to stop using imp.find_module()/load_module(). ---------- components: Library (Lib) messages: 160522 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: Deprecate imp.find_module()/load_module() type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 18:32:23 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 13 May 2012 16:32:23 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1336926743.18.0.396453558752.issue13959@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- dependencies: +Deprecate imp.find_module()/load_module() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 18:35:07 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 13 May 2012 16:35:07 +0000 Subject: [issue14797] Deprecate imp.find_module()/load_module() In-Reply-To: <1336926729.01.0.715234386918.issue14797@psf.upfronthosting.co.za> Message-ID: <1336926907.01.0.446955718935.issue14797@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 18:35:45 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 13 May 2012 16:35:45 +0000 Subject: [issue14796] Calendar module test coverage improved In-Reply-To: <1336925171.3.0.599615693844.issue14796@psf.upfronthosting.co.za> Message-ID: <1336926945.37.0.0431264444091.issue14796@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 18:39:00 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 13 May 2012 16:39:00 +0000 Subject: [issue14798] pyclbr raises KeyError when the prefix of a dotted name is not a package Message-ID: <1336927140.56.0.342713229106.issue14798@psf.upfronthosting.co.za> New submission from Xavier de Gaye : pyclbr must raise ImportError instead of KeyError. The attached patch fixes the problem. A test case is included. ---------- components: Library (Lib) files: pdb_default.patch keywords: patch messages: 160523 nosy: xdegaye priority: normal severity: normal status: open title: pyclbr raises KeyError when the prefix of a dotted name is not a package type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25563/pdb_default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 19:04:28 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 May 2012 17:04:28 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 59870239813c by Brett Cannon in branch 'default': Issue #13959: Document imp.find_module/load_module as deprecated. http://hg.python.org/cpython/rev/59870239813c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 19:07:22 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 13 May 2012 17:07:22 +0000 Subject: [issue14797] Deprecate imp.find_module()/load_module() In-Reply-To: <1336926729.01.0.715234386918.issue14797@psf.upfronthosting.co.za> Message-ID: <1336928842.28.0.923656073755.issue14797@psf.upfronthosting.co.za> Brett Cannon added the comment: http://hg.python.org/lookup/59870239813c documents imp.find_module/load_module as deprecated w/o actually raising the deprecation. The code works fine, but the API is just crap. So in the name of ease of transition (and my own personal sanity), I didn't go full-blown deprecation. The remaining code that uses imp.find_module() in the stdlib uses the API's unique properties (e.g. executing under a different name in multiprocessing) or directly exposes the API (e.g. pkgutil and modulefinder). As for idle, I don't run the tool so I don't feel like editing the code and getting it wrong. ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 19:07:54 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 13 May 2012 17:07:54 +0000 Subject: [issue14797] Deprecate imp.find_module()/load_module() In-Reply-To: <1336926729.01.0.715234386918.issue14797@psf.upfronthosting.co.za> Message-ID: <1336928874.83.0.0862032997954.issue14797@psf.upfronthosting.co.za> Brett Cannon added the comment: BTW, I'm leaving this issue open in case someone wants to take a stab and removing the uses of imp.find_module()/load_module() from the stdlb. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 19:13:39 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 13 May 2012 17:13:39 +0000 Subject: [issue14796] Calendar module test coverage improved In-Reply-To: <1336925171.3.0.599615693844.issue14796@psf.upfronthosting.co.za> Message-ID: <1336929219.82.0.975980641531.issue14796@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the patch. There are a couple of things I'd change, which I or someone could do while committing if you prefer, but if you'd like to tune up the patch yourself that would be great. The first is that I'd break up the tests that run more than one test into separate test methods (test_formatweekheader, test_formatmonthname, test_output_htmlcalendar). The second is that the exception tests can be written more compactly (and IMO more legibly) like this: def test_illegal_month_reported(self): with self.assertRaisesRegex(calendar.IllegalMonthError, '65'): calendar.monthrange(2004, 65) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 19:18:17 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 May 2012 17:18:17 +0000 Subject: [issue14770] Minor documentation fixes In-Reply-To: <1336647684.02.0.112519558227.issue14770@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 9d2a1f35421d by Ezio Melotti in branch '2.7': #14770: improve the library FAQ. http://hg.python.org/cpython/rev/9d2a1f35421d New changeset 7a046f1ddd07 by Ezio Melotti in branch '3.2': #14770: improve the library FAQ. http://hg.python.org/cpython/rev/7a046f1ddd07 New changeset 59fd56c1be0d by Ezio Melotti in branch 'default': #14770: merge with 3.2. http://hg.python.org/cpython/rev/59fd56c1be0d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 19:19:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 May 2012 17:19:50 +0000 Subject: [issue14770] Minor documentation fixes In-Reply-To: <1336647684.02.0.112519558227.issue14770@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset bf3cb58dcfe7 by Ezio Melotti in branch '2.7': #14770: backport a couple of changes from 3.x. http://hg.python.org/cpython/rev/bf3cb58dcfe7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 19:23:43 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 13 May 2012 17:23:43 +0000 Subject: [issue14770] Minor documentation fixes In-Reply-To: <1336647684.02.0.112519558227.issue14770@psf.upfronthosting.co.za> Message-ID: <1336929823.41.0.733293379633.issue14770@psf.upfronthosting.co.za> Ezio Melotti added the comment: I addressed ?ric comments and committed the patch. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 19:31:33 2012 From: report at bugs.python.org (Paul Upchurch) Date: Sun, 13 May 2012 17:31:33 +0000 Subject: [issue14794] slice.indices raises OverflowError In-Reply-To: <1336863098.54.0.753598684211.issue14794@psf.upfronthosting.co.za> Message-ID: <1336930293.06.0.72549173506.issue14794@psf.upfronthosting.co.za> Paul Upchurch added the comment: That's true; it doesn't work with today's downloads from python.org. The version I tested was win32 but I don't think that should matter. Python has always supported large numbers on 32-bit OSs. My observations: [1] Debian Wheezy, python3.2, 3.2.3~rc2-1: Fail [2] Debian Wheezy, python2.7, 2.7.3~rc2-2.1: Fail [3] python.org, python3.3, 3.3.0a3: Fail [4] python.org, python3.2, 3.2.3: Fail I'll compile 64-bit linux from source and try that. [1] Python 3.2.3rc2 (default, Mar 21 2012, 06:59:51) [GCC 4.6.3] on linux2 [2] Python 2.7.3rc2 (default, Apr 22 2012, 22:35:38) [GCC 4.6.3] on linux2 [3] Python 3.3.0a3 (default, May 1 2012, 16:25:20) [MSC v.1500 32 bit (Intel)] on win32 [4] Python 3.2.3 (default, Apr 11 2012, 07:15:24) [MSC v.1500 32 bit (Intel)] on win32 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 19:32:44 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 13 May 2012 17:32:44 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1336930364.89.0.160916456252.issue13210@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: All the old .vcproj files are still there. Probably not useful since the .sln file has been upgraded to VisualStudio 2010. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 19:34:44 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 May 2012 17:34:44 +0000 Subject: [issue6818] remove/delete method for zipfile/tarfile objects In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za> Message-ID: <1336930484.58.0.74135305991.issue6818@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Yuval, can you please submit a contributor agreement? See http://www.python.org/psf/contrib/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 19:36:56 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 May 2012 17:36:56 +0000 Subject: [issue6818] remove/delete method for zipfile/tarfile objects In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za> Message-ID: <1336930616.84.0.846534507612.issue6818@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As for adding yourself to the CC list: notice the string "ubershmekel" appearing in the "CC" field of http://bugs.python.org/review/6818/show. It means that you are already on the CC list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 19:40:30 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 May 2012 17:40:30 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 924c178c0d1d by Brian Curtin in branch 'default': Move out VS9 project files to PC\VS9.0 folder. Fixes #13210 http://hg.python.org/cpython/rev/924c178c0d1d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 19:42:06 2012 From: report at bugs.python.org (Brian Curtin) Date: Sun, 13 May 2012 17:42:06 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1336930926.84.0.829642371.issue13210@psf.upfronthosting.co.za> Brian Curtin added the comment: Thanks for noticing. I moved them out to PC\VS9.0 rather than outright deleting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 19:53:28 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 May 2012 17:53:28 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset ddcc8ee680d7 by Charles-Fran?ois Natali in branch 'default': Issue #14532: Add a secure_compare() helper to the hmac module, to mitigate http://hg.python.org/cpython/rev/ddcc8ee680d7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 19:55:27 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 May 2012 17:55:27 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1331810146.14.0.995585507713.issue14315@psf.upfronthosting.co.za> Message-ID: <1336931727.45.0.383824329118.issue14315@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file25564/zipfile_extra_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 19:58:53 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 May 2012 17:58:53 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1331810146.14.0.995585507713.issue14315@psf.upfronthosting.co.za> Message-ID: <1336931933.83.0.17014569472.issue14315@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Serhiy: can you please provide a unit test? The OP's test case is unsuitable because of both size and copyright. As for the actual issue: the extra data (type 0xcafe) is apparently added by jar tools to make the jar file executable: http://www.androidadb.com/source/commons-compress-1.1-src/src/main/java/org/apache/commons/compress/archivers/zip/JarMarker.java.html ISTM that the extra 0 byte is in clear violation of the ZIP specification, which says that there always be type+length headers, followed by length data. So if the length is 0, there ought not to be any data. I don't buy the "padding" argument, since a) the spec is silent on any padding, and b) for alignment reasons, it's not plausible to add any padding, since it is aligned fine without this padding, and unaligned with the padding. I can sympathize with the desire to accept the zipfile, anyway (i.e. despite it being broken). At the same time, I also think that Python should not let errors pass silently. So as a way out, I propose that the ZipFile class gains a "strict" attribute, indicating whether "acceptable" violations of the spec are ignored or reported as exceptions. So -1 on the patch as it stands (but thanks for the analysis). ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 20:06:53 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 May 2012 18:06:53 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1336931933.83.0.17014569472.issue14315@psf.upfronthosting.co.za> Message-ID: <1336932566.3172.281.camel@raxxla> Serhiy Storchaka added the comment: > Serhiy: can you please provide a unit test? The OP's test case is unsuitable because of both size and copyright. I provided the test several minutes ago. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 20:08:23 2012 From: report at bugs.python.org (Oleg Plakhotnyuk) Date: Sun, 13 May 2012 18:08:23 +0000 Subject: [issue14796] Calendar module test coverage improved In-Reply-To: <1336925171.3.0.599615693844.issue14796@psf.upfronthosting.co.za> Message-ID: <1336932503.15.0.548486455632.issue14796@psf.upfronthosting.co.za> Oleg Plakhotnyuk added the comment: Thanks for the review. I'll happily tune the patch myself. Just when I have some spare time again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 20:12:32 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 13 May 2012 18:12:32 +0000 Subject: [issue14797] Deprecate imp.find_module()/load_module() In-Reply-To: <1336926729.01.0.715234386918.issue14797@psf.upfronthosting.co.za> Message-ID: <1336932752.14.0.471268570136.issue14797@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 20:27:07 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 May 2012 18:27:07 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1336931933.83.0.17014569472.issue14315@psf.upfronthosting.co.za> Message-ID: <1336933783.3172.295.camel@raxxla> Serhiy Storchaka added the comment: > I can sympathize with the desire to accept the zipfile, anyway (i.e. despite it being broken). At the same time, I also think that Python should not let errors pass silently. I do not know other implementation of ZIP, which output an error or a warning on such files. The fact is that such files exist in the wild world. > So as a way out, I propose that the ZipFile class gains a "strict" attribute, indicating whether "acceptable" violations of the spec are ignored or reported as exceptions. It is a not easy task (and unnecessary, I suppose). Now zipfile ignores many errors (for example, it completely ignores local file headers). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 20:32:04 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 May 2012 18:32:04 +0000 Subject: [issue10376] ZipFile unzip is unbuffered In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za> Message-ID: <1336933924.99.0.621640368403.issue10376@psf.upfronthosting.co.za> Changes by Martin v. L?wis : Added file: http://bugs.python.org/file25565/zipfile_optimize_read.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 20:36:02 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 May 2012 18:36:02 +0000 Subject: [issue10376] ZipFile unzip is unbuffered In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za> Message-ID: <1336934162.37.0.659722681158.issue10376@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you, Martin, now I understood why not work Rietveld review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 20:50:19 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 May 2012 18:50:19 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1332785811.84.0.616508221107.issue14417@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 93748e2d64e3 by Antoine Pitrou in branch 'default': Issue #14417: Mutating a dict during lookup now restarts the lookup instead of raising a RuntimeError (undoes issue #14205). http://hg.python.org/cpython/rev/93748e2d64e3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 20:50:19 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 May 2012 18:50:19 +0000 Subject: [issue14205] Raise an error if a dict is modified during a lookup In-Reply-To: <1330982395.54.0.88630927528.issue14205@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 93748e2d64e3 by Antoine Pitrou in branch 'default': Issue #14417: Mutating a dict during lookup now restarts the lookup instead of raising a RuntimeError (undoes issue #14205). http://hg.python.org/cpython/rev/93748e2d64e3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 20:50:56 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 13 May 2012 18:50:56 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336935056.36.0.0694305345127.issue14777@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Patch looks good for me, works fine. I think it can be applied to 2.7 as well. There are only problem: I don't know how to make test for it without using external tools like xclip or ctypes bindings for X so library. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 20:54:53 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 13 May 2012 18:54:53 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1332785811.84.0.616508221107.issue14417@psf.upfronthosting.co.za> Message-ID: <1336935293.15.0.586422756454.issue14417@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I have committed an updated patch, with a fix to Victor's test. I don't think anything else remains to be done. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 20:55:43 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 13 May 2012 18:55:43 +0000 Subject: [issue14799] Tkinter ttk tests hang on linux Message-ID: <1336935343.12.0.855604727116.issue14799@psf.upfronthosting.co.za> New submission from Andrew Svetlov : By default python doesn't run full test suite, but regrtest accepts -u parameter. The simplest way to reproduce is: $ ./python -m test.regrtest -u gui test_ttk_guionly ---------- components: Tkinter messages: 160547 nosy: asvetlov priority: critical severity: normal status: open title: Tkinter ttk tests hang on linux type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 20:55:50 2012 From: report at bugs.python.org (Thomas Kluyver) Date: Sun, 13 May 2012 18:55:50 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336935350.25.0.856045570669.issue14777@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Indeed, and there don't seem to be any other tests for the clipboard functionality. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:00:50 2012 From: report at bugs.python.org (James Lu) Date: Sun, 13 May 2012 19:00:50 +0000 Subject: [issue14667] No IDLE In-Reply-To: <1335416555.9.0.950503401355.issue14667@psf.upfronthosting.co.za> Message-ID: James Lu added the comment: thanks! james On Thu, Apr 26, 2012 at 1:02 AM, Brian Curtin wrote: > > Brian Curtin added the comment: > > James, since you attached a Windows executable I'll assume that's the > platform you're on. > > Try the following: > > 1. Open the Start menu > 2. Choose "All Programs" (or "Programs" on XP, I think) > 3. Scroll to where you see "Python x.y", where you'll see one or more > entries depending on how many versions you have installed. > 4. Choose the version you want to open, e.g., Python 2.7 > 5. You should see "IDLE (Python GUI)" in the menu. Run it, that's IDLE. > > Is there an issue with any of those steps? > > ---------- > nosy: +brian.curtin > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:03:38 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 May 2012 19:03:38 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1336933783.3172.295.camel@raxxla> Message-ID: <4FB00589.5010006@v.loewis.de> Martin v. L?wis added the comment: >> So as a way out, I propose that the ZipFile class gains a "strict" >> attribute, indicating whether "acceptable" violations of the spec >> are ignored or reported as exceptions. > > It is a not easy task (and unnecessary, I suppose). Now zipfile > ignores many errors (for example, it completely ignores local file > headers). Why do you consider this difficult? Just add a "strict" flag, make it false by default, and raise an error if there is any unparsable extra data. I'm not asking that you implement a complete validity check for all aspects of the zip spec - just that there is a mode where it continues to raise an exception as it currently does (but with a better exception). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:04:32 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 13 May 2012 19:04:32 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336935872.98.0.927409276043.issue14777@psf.upfronthosting.co.za> Andrew Svetlov added the comment: You are right: there are no tests as well as for the most part of tkinter. Why don't make it if possible? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:13:29 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 May 2012 19:13:29 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336936409.63.0.403639332491.issue14777@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm skeptical about the patch. In both 2.7 and 3.x, clipboard_get returns a Unicode string, yet it fails to decode it properly. So I think this is the bug that ought to be fixed (using the proper encoding). Defaulting to UTF8_STRING is a new feature, IMO, and shouldn't be done for 2.7 (or 3.2). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:18:01 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 May 2012 19:18:01 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <4FB00589.5010006@v.loewis.de> Message-ID: <1336936838.3172.305.camel@raxxla> Serhiy Storchaka added the comment: > Just add a "strict" flag, make > it false by default, and raise an error if there is any unparsable > extra data. If the module does not actually checks the correctness of all (including local file headers, which now it ignores), it will be a false promise. And I don't understand who these checks are needed at all. Note that the parameter "strict" in htmlparser is considered to be obsolete. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:22:24 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 13 May 2012 19:22:24 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336936944.61.0.312963161782.issue14777@psf.upfronthosting.co.za> Ned Deily added the comment: Martin, is that a way for _tkinter to know whether the result returned from Tcl/Tk is an encoded string or not in this case? With regard to the patch, it would be better to cache the results of the first-time call to get the windowingsystem value so that we don't have to make two calls down into Tcl for each clipboard_get. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:22:51 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 13 May 2012 19:22:51 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336936971.24.0.15027074034.issue14777@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- Removed message: http://bugs.python.org/msg160554 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:23:05 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 13 May 2012 19:23:05 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336936985.57.0.709871612975.issue14777@psf.upfronthosting.co.za> Ned Deily added the comment: Martin, is there a way for _tkinter to know whether the result returned from Tcl/Tk is an encoded string or not in this case? With regard to the patch, it would be better to cache the results of the first-time call to get the windowingsystem value so that we don't have to make two calls down into Tcl for each clipboard_get. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:29:56 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 May 2012 19:29:56 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336771543.13.0.989255606419.issue14777@psf.upfronthosting.co.za> Message-ID: <1336937555.3172.316.camel@raxxla> Serhiy Storchaka added the comment: ? ??, 2012-05-11 ? 21:25 +0000, Thomas Kluyver ????: > So far, I've not found any case on X where STRING works but UTF8_STRING doesn't. Perhaps there will be problems with the old (very old) closed source software. A few years ago (in Debian Sarge) even xsel did not work with the non-ascii strings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:33:40 2012 From: report at bugs.python.org (Thomas Kluyver) Date: Sun, 13 May 2012 19:33:40 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336937620.25.0.911124372921.issue14777@psf.upfronthosting.co.za> Thomas Kluyver added the comment: But the encoding used seemingly depends on the source application - Geany (GTK 2, I think) seemingly sends UTF8 text anyway, whereas Firefox escapes the unicode character. So I don't think we can correctly decode the STRING value in all cases. The Tk documentation describes UTF8_STRING as being the "most useful" type on modern X11. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:37:36 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 13 May 2012 19:37:36 +0000 Subject: [issue14794] slice.indices raises OverflowError In-Reply-To: <1336863098.54.0.753598684211.issue14794@psf.upfronthosting.co.za> Message-ID: <1336937856.67.0.992990043768.issue14794@psf.upfronthosting.co.za> Hynek Schlawack added the comment: I did a little compiling party with official releases and all permutations of Linux, OS X x 3.2.2, 3.2.3 worked. Both ran on 64bit (Linux in a VirtualBox). Python 3.2.2 (default, May 13 2012, 21:24:38) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> slice(0,90000,None).indices(12600000000) (0, 90000, 1) Python 3.2.2 (default, May 13 2012, 21:33:57) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> slice(0,90000,None).indices(12600000000) (0, 90000, 1) Can we narrow it down to 32bit hosts/OS? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:38:10 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 May 2012 19:38:10 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336937620.25.0.911124372921.issue14777@psf.upfronthosting.co.za> Message-ID: <1336938049.3172.318.camel@raxxla> Serhiy Storchaka added the comment: > But the encoding used seemingly depends on the source application - Geany (GTK 2, I think) seemingly sends UTF8 text anyway, whereas Firefox escapes the unicode character. So I don't think we can correctly decode the STRING value in all cases. Agree. Opera sends 'abc?' literally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:40:24 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 May 2012 19:40:24 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336936944.61.0.312963161782.issue14777@psf.upfronthosting.co.za> Message-ID: <4FB00E27.8020904@v.loewis.de> Martin v. L?wis added the comment: > Martin, is that a way for _tkinter to know whether the result > returned from Tcl/Tk is an encoded string or not in this case? Off-hand, I don't know. I suppose there is a way to do this correctly, but one might have to dig through many layers of software to find out what that way is. > With regard to the patch, it would be better to cache the results of > the first-time call to get the windowingsystem value so that we don't > have to make two calls down into Tcl for each clipboard_get. That also. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:43:03 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 13 May 2012 19:43:03 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336937620.25.0.911124372921.issue14777@psf.upfronthosting.co.za> Message-ID: <4FB00EC5.5040409@v.loewis.de> Martin v. L?wis added the comment: > But the encoding used seemingly depends on the source application - > Geany (GTK 2, I think) seemingly sends UTF8 text anyway, whereas > Firefox escapes the unicode character. So I don't think we can > correctly decode the STRING value in all cases. Ah, ok. IIUC, support for UTF8_STRING would also be in the realm of the source application, right? If so, I think we should use something more involved where we try UTF8_STRING first, and fall back to STRING if the application doesn't support that. This I could also accept for 2.7, since it "shouldn't" have a potential for breakage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:47:48 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 13 May 2012 19:47:48 +0000 Subject: [issue14797] Deprecate imp.find_module()/load_module() In-Reply-To: <1336926729.01.0.715234386918.issue14797@psf.upfronthosting.co.za> Message-ID: <1336938468.23.0.978156029907.issue14797@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:58:22 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 13 May 2012 19:58:22 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336939102.09.0.554603775796.issue14777@psf.upfronthosting.co.za> Ned Deily added the comment: +1 to Martin's proposal ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 21:59:44 2012 From: report at bugs.python.org (Thomas Kluyver) Date: Sun, 13 May 2012 19:59:44 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336939184.21.0.7089566513.issue14777@psf.upfronthosting.co.za> Thomas Kluyver added the comment: OK, I'll produce an updated patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 22:03:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 13 May 2012 20:03:27 +0000 Subject: [issue12098] Child process running as debug on Windows In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za> Message-ID: <1336939407.33.0.270213535116.issue12098@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 22:04:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 May 2012 20:04:27 +0000 Subject: [issue14245] float rounding examples in FAQ are outdated In-Reply-To: <1331372112.92.0.532785259032.issue14245@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2b2a7861255d by Mark Dickinson in branch '3.2': Issue #14245: Improve floating-point entry in FAQ. Thanks Zbyszek J?drzejewski-Szmek for some of the wording. http://hg.python.org/cpython/rev/2b2a7861255d New changeset a79b07e05d0d by Mark Dickinson in branch 'default': Issue #14245: Merge changes from 3.2. http://hg.python.org/cpython/rev/a79b07e05d0d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 22:10:29 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 13 May 2012 20:10:29 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336902865.3347.1.camel@localhost.localdomain> Message-ID: STINNER Victor added the comment: >> When it's possible to not overallocate, the speed up is around 10% for >> short strings (I suppose that it's much better to longer strings). > Well, please post a benchmark for long strings, then :-) Ok, here you have. I don't understand why results are so random. There is no performance regression, but there are interesting speed up. Original: 200 ns: L=10 ** 3; fmt="%s"; args="a" * L; fmt % args 370 ns: L=10 ** 4; fmt="%s"; args="a" * L; fmt % args 3.85 ms: L=10 ** 5; fmt="%s"; args="a" * L; fmt % args 334 ms: L=10 ** 6; fmt="%s"; args="a" * L; fmt % args 2.87 ms: L=10 ** 7; fmt="%s"; args="a" * L; fmt % args 23.9 ms: L=10 ** 8; fmt="%s"; args="a" * L; fmt % args Patched: 120 ns (-40%): L=10 ** 3; fmt="%s"; args="a" * L; fmt % args 276 ns (-25%): L=10 ** 4; fmt="%s"; args="a" * L; fmt % args 3.7 ms (-4%): L=10 ** 5; fmt="%s"; args="a" * L; fmt % args 67.6 ms (-80%): L=10 ** 6; fmt="%s"; args="a" * L; fmt % args 1.38 ms (-51%): L=10 ** 7; fmt="%s"; args="a" * L; fmt % args 23.5 ms (-2%): L=10 ** 8; fmt="%s"; args="a" * L; fmt % args ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 22:10:44 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 13 May 2012 20:10:44 +0000 Subject: [issue14245] float rounding examples in FAQ are outdated In-Reply-To: <1331372112.92.0.532785259032.issue14245@psf.upfronthosting.co.za> Message-ID: <1336939844.44.0.31161792086.issue14245@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks for all the feedback. I made another round of minor edits to the latest version and committed the result. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 22:14:33 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 May 2012 20:14:33 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336876009.15.0.759788654308.issue14744@psf.upfronthosting.co.za> Message-ID: <1336940228.3172.337.camel@raxxla> Serhiy Storchaka added the comment: Not quite honest contrexample: ./python -m timeit -s "f='[{}]'.format;s='A'*100" "f(s)" Python 3.3: 1000000 loops, best of 3: 1.67 usec per loop Python 3.3 + dont_overallocate.patch: 100000 loops, best of 3: 2.01 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 22:15:43 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 13 May 2012 20:15:43 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: Message-ID: <1336940008.3373.4.camel@localhost.localdomain> Antoine Pitrou added the comment: > >> When it's possible to not overallocate, the speed up is around 10% for > >> short strings (I suppose that it's much better to longer strings). > > Well, please post a benchmark for long strings, then :-) > > Ok, here you have. I don't understand why results are so random. There > is no performance regression, but there are interesting speed up. Do you have anything more interesting than fmt="%s" ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 22:21:01 2012 From: report at bugs.python.org (Thomas Kluyver) Date: Sun, 13 May 2012 20:21:01 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336940461.02.0.447852391586.issue14777@psf.upfronthosting.co.za> Thomas Kluyver added the comment: As requested, the second version of the patch (x11-clipboard-try-utf8): - Caches the windowing system per object. The tk call to find the windowing system is made the first time clipboard_get or selection_get are called without specifying `type=`. - If using UTF8_STRING throws an error, it falls back to the default call with no type specified (i.e. STRING). ---------- Added file: http://bugs.python.org/file25566/x11-clipboard-try-utf8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 22:31:52 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 13 May 2012 20:31:52 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1336941112.54.0.752852271914.issue9260@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Does anyone else want to review this patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 22:34:33 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 13 May 2012 20:34:33 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336941273.34.0.753770807713.issue14777@psf.upfronthosting.co.za> Ned Deily added the comment: Not to bikeshed here but I think it would be better to cache the windowingsystem value at the module level since I assume an application could be calling clipboard_get on different tkinter objects and I don't there is any possibility that the windowingsystem value could vary within one interpreter invocation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 22:38:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 13 May 2012 20:38:33 +0000 Subject: [issue14624] Faster utf-16 decoder In-Reply-To: <1334869141.17.0.802149162715.issue14624@psf.upfronthosting.co.za> Message-ID: <1336941513.13.0.353596556039.issue14624@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New performance figures under 64 bit Linux, Intel Core i5-2500K @ 3.30GHz: vanilla 3.3 patched utf-16le 'A'*10000 1411 (+290%) 5504 utf-16le 'A'*9999+'\x80' 1368 (+263%) 4970 utf-16le 'A'*9999+'\u0100' 1145 (+151%) 2871 utf-16le 'A'*9999+'\u8000' 1144 (+151%) 2870 utf-16le 'A'*9999+'\U00010000' 1164 (+154%) 2957 utf-16le '\x80'*10000 1403 (+271%) 5209 utf-16le '\x80'+'A'*9999 1406 (+272%) 5235 utf-16le '\x80'*9999+'\u0100' 1138 (+138%) 2713 utf-16le '\x80'*9999+'\u8000' 1138 (+139%) 2716 utf-16le '\x80'*9999+'\U00010000' 1155 (+151%) 2897 utf-16le '\u0100'*10000 1477 (+243%) 5062 utf-16le '\u0100'+'A'*9999 1478 (+243%) 5072 utf-16le '\u0100'+'\x80'*9999 1477 (+243%) 5062 utf-16le '\u0100'*9999+'\u8000' 1478 (+242%) 5055 utf-16le '\u0100'*9999+'\U00010000' 1201 (+131%) 2776 utf-16le '\u8000'*10000 246 (+347%) 1100 utf-16le '\u8000'+'A'*9999 1475 (+244%) 5069 utf-16le '\u8000'+'\x80'*9999 1474 (+243%) 5062 utf-16le '\u8000'+'\u0100'*9999 1473 (+243%) 5057 utf-16le '\u8000'*9999+'\U00010000' 236 (+295%) 932 utf-16le '\U00010000'*10000 393 (+164%) 1039 utf-16le '\U00010000'+'A'*9999 1325 (+134%) 3106 utf-16le '\U00010000'+'\x80'*9999 1326 (+134%) 3103 utf-16le '\U00010000'+'\u0100'*9999 1326 (+134%) 3104 utf-16le '\U00010000'+'\u8000'*9999 253 (+331%) 1091 utf-16be 'A'*10000 1341 (+298%) 5342 utf-16be 'A'*9999+'\x80' 1305 (+275%) 4888 utf-16be 'A'*9999+'\u0100' 1101 (+157%) 2834 utf-16be 'A'*9999+'\u8000' 1102 (+157%) 2831 utf-16be 'A'*9999+'\U00010000' 1115 (+162%) 2917 utf-16be '\x80'*10000 1326 (+296%) 5253 utf-16be '\x80'+'A'*9999 1322 (+298%) 5258 utf-16be '\x80'*9999+'\u0100' 1088 (+156%) 2781 utf-16be '\x80'*9999+'\u8000' 1088 (+155%) 2770 utf-16be '\x80'*9999+'\U00010000' 1103 (+159%) 2854 utf-16be '\u0100'*10000 1344 (+221%) 4308 utf-16be '\u0100'+'A'*9999 1342 (+223%) 4330 utf-16be '\u0100'+'\x80'*9999 1343 (+221%) 4307 utf-16be '\u0100'*9999+'\u8000' 1343 (+221%) 4306 utf-16be '\u0100'*9999+'\U00010000' 1109 (+128%) 2529 utf-16be '\u8000'*10000 248 (+341%) 1094 utf-16be '\u8000'+'A'*9999 1340 (+223%) 4331 utf-16be '\u8000'+'\x80'*9999 1341 (+221%) 4307 utf-16be '\u8000'+'\u0100'*9999 1341 (+221%) 4309 utf-16be '\u8000'*9999+'\U00010000' 239 (+290%) 931 utf-16be '\U00010000'*10000 399 (+160%) 1037 utf-16be '\U00010000'+'A'*9999 1230 (+152%) 3101 utf-16be '\U00010000'+'\x80'*9999 1218 (+154%) 3095 utf-16be '\U00010000'+'\u0100'*9999 1220 (+154%) 3095 utf-16be '\U00010000'+'\u8000'*9999 257 (+318%) 1074 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 22:40:42 2012 From: report at bugs.python.org (Thomas Kluyver) Date: Sun, 13 May 2012 20:40:42 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336941642.15.0.435195447592.issue14777@psf.upfronthosting.co.za> Thomas Kluyver added the comment: I'm happy to put the cache at the module level, but I'll give other people a chance to express their views before I dive into the code again. I imagine most applications would only call clipboard_get() on one item, so it wouldn't matter. However, my own interest in this is from IPython, where we create a Tk object just to call clipboard_get() once, so a module level cache would be quicker, albeit only a tiny bit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 22:41:07 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 13 May 2012 20:41:07 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336428561.46.0.842580483885.issue14744@psf.upfronthosting.co.za> Message-ID: <1336941667.48.0.822202928386.issue14744@psf.upfronthosting.co.za> STINNER Victor added the comment: > Not quite honest contrexample I agree, this example is not honest :-) It's because of the magical value 100 used as initial size of the buffer. The speed is the same for shorter or longer strings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 22:49:03 2012 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 13 May 2012 20:49:03 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1336935293.15.0.586422756454.issue14417@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Thanks Antoine! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 22:49:51 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 May 2012 20:49:51 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336941273.34.0.753770807713.issue14777@psf.upfronthosting.co.za> Message-ID: <1336942350.3172.354.camel@raxxla> Serhiy Storchaka added the comment: > Not to bikeshed here but I think it would be better to cache the windowingsystem value at the module level since I assume an application could be calling clipboard_get on different tkinter objects and I don't there is any possibility that the windowingsystem value could vary within one interpreter invocation. Why Misc.tk is not a module level variable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 22:52:53 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 13 May 2012 20:52:53 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1336942373.96.0.00750650912806.issue9260@psf.upfronthosting.co.za> Brett Cannon added the comment: I don't feel the need to, but I can in a few days if you want me to (just let me know if you do). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 23:18:27 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 May 2012 21:18:27 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336428561.46.0.842580483885.issue14744@psf.upfronthosting.co.za> Message-ID: <1336943907.11.0.590889851787.issue14744@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It seems to me that the proposed changes are too tricky and too dirty for such a modest gain. It seems to me, this effect can be achieved easier (special-casing "%s" and "{}" to return str(arg)?). If you want to get really impressive results, try to compile a pattern into an optimized internal representation and cache it (as in the struct module). This completely different approach may work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 23:26:53 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 13 May 2012 21:26:53 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336428561.46.0.842580483885.issue14744@psf.upfronthosting.co.za> Message-ID: <1336944413.83.0.861523463128.issue14744@psf.upfronthosting.co.za> STINNER Victor added the comment: > Do you have anything more interesting than fmt="%s" ? and > It seems to me that the proposed changes are too tricky and too dirty for such a modest gain. To be honest, I didn't write dont_overallocate.patch to speed up formatting strings, but it's a patch to prepare another change on str.format. The patch limits the overhead of _PyUnicodeWriter for str.format. I proposed the change as a separated patch because I prefer simple patches: they are easier to review and to benchmark. But I agree the speed up is less impressive :-) I also prefer small patches for practical reasons. It's not easy to exchange huge patches on the tracker and to manipulate them. I always hesitate to start a new HG repository for a specific issue. I will rewrite my format_writer-2.patch based on dont_overallocate.patch. It looks like you are waiting for the full patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 23:29:47 2012 From: report at bugs.python.org (Thomas Kluyver) Date: Sun, 13 May 2012 21:29:47 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336944588.0.0.370509546756.issue14777@psf.upfronthosting.co.za> Thomas Kluyver added the comment: The 3rd revision of the patch has the cache at the module level. It's a bit awkward, because there's no module level function to call to retrieve it (as far as I know), so it's exposed by objects which can call Tk. Also, serhiy pointed out a mistake in the 2nd revision, which is fixed ('selection' instead of 'clipboard'). ---------- Added file: http://bugs.python.org/file25567/x11-clipboard-try-utf8-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 13 23:32:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 13 May 2012 21:32:27 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336944413.83.0.861523463128.issue14744@psf.upfronthosting.co.za> Message-ID: <1336944612.3373.5.camel@localhost.localdomain> Antoine Pitrou added the comment: > I will rewrite my format_writer-2.patch based on > dont_overallocate.patch. It looks like you are waiting for the full > patch. Well, there's no point in committing the first patch if the second one doesn't give an interesting speedup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 01:42:05 2012 From: report at bugs.python.org (Chris Rebert) Date: Sun, 13 May 2012 23:42:05 +0000 Subject: [issue14187] add "function annotation" entry to Glossary In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za> Message-ID: <1336952525.51.0.806159673911.issue14187@psf.upfronthosting.co.za> Chris Rebert added the comment: Right, I can see how the 3rd paragraph has become tangential given the refined scope of the entry. What do people think about a separate entry: "annotation" Can refer to either a `function annotation` or some uses of `decorator`s. ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 01:45:42 2012 From: report at bugs.python.org (Chris Rebert) Date: Sun, 13 May 2012 23:45:42 +0000 Subject: [issue14187] add "function annotation" entry to Glossary In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za> Message-ID: <1336952742.71.0.74371633497.issue14187@psf.upfronthosting.co.za> Changes by Chris Rebert : Added file: http://bugs.python.org/file25568/function_annotation_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 01:53:40 2012 From: report at bugs.python.org (Paul Upchurch) Date: Sun, 13 May 2012 23:53:40 +0000 Subject: [issue14794] slice.indices raises OverflowError In-Reply-To: <1336863098.54.0.753598684211.issue14794@psf.upfronthosting.co.za> Message-ID: <1336953220.13.0.435103544035.issue14794@psf.upfronthosting.co.za> Paul Upchurch added the comment: The pre-built 64-bit Windows binaries from python.org works. Python 3.3.0a3 (default, May 1 2012, 16:46:00) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> slice(0,90000,None).indices(12600000000) (0, 90000, 1) Python 3.2.3 (default, Apr 11 2012, 07:12:16) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> slice(0,90000,None).indices(12600000000) (0, 90000, 1) I think this issue is settled. There are several possible actions for people that find this discussion through a web search. 1. Use Ubuntu 12.04 LTS 2. Compile a fresh copy of 3.2 or 3.3 from python.org. 3. Use a pre-built 3.2 or 3.3 64-bit Windows binary from python.org. 4. Wait for your Linux distribution to catch up. Hynek, ?ric: Thanks for your help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 01:53:45 2012 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 13 May 2012 23:53:45 +0000 Subject: [issue14800] stat.py constant comments + docstrings Message-ID: <1336953225.33.0.233761576766.issue14800@psf.upfronthosting.co.za> New submission from Giampaolo Rodola' : As per: http://mail.python.org/pipermail/python-ideas/2012-May/015112.html ---------- files: stat-comments.patch keywords: patch messages: 160584 nosy: giampaolo.rodola, terry.reedy priority: normal severity: normal status: open title: stat.py constant comments + docstrings Added file: http://bugs.python.org/file25569/stat-comments.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 02:13:34 2012 From: report at bugs.python.org (Peter Marheine) Date: Mon, 14 May 2012 00:13:34 +0000 Subject: [issue14801] ssize_t where size_t expected Message-ID: <1336954414.18.0.61439717267.issue14801@psf.upfronthosting.co.za> New submission from Peter Marheine : Cross-compiling the interpreter for a system without a definition for ssize_t fails in PyType_FromSpec (Object/typeobject.c:2380 in the 3.2.3 release, line 2409 in hg 6b8f34a1cb22). It appears the type of len should be corrected to size_t to match the signatures of strlen and memcpy. This fixes the compilation error. ---------- components: Interpreter Core messages: 160585 nosy: tari priority: normal severity: normal status: open title: ssize_t where size_t expected type: compile error versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 02:14:12 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 14 May 2012 00:14:12 +0000 Subject: [issue14616] subprocess docs should mention pipes.quote/shlex.quote In-Reply-To: <1334769157.78.0.557014485739.issue14616@psf.upfronthosting.co.za> Message-ID: <1336954452.59.0.243768509748.issue14616@psf.upfronthosting.co.za> Chris Rebert added the comment: Patch to mention shlex.quote() in the `subprocess` module's "Frequently Used Arguments" Warning box. Could perhaps be a separate Note, but that could be clutter-y. ---------- keywords: +patch Added file: http://bugs.python.org/file25570/subprocess_shlex_quote.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 02:22:34 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 14 May 2012 00:22:34 +0000 Subject: [issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za> Message-ID: <1336954954.04.0.876608966004.issue7839@psf.upfronthosting.co.za> Chris Rebert added the comment: Re: Nick's comments: Besides `close_fds`, what other Popen parameters currently have suboptimal defaults? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 02:40:22 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 14 May 2012 00:40:22 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336956022.69.0.328504373443.issue14777@psf.upfronthosting.co.za> Ned Deily added the comment: Serhiy, I don't know why Misc.Tk is not module level but it isn't so caching global attributes there isn't effective. However, upon further consideration, I take back my original suggestion of caching at the module level primarily because I can think of future scenarios where it might be possible that there are different windowing systems supported in the same Python instance. I now think the best solution is to cache at the Tk root object level; that appears to be a simple change to Thomas's 2nd revision. Sorry about that! Here is a fourth version (one for 3.x and one for 2.7) based on the second which includes the fix from the 3rd. I started to write a simple test for the clipboard functions but then realized that there doesn't seem to be a practical way to effectively test in a machine-independent way without destroying the contents of the Tk clipboard and hence the user's desktop clipboard, not a friendly thing to do. For example, the clipboard might contain a data type not supported by the platform's Tk, like pict data on OS X. So I'm not including the test here but it did verify that the attribute was being properly cached across multiple tkinter objects. Thanks to Thomas for the patch and to Serhiy for reviewing. By the way, Thomas, for your patch to be included, you should submit a PSF contributor agreement as described here: http://www.python.org/psf/contrib/. Once that is in place and if the patch looks good to everyone, I'll apply it. ---------- stage: -> patch review Added file: http://bugs.python.org/file25571/x11-clipboard-try-utf8-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 02:40:46 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 14 May 2012 00:40:46 +0000 Subject: [issue14777] Tkinter clipboard_get() decodes characters incorrectly In-Reply-To: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za> Message-ID: <1336956046.59.0.260788900183.issue14777@psf.upfronthosting.co.za> Changes by Ned Deily : Added file: http://bugs.python.org/file25572/x11-clipboard-try-utf8-4_27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 02:59:09 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 14 May 2012 00:59:09 +0000 Subject: [issue14187] add "function annotation" entry to Glossary In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za> Message-ID: <1336957149.41.0.436382010395.issue14187@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This looks fine. ?ric, please apply the v2 patch when you get a chance. ---------- assignee: rhettinger -> eric.araujo priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 03:20:41 2012 From: report at bugs.python.org (Meador Inge) Date: Mon, 14 May 2012 01:20:41 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1331810146.14.0.995585507713.issue14315@psf.upfronthosting.co.za> Message-ID: <1336958441.23.0.971269097314.issue14315@psf.upfronthosting.co.za> Meador Inge added the comment: This is definitely *not* a padding issue. The problem is that one of the records has an extra field of length 1: $ zipinfo -v bla.apk ... Central directory entry #3: --------------------------- There are an extra 16 bytes preceding this file. res/raw/ice.png offset of local header from start of archive: 1190 (000004A6h) bytes file system or operating system of origin: MS-DOS, OS/2 or NT FAT version of encoding software: 1.0 minimum file system compatibility required: MS-DOS, OS/2 or NT FAT minimum software version required to extract: 1.0 compression method: none (stored) file security status: not encrypted extended local header: no file last modified on (DOS date/time): 2012 Jan 13 15:30:08 32-bit CRC value (hex): f969abab compressed size: 26250 bytes uncompressed size: 26250 bytes length of filename: 15 characters length of extra field: 1 bytes length of file comment: 0 characters disk number on which file begins: disk 1 apparent file type: binary non-MSDOS external file attributes: 000000 hex MS-DOS file attributes (00 hex): none The central-directory extra field contains: There is no file comment. Our implementation can't deal with that because of the line that Terry pointed out: tp, ln = unpack(' _______________________________________ From report at bugs.python.org Mon May 14 03:52:22 2012 From: report at bugs.python.org (Meador Inge) Date: Mon, 14 May 2012 01:52:22 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1331810146.14.0.995585507713.issue14315@psf.upfronthosting.co.za> Message-ID: <1336960342.31.0.982419616422.issue14315@psf.upfronthosting.co.za> Meador Inge added the comment: FWIW, I think it will OK to just ignore extra fields that we can't interpret as according to the standard. The only one we currently care about is the "Zip64 extended information extra field". Also, other programs (including the Info-Zip tools) seem to mostly ignore these fields. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 05:29:34 2012 From: report at bugs.python.org (Yugang LIU) Date: Mon, 14 May 2012 03:29:34 +0000 Subject: [issue14786] htmlparser with tag br In-Reply-To: <1336841474.91.0.684060031665.issue14786@psf.upfronthosting.co.za> Message-ID: <4FB07C14.8020103@yahoo.cn> Yugang LIU added the comment: By HTML standard, it is not a bug. I will verify my code. Thanks for your reply. On 2012-05-13 0:51, Ezio Melotti wrote: > Ezio Melotti added the comment: > > The HTML you pasted looks valid to me -- the br element doesn't have an end tag and the HTML 4.01 standard explicitly says "Start tag: required, End tag: forbidden" [0]. > Why do you think this is a problem? > > [0]: http://www.w3.org/TR/html401/struct/text.html#edef-BR > > ---------- > assignee: -> ezio.melotti > components: +Library (Lib) -None > nosy: +ezio.melotti > resolution: -> invalid > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 05:57:25 2012 From: report at bugs.python.org (Minmin Gong) Date: Mon, 14 May 2012 03:57:25 +0000 Subject: [issue14802] Python 3.2 fail to compile with VC11 ARM configuration Message-ID: <1336967845.45.0.147430912977.issue14802@psf.upfronthosting.co.za> New submission from Minmin Gong : Windows ARM doesn't support full win32 api, e.g. no registry and winsock. So the python fail to compile with VC11 beta in ARM configuration. ---------- components: Interpreter Core messages: 160593 nosy: Minmin.Gong priority: normal severity: normal status: open title: Python 3.2 fail to compile with VC11 ARM configuration type: compile error versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 06:11:12 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 14 May 2012 04:11:12 +0000 Subject: [issue14786] htmlparser with tag br In-Reply-To: <1336810208.34.0.533779581931.issue14786@psf.upfronthosting.co.za> Message-ID: <1336968672.99.0.555297062586.issue14786@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 07:05:59 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 14 May 2012 05:05:59 +0000 Subject: [issue14794] slice.indices raises OverflowError In-Reply-To: <1336863098.54.0.753598684211.issue14794@psf.upfronthosting.co.za> Message-ID: <1336971959.48.0.418686107628.issue14794@psf.upfronthosting.co.za> Ned Deily added the comment: The problem you described is definitely still an issue with 32-bit builds. $ /usr/local/bin/python3.3 Python 3.3.0a3 (v3.3.0a3:0b53b70a40a0, May 1 2012, 11:39:35) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys; sys.maxsize 9223372036854775807 >>> slice(0,90000,None).indices(12600000000) (0, 90000, 1) $ /usr/local/bin/python3.3-32 Python 3.3.0a3 (v3.3.0a3:0b53b70a40a0, May 1 2012, 11:39:35) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys; print(sys.maxsize) 2147483647 >>> slice(0,90000,None).indices(12600000000) Traceback (most recent call last): File "", line 1, in OverflowError: cannot fit 'int' into an index-sized integer ---------- nosy: +ned.deily resolution: out of date -> stage: committed/rejected -> needs patch status: closed -> open versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 07:58:37 2012 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Mon, 14 May 2012 05:58:37 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1336975117.08.0.785784753178.issue14776@psf.upfronthosting.co.za> Changes by Bohuslav "Slavek" Kabrda : ---------- nosy: +bkabrda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 09:34:23 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 14 May 2012 07:34:23 +0000 Subject: [issue14793] broken grammar in Built-in Types doc In-Reply-To: Message-ID: <1336980863.71.0.281722145767.issue14793@psf.upfronthosting.co.za> Tshepang Lekhonkhobe added the comment: I thought the title was enough? Is it fine to merely repeat it in? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 09:38:03 2012 From: report at bugs.python.org (Sandro Tosi) Date: Mon, 14 May 2012 07:38:03 +0000 Subject: [issue14793] broken grammar in Built-in Types doc In-Reply-To: Message-ID: <1336981083.2.0.988305923356.issue14793@psf.upfronthosting.co.za> Sandro Tosi added the comment: I think that something on the line "Hey, it looks like this phrase misses some words, and I've just fixed it" would have been nicer - IMO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 09:43:39 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 14 May 2012 07:43:39 +0000 Subject: [issue14803] Add -C option to run code at Python startup Message-ID: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za> New submission from Nick Coghlan : Reading http://nedbatchelder.com/code/coverage/subprocess.html, it occurred to me that there are various tracing and profiling operations that could be cleanly handled with significantly less work on the part of the tracing/profiling tool authors if the interpreter supported a "-C" operation that was like the existing "-c" option, but *didn't* terminate the options list. The interpreter would invoke such commands after the interpreter is fully initialised, but before it begins the processing to find and execute __main__. Then, to use subprocess coverage with coverage.py as an example, you could just run a command like: "python -C 'import coverage; coverage.process_startup()' worker.py" Other things you could usefully do in such an invocation is reconfigure sys.std(in|out|err) to match the settings used on the invoking side (e.g. to ensure Unicode data is tunnelled correctly), configure the logging module with a custom configuration, configure the warnings module programmatically, enable a memory profiler, etc. Providing a function that could be called from -C and then uses an atexit() handler to do any necessary post-processing may be significantly simpler than trying to use runpy.run_(path|module) to achieve a similar effect. ---------- messages: 160597 nosy: ncoghlan priority: normal severity: normal status: open title: Add -C option to run code at Python startup _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 09:45:19 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 14 May 2012 07:45:19 +0000 Subject: [issue14803] Add -C option to run code at Python startup In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za> Message-ID: <1336981519.51.0.703379825435.issue14803@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- stage: -> needs patch type: -> enhancement versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 09:45:40 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 14 May 2012 07:45:40 +0000 Subject: [issue14803] Add -C option to run code at Python startup In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za> Message-ID: <1336981540.66.0.475197573824.issue14803@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- components: +Interpreter Core _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 09:50:22 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 14 May 2012 07:50:22 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1336981822.74.0.5120193183.issue14532@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Committed. Jon, thanks for your patch and your patience! ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 11:46:59 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 14 May 2012 09:46:59 +0000 Subject: [issue14804] Wrong defaults args notation in docs Message-ID: <1336988819.38.0.761185643873.issue14804@psf.upfronthosting.co.za> New submission from Hynek Schlawack : After having been called out on wrong default arg notation in one of my patches (eg. function:: copyfile(src, dst[, symlinks=False])), I've done a "grep -RPi "\[\w+=" Doc/library" and fixed the cases I've found ? many of them sadly from myself (all the symlinks=False ones). ;) The patch is against tip, I'd back port it to 3.2 if the contents is okay (and do it for 2.7 too, there's a lot of this errors there, I suppose docs fixes are okay for 2.7?). ---------- assignee: docs at python components: Documentation files: doc-default-args.diff keywords: patch messages: 160599 nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, hynek priority: low severity: normal stage: patch review status: open title: Wrong defaults args notation in docs type: enhancement versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25573/doc-default-args.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 11:56:45 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 14 May 2012 09:56:45 +0000 Subject: [issue14804] Wrong defaults args notation in docs In-Reply-To: <1336988819.38.0.761185643873.issue14804@psf.upfronthosting.co.za> Message-ID: <1336989405.71.0.627898627518.issue14804@psf.upfronthosting.co.za> Ezio Melotti added the comment: The patch looks good to me, however in -.. method:: epoll.poll([timeout=-1[, maxevents=-1]]) +.. method:: epoll.poll(timeout=-1, maxevents=-1) it seems that maxevents can be passed only if timeout is specified, and this information is now lost in the signature. If this is indeed true, it should be written down in the doc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 12:03:57 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 14 May 2012 10:03:57 +0000 Subject: [issue14307] Make subclassing SocketServer simpler for non-blocking frameworks In-Reply-To: <1331767378.71.0.470789063251.issue14307@psf.upfronthosting.co.za> Message-ID: <1336989837.85.0.747158950916.issue14307@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Btw, I have found that socket.closesocket() is quite able, on Windows, to abort an ongoing accept() call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 12:13:03 2012 From: report at bugs.python.org (Petri Lehtinen) Date: Mon, 14 May 2012 10:13:03 +0000 Subject: [issue14804] Wrong defaults args notation in docs In-Reply-To: <1336988819.38.0.761185643873.issue14804@psf.upfronthosting.co.za> Message-ID: <1336990383.3.0.370252307692.issue14804@psf.upfronthosting.co.za> Petri Lehtinen added the comment: Looking at the code of epoll.poll(), it seems that epoll.poll(timeout=-1, maxevents=-1) is correct and the old epoll.poll([timeout=-1[, maxevents=-1]]) is wrong, as there's no dependency between timeout and maxevents. ---------- nosy: +petri.lehtinen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 12:32:39 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 May 2012 10:32:39 +0000 Subject: [issue14405] Some "Other Resources" in the sidebar are hopelessly out of date In-Reply-To: <1332696210.48.0.175266420412.issue14405@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 855a6796312b by Ezio Melotti in branch '2.7': #14405: remove outdated/broken/duplicate links. http://hg.python.org/cpython/rev/855a6796312b New changeset b50d4ae6aaa3 by Ezio Melotti in branch '3.2': #14405: remove outdated/broken/duplicate links. http://hg.python.org/cpython/rev/b50d4ae6aaa3 New changeset 8a8120ee1202 by Ezio Melotti in branch 'default': #14405: merge with 3.2. http://hg.python.org/cpython/rev/8a8120ee1202 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 12:33:13 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 14 May 2012 10:33:13 +0000 Subject: [issue14405] Some "Other Resources" in the sidebar are hopelessly out of date In-Reply-To: <1332696210.48.0.175266420412.issue14405@psf.upfronthosting.co.za> Message-ID: <1336991593.58.0.567069195868.issue14405@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 12:47:38 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 14 May 2012 10:47:38 +0000 Subject: [issue14791] setup.py only adds /prefix/lib, not /prefix/lib64 In-Reply-To: <1336840843.09.0.565460268003.issue14791@psf.upfronthosting.co.za> Message-ID: <1336992458.16.0.215129910819.issue14791@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 12:57:59 2012 From: report at bugs.python.org (Ned Batchelder) Date: Mon, 14 May 2012 10:57:59 +0000 Subject: [issue14803] Add -C option to run code at Python startup In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za> Message-ID: <1336993079.46.0.496316731536.issue14803@psf.upfronthosting.co.za> Changes by Ned Batchelder : ---------- nosy: +nedbat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 13:20:17 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 May 2012 11:20:17 +0000 Subject: [issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper In-Reply-To: <1326892577.13.0.456815776311.issue13815@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset ab6496b98ac4 by Lars Gust?bel in branch 'default': Issue #13815: Resurrect the ExFileObject class. http://hg.python.org/cpython/rev/ab6496b98ac4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 13:20:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 May 2012 11:20:26 +0000 Subject: [issue14802] Python 3.2 fail to compile with VC11 ARM configuration In-Reply-To: <1336967845.45.0.147430912977.issue14802@psf.upfronthosting.co.za> Message-ID: <1336994426.1.0.985688064494.issue14802@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 13:22:45 2012 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Mon, 14 May 2012 11:22:45 +0000 Subject: [issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper In-Reply-To: <1326892577.13.0.456815776311.issue13815@psf.upfronthosting.co.za> Message-ID: <1336994565.24.0.634883759405.issue13815@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Okay, I close this issue now, as I think the problems are now resolved. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 13:37:58 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 14 May 2012 11:37:58 +0000 Subject: [issue14804] Wrong defaults args notation in docs In-Reply-To: <1336988819.38.0.761185643873.issue14804@psf.upfronthosting.co.za> Message-ID: <1336995478.85.0.893941747864.issue14804@psf.upfronthosting.co.za> Hynek Schlawack added the comment: I had to expand the patch a bit by default args that weren't caught before. So here is still against default. It applies also against 3.2, only missing stuff fails AFAICT. (and yes, I checked the mknod device arg). 2.7 is in the works. ---------- Added file: http://bugs.python.org/file25574/doc-default-args-v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 13:41:48 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Mon, 14 May 2012 11:41:48 +0000 Subject: [issue6727] ImportError when package is symlinked on Windows In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za> Message-ID: <1336995708.93.0.198342169041.issue6727@psf.upfronthosting.co.za> Jason R. Coombs added the comment: At PyCon, I took another look at the Python 3.2 changes. Unfortunately, I found they trigger failures in other aspects of the test suite, so the approach is not viable as implemented. I plan to take another look at this at some point, but I've been utterly swamped. If someone wants to take a look at the 3.2 branch of my bitbucket clone, I would have no problem with that. Otherwise, I'll try to take a look at it when I can. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 13:50:15 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 14 May 2012 11:50:15 +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: <1336996215.21.0.458855459459.issue11549@psf.upfronthosting.co.za> Nick Coghlan added the comment: Bumping the target version to 3.4. This is still a good long term idea, but it's a substantial enough change that we really want to land it early in a development cycle so we have plenty of time to hammer out any issues. ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 14:00:39 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 14 May 2012 12:00:39 +0000 Subject: [issue14805] Support display of both __cause__ and __context__ Message-ID: <1336996839.56.0.43377861765.issue14805@psf.upfronthosting.co.za> New submission from Nick Coghlan : With PEP 415 accepted as the implementation of the "raise exc from None" syntax, it raises the prospect of exceptions with both __cause__ and __context__ set to non-None values, and __suppress_context__ set to False. The initial PEP 415 patch treats this case the same way PEP 409 did: it ignores __context__ if *either* __cause__ is not None *or* __suppress_context__ is True. This issue proposes that at least the default exception display routine and the display routine in the traceback module be updated to display the __context__ any time __suppress_context__ is False, even if __cause__ is also non-None. ---------- components: Interpreter Core, Library (Lib) messages: 160609 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: Support display of both __cause__ and __context__ type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 14:05:14 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 May 2012 12:05:14 +0000 Subject: [issue14744] Use _PyUnicodeWriter API in str.format() internals In-Reply-To: <1336428561.46.0.842580483885.issue14744@psf.upfronthosting.co.za> Message-ID: <1336997114.31.0.836560158489.issue14744@psf.upfronthosting.co.za> STINNER Victor added the comment: I created a new repository to optimize str.format and str%args. ---------- hgrepos: +125 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 14:12:23 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 14 May 2012 12:12:23 +0000 Subject: [issue14805] Support display of both __cause__ and __context__ In-Reply-To: <1336996839.56.0.43377861765.issue14805@psf.upfronthosting.co.za> Message-ID: <1336997543.66.0.578497700723.issue14805@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- dependencies: +improved PEP 409 implementation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 14:13:21 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 14 May 2012 12:13:21 +0000 Subject: [issue14133] improved PEP 409 implementation In-Reply-To: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za> Message-ID: <1336997601.15.0.556019677087.issue14133@psf.upfronthosting.co.za> Nick Coghlan added the comment: I have accepted the PEP. Issue 14805 now covers the separate question of allowing both __cause__ and __context__ to be displayed in the same traceback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 14:20:08 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 14 May 2012 12:20:08 +0000 Subject: [issue5057] Unicode-width dependent optimization leads to non-portable pyc file In-Reply-To: <1232900172.29.0.659028766072.issue5057@psf.upfronthosting.co.za> Message-ID: <1336998008.12.0.351812868491.issue5057@psf.upfronthosting.co.za> Ezio Melotti added the comment: This whole issue doesn't affect 3.3. For 2.7/3.2 there are three possible options: 1) remove constant folding altogether on unicode (this is the solution adopted by PyPy); 2) scan the string up to the index looking for non-BMP chars and disable the constant folding if they are found (probably not very efficient); 3) leave the "buggy" code there (might lead to obscure failures in remote cases); Any opinions? ---------- versions: -Python 3.1, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 14:32:02 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 14 May 2012 12:32:02 +0000 Subject: [issue5057] Unicode-width dependent optimization leads to non-portable pyc file In-Reply-To: <1232900172.29.0.659028766072.issue5057@psf.upfronthosting.co.za> Message-ID: <1336998722.77.0.517215756756.issue5057@psf.upfronthosting.co.za> Ezio Melotti added the comment: Attached a patch that implements option 1). ---------- stage: needs patch -> commit review Added file: http://bugs.python.org/file25575/issue5057-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 14:39:56 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 May 2012 12:39:56 +0000 Subject: [issue5057] Unicode-width dependent optimization leads to non-portable pyc file In-Reply-To: <1232900172.29.0.659028766072.issue5057@psf.upfronthosting.co.za> Message-ID: <1336999196.9.0.148665381295.issue5057@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Option 2) would have my preference. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 14:50:28 2012 From: report at bugs.python.org (zk) Date: Mon, 14 May 2012 12:50:28 +0000 Subject: [issue14806] re.match does not match word '{' Message-ID: <1336999828.05.0.573587450355.issue14806@psf.upfronthosting.co.za> New submission from zk : >>> type(re.match('{', 'aaaa{')) >>> type(re.match('\{', 'aaaa{')) >>> type(re.search('\{', 'aaaa{')) >>> type(re.search('{', 'aaaa{')) ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 160615 nosy: zk priority: normal severity: normal status: open title: re.match does not match word '{' type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 14:51:35 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 May 2012 12:51:35 +0000 Subject: [issue14801] ssize_t where size_t expected In-Reply-To: <1336954414.18.0.61439717267.issue14801@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2bbf3ba30435 by Antoine Pitrou in branch '3.2': Use size_t, not ssize_t (issue #14801). http://hg.python.org/cpython/rev/2bbf3ba30435 New changeset 64b695a6cc3d by Antoine Pitrou in branch 'default': Use size_t, not ssize_t (issue #14801). http://hg.python.org/cpython/rev/64b695a6cc3d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 14:52:09 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 14 May 2012 12:52:09 +0000 Subject: [issue14806] re.match does not match word '{' In-Reply-To: <1336999828.05.0.573587450355.issue14806@psf.upfronthosting.co.za> Message-ID: <1336999929.66.0.0991768120138.issue14806@psf.upfronthosting.co.za> Ezio Melotti added the comment: re.match matches only at the beginning of the string. ---------- assignee: -> ezio.melotti components: +Regular Expressions -2to3 (2.x to 3.x conversion tool) nosy: +ezio.melotti, mrabarnett resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 14:53:01 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 May 2012 12:53:01 +0000 Subject: [issue14801] ssize_t where size_t expected In-Reply-To: <1336954414.18.0.61439717267.issue14801@psf.upfronthosting.co.za> Message-ID: <1336999981.9.0.471387138114.issue14801@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Should be ok now, thank you. ---------- nosy: +pitrou resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 14:55:22 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 May 2012 12:55:22 +0000 Subject: [issue14800] stat.py constant comments + docstrings In-Reply-To: <1336953225.33.0.233761576766.issue14800@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2a695cbdf090 by Giampaolo Rodola' in branch 'default': Issue 14800: add comments explaining stat.py constants + docstring for S_* functions. http://hg.python.org/cpython/rev/2a695cbdf090 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 14:59:23 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 14 May 2012 12:59:23 +0000 Subject: [issue14804] Wrong defaults args notation in docs In-Reply-To: <1336988819.38.0.761185643873.issue14804@psf.upfronthosting.co.za> Message-ID: <1337000363.71.0.659111155657.issue14804@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Here's against 2.7 which proved to be a can of worms. I tried to be as unobstructive as possible. Please have a look at it, I'm sure I forgot some parenthesis somewhere. ---------- Added file: http://bugs.python.org/file25576/doc-default-args-v2-2.7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 15:04:38 2012 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 14 May 2012 13:04:38 +0000 Subject: [issue14807] Move tarfile.filemode() into stat module Message-ID: <1337000678.3.0.189462567372.issue14807@psf.upfronthosting.co.za> New submission from Giampaolo Rodola' : As per: http://mail.python.org/pipermail/python-ideas/2012-May/015104.html Patch is in attachment. ---------- components: Library (Lib) files: filemode.patch keywords: easy, patch messages: 160621 nosy: giampaolo.rodola, terry.reedy priority: normal severity: normal status: open title: Move tarfile.filemode() into stat module versions: Python 3.3 Added file: http://bugs.python.org/file25577/filemode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 15:08:43 2012 From: report at bugs.python.org (Armin Rigo) Date: Mon, 14 May 2012 13:08:43 +0000 Subject: [issue5057] Unicode-width dependent optimization leads to non-portable pyc file In-Reply-To: <1232900172.29.0.659028766072.issue5057@psf.upfronthosting.co.za> Message-ID: <1337000923.47.0.358775551192.issue5057@psf.upfronthosting.co.za> Armin Rigo added the comment: Did anyone ever show that this particular detail, which looks like a completely obscure case to me, has any measurable effect on any code whatsoever? Just coming up with numbers, but I'm sure it gives you 5% on the most specially tuned micro-benchmark, and nothing at all in all other cases. Just saying my vote goes for option 1, but I won't argue if people feel that it's a good investment of their time :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 15:28:37 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 14 May 2012 13:28:37 +0000 Subject: [issue12098] Child process running as debug on Windows In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za> Message-ID: <1337002117.98.0.345318230643.issue12098@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > - the function generating the flags should be exported (with a private > name), so that it can be reused by Lib/test/[test_]support.py. Duplicate > code is error-prone, especially when enumerating command-line flags, > attribute names... Failure to build _multiprocessing will mean that multiprocessing cannot be imported. So if the function goes somewhere in multiprocessing then it makes running the test suite with multiple processes dependent on the building of _multiprocessing. Not sure if that is much of a problem since one can just run the test suite normally. Also I don't think "-i" (inspect/interactive) should be passed on: a child process's stdin is os.devnull. BTW, why isn't the use of "-u" (unbuffered stdout, stderr) reflected in sys.flags? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 15:37:50 2012 From: report at bugs.python.org (zk) Date: Mon, 14 May 2012 13:37:50 +0000 Subject: [issue14806] re.match does not match word '{' In-Reply-To: <1336999828.05.0.573587450355.issue14806@psf.upfronthosting.co.za> Message-ID: <1337002670.53.0.140081816635.issue14806@psf.upfronthosting.co.za> zk added the comment: Oops. Sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 15:45:03 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 14 May 2012 13:45:03 +0000 Subject: [issue14313] zipfile should raise an exception for unsupported compression methods In-Reply-To: <1331786135.76.0.307574406169.issue14313@psf.upfronthosting.co.za> Message-ID: <1337003103.96.0.253699116539.issue14313@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- keywords: +needs review stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 15:47:21 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 14 May 2012 13:47:21 +0000 Subject: [issue14187] add "function annotation" entry to Glossary In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za> Message-ID: <1337003241.53.0.207262036186.issue14187@psf.upfronthosting.co.za> ?ric Araujo added the comment: Will do. Chris, I don?t think another entry for ?annotation? is needed, given Raymond?s previous rejection of the paragraph talking about other languages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 15:58:11 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 14 May 2012 13:58:11 +0000 Subject: [issue14804] Wrong defaults args notation in docs In-Reply-To: <1336988819.38.0.761185643873.issue14804@psf.upfronthosting.co.za> Message-ID: <1337003891.59.0.063208094107.issue14804@psf.upfronthosting.co.za> ?ric Araujo added the comment: I think there?s already one report for this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 16:00:52 2012 From: report at bugs.python.org (Brian Curtin) Date: Mon, 14 May 2012 14:00:52 +0000 Subject: [issue14802] Python 3.2 fail to compile with VC11 ARM configuration In-Reply-To: <1336967845.45.0.147430912977.issue14802@psf.upfronthosting.co.za> Message-ID: <1337004052.32.0.527016688513.issue14802@psf.upfronthosting.co.za> Brian Curtin added the comment: Thanks for your report. Unfortunately Python 3.2 won't ever work in this way because changing compilers would be a new feature, and bug fix releases like 3.2 don't receive new features. Yesterday we completed the transition to VS2010 as a step towards our 3.3 release. We are open to supporting VS11, but it won't become the standard compiler suite we use until VS11 goes RTM. I'm not aware of any release schedule announced yet, but I believe we would need VS11 to be released before our first beta release, which is at the end of June. Most estimates I've seen don't look favorable for us supporting it in 3.3. Another issue that may hinder this is that myself, and as far as I know, the other developers, do not have ARM machines available to them. I'm interested in continuing our transition from VS2010 on to VS11 for when it's ready, but anything ARM related will likely require someone else to help out, maybe even you :) ---------- components: +Build, Windows -Interpreter Core versions: +Python 3.3, Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 17:31:48 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 May 2012 15:31:48 +0000 Subject: [issue14313] zipfile should raise an exception for unsupported compression methods In-Reply-To: <1331786135.76.0.307574406169.issue14313@psf.upfronthosting.co.za> Message-ID: <1337009508.58.0.395996522097.issue14313@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Modified patch adopted in 3.3 (changeset 596b0eaeece8), therefore the current patch only applies to 3.2 and 2.7. If this is a new feature, the issue can be closed. ---------- nosy: +loewis, storchaka versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 17:36:59 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 14 May 2012 15:36:59 +0000 Subject: [issue14808] Pdb does not stop at a breakpoint set on the line of a function definition Message-ID: <1337009819.22.0.0422011129239.issue14808@psf.upfronthosting.co.za> New submission from Xavier de Gaye : In the following test both breakpoints are set on the line of a function definition. However pdb does not stop when entering foo whose breakpoint has been set with 'break 1' while pdb stops when entering bar whose breakpoint has been set with 'break bar'. The breakpoint table display is identical for both breakpoints. This is inconsistent and confusing. === main.py ================================== 1 def foo(): 2 pass 3 4 def bar(): 5 pass 6 7 def main(): 8 foo() 9 bar() 10 11 import pdb; pdb.runcall(main) ================================================= $ python main.py > /path_to/main.py(8)main() -> foo() (Pdb) break 1 Breakpoint 1 at /path_to/main.py:1 (Pdb) break bar Breakpoint 2 at /path_to/main.py:4 (Pdb) break Num Type Disp Enb Where 1 breakpoint keep yes at /path_to/main.py:1 2 breakpoint keep yes at /path_to/main.py:4 (Pdb) continue > /path_to/main.py(5)bar() -> pass (Pdb) continue $ ================================================= The reverse occurs in the following test where pdb stops only at the execution of the function definition when the breakpoint has been set with a line number. === main.py ================================== 1 x = 1 2 3 def foo(): 4 pass 5 6 def bar(): 7 pass 8 9 x = 2 ================================================= $ python -m pdb main.py > /path_to/main.py(1)() -> x = 1 (Pdb) break 3 Breakpoint 1 at /path_to/main.py:3 (Pdb) break bar Breakpoint 2 at /path_to/main.py:6 (Pdb) break 9 Breakpoint 3 at /path_to/main.py:9 (Pdb) break Num Type Disp Enb Where 1 breakpoint keep yes at /path_to/main.py:3 2 breakpoint keep yes at /path_to/main.py:6 3 breakpoint keep yes at /path_to/main.py:9 (Pdb) continue > /path_to/main.py(3)() -> def foo(): (Pdb) continue > /path_to/main.py(9)() -> x = 2 (Pdb) ================================================= The following patch fixes both inconsistencies by having pdb stop when entering a function and at the execution of a definition whatever the method used to set the breakpoint (line number or function name). Two test cases are included in the patch. ---------- components: Library (Lib) files: pdb_default.patch keywords: patch messages: 160629 nosy: xdegaye priority: normal severity: normal status: open title: Pdb does not stop at a breakpoint set on the line of a function definition type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25578/pdb_default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 17:52:42 2012 From: report at bugs.python.org (Christoph Sieghart) Date: Mon, 14 May 2012 15:52:42 +0000 Subject: [issue14778] IrrationalVersionError should include the project name In-Reply-To: <1336691641.31.0.00520688122933.issue14778@psf.upfronthosting.co.za> Message-ID: <1337010762.06.0.482261258133.issue14778@psf.upfronthosting.co.za> Christoph Sieghart added the comment: I took a look at the code and I don't think that adding an argument to the IrrationalVersionError constructor is the right way to go. The exception is raised in places where we don't know for which project we are raising the exception (eg in packaging.version.NormalizedVersion). Wouldn't it be better to make packaging.pypi.xmlrpc.Client just print the package name with the exception? I would be glad to contribute a patch. ---------- nosy: +sigi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 18:07:17 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 May 2012 16:07:17 +0000 Subject: [issue14781] Default to year 1 in strptime if year 0 has been specified In-Reply-To: <1336733675.67.0.302475509156.issue14781@psf.upfronthosting.co.za> Message-ID: <1337011637.72.0.10482482506.issue14781@psf.upfronthosting.co.za> R. David Murray added the comment: Datetime doesn't support BC. ---------- nosy: +r.david.murray resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 18:11:17 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 14 May 2012 16:11:17 +0000 Subject: [issue14778] IrrationalVersionError should include the project name In-Reply-To: <1336691641.31.0.00520688122933.issue14778@psf.upfronthosting.co.za> Message-ID: <1337011877.59.0.180273410286.issue14778@psf.upfronthosting.co.za> ?ric Araujo added the comment: You are right. When the NormalizedVersion class is used standalone, there is no project name to pass, so it is the responsibility of higher-level code (the Metadata class I think here) to raise or log messages including the project name. To make a patch, you can use the hg.python.org/distutils2 repo (also mirrored on Bitbucket under the python_mirrors user account for easing cloning) or the CPython repository. Thanks! ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 18:11:39 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 May 2012 16:11:39 +0000 Subject: [issue14782] Tab-completion of callables displays opening paren In-Reply-To: <1336738586.42.0.602618902889.issue14782@psf.upfronthosting.co.za> Message-ID: <1337011899.48.0.405252600166.issue14782@psf.upfronthosting.co.za> R. David Murray added the comment: It's issue 449227. ---------- nosy: +dieresys, facundobatista, georg.brandl, gpolo, pitrou, r.david.murray, rnd0110 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 18:12:26 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 14 May 2012 16:12:26 +0000 Subject: [issue14778] logging messages about bad version numbers should include the project name In-Reply-To: <1336691641.31.0.00520688122933.issue14778@psf.upfronthosting.co.za> Message-ID: <1337011946.8.0.827656201684.issue14778@psf.upfronthosting.co.za> ?ric Araujo added the comment: BTW there could be an optional argument in the exception constructor for the project name, but that does not seem clean to me. ---------- title: IrrationalVersionError should include the project name -> logging messages about bad version numbers should include the project name _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 18:15:27 2012 From: report at bugs.python.org (Dave Malcolm) Date: Mon, 14 May 2012 16:15:27 +0000 Subject: [issue14785] Add sys._debugmallocstats() In-Reply-To: <1336776030.63.0.471450530302.issue14785@psf.upfronthosting.co.za> Message-ID: <1337012127.34.0.904831429964.issue14785@psf.upfronthosting.co.za> Dave Malcolm added the comment: Updated version of the patch, using test.script_helper.assert_python_ok() and adding a NEWS entry ---------- Added file: http://bugs.python.org/file25579/add-debug-malloc-stats-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 18:23:44 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 May 2012 16:23:44 +0000 Subject: [issue14799] Tkinter ttk tests hang on linux In-Reply-To: <1336935343.12.0.855604727116.issue14799@psf.upfronthosting.co.za> Message-ID: <1337012624.94.0.394590987574.issue14799@psf.upfronthosting.co.za> R. David Murray added the comment: It does not hang for me on Gentoo. When I run the test suite before a checkin, I use -uall, and I've never had test_ttk hang for me. I did an 'hg pull; hg up' before running the command line you give below. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 18:25:52 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 May 2012 16:25:52 +0000 Subject: [issue14802] Python fails to compile with VC11 ARM configuration In-Reply-To: <1336967845.45.0.147430912977.issue14802@psf.upfronthosting.co.za> Message-ID: <1337012752.36.0.694221703672.issue14802@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: Python 3.2 fail to compile with VC11 ARM configuration -> Python fails to compile with VC11 ARM configuration type: compile error -> enhancement versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 18:50:16 2012 From: report at bugs.python.org (Martin Morrison) Date: Mon, 14 May 2012 16:50:16 +0000 Subject: [issue14157] time.strptime without a year fails on Feb 29 In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za> Message-ID: <1337014216.65.0.583002633276.issue14157@psf.upfronthosting.co.za> Martin Morrison added the comment: This solution has some very undesirable properties - namely that Mar 1st is now less than Feb 29th! It seems like the correct follow up fix would be to adjust the date of the returned struct_time back to 1900. The struct_time object doesn't have the validation issue, so this works fine. This pair of fixes then nicely circumvents the intermediate datetime object's checking, while providing a consistent end result. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 18:54:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 May 2012 16:54:40 +0000 Subject: [issue14157] time.strptime without a year fails on Feb 29 In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za> Message-ID: <1337014480.03.0.122818512621.issue14157@psf.upfronthosting.co.za> Antoine Pitrou added the comment: That's a good point, thank you. Hynek, do you want to provide a new patch? ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 19:00:30 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 14 May 2012 17:00:30 +0000 Subject: [issue14157] time.strptime without a year fails on Feb 29 In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za> Message-ID: <1337014830.89.0.677125907738.issue14157@psf.upfronthosting.co.za> Hynek Schlawack added the comment: On it. I wonder whether it causes trouble that we return an invalid time_struct down the road? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 19:10:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 May 2012 17:10:54 +0000 Subject: [issue14785] Add sys._debugmallocstats() In-Reply-To: <1336776030.63.0.471450530302.issue14785@psf.upfronthosting.co.za> Message-ID: <1337015454.21.0.923325476975.issue14785@psf.upfronthosting.co.za> Antoine Pitrou added the comment: One other nit: the C API functions shouldn't be included in the limited API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 19:20:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 May 2012 17:20:41 +0000 Subject: [issue12098] Child process running as debug on Windows In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za> Message-ID: <1337016041.71.0.408660629316.issue12098@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Failure to build _multiprocessing will mean that multiprocessing cannot > be imported. So if the function goes somewhere in multiprocessing then > it makes running the test suite with multiple processes dependent on the > building of _multiprocessing. Not sure if that is much of a problem > since one can just run the test suite normally. I don't think that's a problem indeed. > Also I don't think "-i" (inspect/interactive) should be passed on: a > child process's stdin is os.devnull. Ah, you're right. > BTW, why isn't the use of "-u" (unbuffered stdout, stderr) reflected in > sys.flags? Don't know. sys.flags was introduced in issue1816, long after the -u flag itself. The code to reflect "-u" is commented out, perhaps Christian Heimes can shed some light on this. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 19:22:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 May 2012 17:22:42 +0000 Subject: [issue14803] Add -C option to run code at Python startup In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za> Message-ID: <1337016162.71.0.720950046464.issue14803@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It would be nice to have a comparison of the available alternatives. It's not obvious that asking people to type some "-C ..." boilerplate to get code coverage is very user-friendly. Or am I misunderstanding the request? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 19:28:17 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 May 2012 17:28:17 +0000 Subject: [issue14807] Move tarfile.filemode() into stat module In-Reply-To: <1337000678.3.0.189462567372.issue14807@psf.upfronthosting.co.za> Message-ID: <1337016497.34.0.726640924425.issue14807@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not sure filemode() is the best name for this. On the other hand, I don't have any suggestion. I don't understand why you're using atexit. tearDown() and addCleanup() are your friends. The call_safely thing also looks unwarranted. support.unlink() should be able to help you. ---------- nosy: +pitrou stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 19:28:41 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 14 May 2012 17:28:41 +0000 Subject: [issue14157] time.strptime without a year fails on Feb 29 In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za> Message-ID: <1337016521.26.0.285933941708.issue14157@psf.upfronthosting.co.za> Hynek Schlawack added the comment: I have added a restoration including a short explanation + a regression test. ---------- Added file: http://bugs.python.org/file25580/strptime-restore-1900.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 19:30:42 2012 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Mon, 14 May 2012 17:30:42 +0000 Subject: [issue14807] Move tarfile.filemode() into stat module In-Reply-To: <1337000678.3.0.189462567372.issue14807@psf.upfronthosting.co.za> Message-ID: <1337016642.25.0.100165170419.issue14807@psf.upfronthosting.co.za> Changes by Lars Gust?bel : ---------- nosy: +lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 19:31:14 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 May 2012 17:31:14 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1336958441.23.0.971269097314.issue14315@psf.upfronthosting.co.za> Message-ID: <1337016833.3422.28.camel@raxxla> Serhiy Storchaka added the comment: > This is definitely *not* a padding issue. This is definitely a padding issue. All uncompressed files are located so that the data starts with a 4-byte boundary (1190+30+15+1=1236, 27486 +30+17+3=27536, etc). This is, probably, allows the use of mmap for the resources. > As Martin pointed out, the standard says that things must be in > multiples of 4-bytes. More precisely, the extra field must have at least 4-bytes length to fit a header. The standard is insufficiently defined in terms of what would happen if the rest of the field is less than 4 bytes (this is hidden behind by ellipsis). > So the record is non-portable. De jure the record is non-portable. De facto the record is portable (many other tools supports it). But even if it does not portable, we are dealing with the expansion of the zip format, which is very easy support for reading. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 19:35:04 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 14 May 2012 17:35:04 +0000 Subject: [issue14157] time.strptime without a year fails on Feb 29 In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za> Message-ID: <1337016904.83.0.489491007873.issue14157@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Small adjustments to the test as discussed in IRC. ---------- assignee: -> hynek resolution: fixed -> stage: committed/rejected -> patch review type: enhancement -> behavior Added file: http://bugs.python.org/file25581/strptime-restore-1900-v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 14 19:49:28 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 May 2012 17:49:28 +0000 Subject: [issue14803] Add -C option to run code at Python startup In-Reply-To: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za> Message-ID: <1337017768.13.0.295176307435.issue14803@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This can be achieved without intoducing a new interpreter option, using special module. python -m prerun