From report at bugs.python.org Sat Mar 1 00:08:03 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 29 Feb 2008 23:08:03 -0000 Subject: [issue2211] Cookie.Morsel interface needs update In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za> Message-ID: <1204326483.05.0.704760646821.issue2211@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Would you be interested to work on a patch? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 00:20:59 2008 From: report at bugs.python.org (Gawain Bolton) Date: Fri, 29 Feb 2008 23:20:59 -0000 Subject: [issue2195] urlparse() does not handle URLs with port numbers properly In-Reply-To: <1204065114.68.0.139974159124.issue2195@psf.upfronthosting.co.za> Message-ID: <1204327259.86.0.742954659813.issue2195@psf.upfronthosting.co.za> Gawain Bolton added the comment: On the contrary, RFC 1738 does mention the port number in section 3.1. Common Internet Scheme Syntax: While the syntax for the rest of the URL may vary depending on the particular scheme selected, URL schemes that involve the direct use of an IP-based protocol to a specified host on the Internet use a common syntax for the scheme-specific data: //:@:/ Some or all of the parts ":@", ":", ":", and "/" may be excluded. The scheme specific data start with a double slash "//" to indicate that it complies with the common Internet scheme syntax. I agree with Christos Georgiou's suggestion that if the a default scheme is passed AND the default scheme is a URL scheme, then the scheme should be identified as being before "://". __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 00:24:25 2008 From: report at bugs.python.org (Brett Cannon) Date: Fri, 29 Feb 2008 23:24:25 -0000 Subject: [issue2196] Fix hasattr's exception problems In-Reply-To: <1204322676.49.0.787938887925.issue2196@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: On Fri, Feb 29, 2008 at 2:04 PM, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > After looking more closely, I saw that this is documented at > http://www.python.org/dev/patches/style/. So the C uses tabs, and the > Python uses spaces? Yes, although that is changing in Python 3.0. ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 01:35:43 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Sat, 01 Mar 2008 00:35:43 -0000 Subject: [issue2213] build_tkinter.py does not handle paths with spaces In-Reply-To: <1204331742.92.0.0412981555519.issue2213@psf.upfronthosting.co.za> Message-ID: <1204331742.92.0.0412981555519.issue2213@psf.upfronthosting.co.za> New submission from Joseph Armbruster: http://svn.python.org/projects/python/trunk/PCbuild/build_tkinter.py rev 61127 Is it still in python-devs interest to support building the tree in a path that contains spaces? I (pretty much always) do, so if a patch for this is desired, I can put one together. ---------- components: Build, Windows messages: 63152 nosy: JosephArmbruster, tiran severity: normal status: open title: build_tkinter.py does not handle paths with spaces type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 02:02:32 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Sat, 01 Mar 2008 01:02:32 -0000 Subject: [issue1672853] Error reading files larger than 4GB Message-ID: <1204333352.25.0.079098348634.issue1672853@psf.upfronthosting.co.za> Joseph Armbruster added the comment: Using: http://svn.python.org/projects/python/trunk @ 61127 OS Name: Microsoft Windows XP Professional OS Version: 5.1.2600 Service Pack 2 Build 2600 I would like to report a positive follow-up on this issue. The output I received was as follows, indicating this specific issue may be resolved. The resulting bigfile produced from the test totaled 11.5 GB (12,382,502,912 bytes). python bigfiletest1.py 10000 20000 30000 40000 50000 60000 70000 80000 90000 100000 110000 120000 130000 140000 150000 160000 170000 180000 190000 200000 210000 220000 230000 240000 250000 260000 270000 280000 290000 300000 310000 320000 330000 340000 350000 360000 370000 380000 390000 400000 410000 420000 430000 440000 450000 460000 470000 480000 490000 500000 510000 520000 530000 540000 550000 560000 570000 580000 590000 600000 610000 620000 630000 640000 650000 660000 670000 680000 690000 700000 710000 720000 730000 740000 750000 760000 770000 780000 790000 800000 810000 820000 830000 840000 850000 860000 870000 880000 890000 900000 910000 920000 930000 940000 950000 960000 970000 980000 990000 1000000 1010000 1020000 1030000 1040000 1050000 1060000 1070000 1080000 1090000 1100000 1110000 1120000 1130000 1140000 1150000 1160000 1170000 1180000 1190000 1200000 1210000 1220000 1230000 1240000 1250000 1260000 1270000 1280000 1290000 1300000 1310000 1320000 1330000 1340000 1350000 1360000 1370000 1380000 1390000 1400000 1410000 1420000 1430000 1440000 1450000 1460000 1470000 1480000 1490000 1500000 ---------- nosy: +JosephArmbruster, tiran _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 1 02:04:08 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Sat, 01 Mar 2008 01:04:08 -0000 Subject: [issue1451466] reading very large files Message-ID: <1204333448.58.0.0463086756498.issue1451466@psf.upfronthosting.co.za> Joseph Armbruster added the comment: I believe this may be related to issue 1672853. http://bugs.python.org/issue1672853 ---------- nosy: +JosephArmbruster _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 1 02:37:15 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Sat, 01 Mar 2008 01:37:15 -0000 Subject: [issue2047] shutil.destinsrc returns wrong result when source path matches beginning of destination path In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za> Message-ID: <1204335435.67.0.576554782784.issue2047@psf.upfronthosting.co.za> Joseph Armbruster added the comment: Using: http://svn.python.org/projects/python/trunk @ 61127 OS Name: Microsoft Windows XP Professional OS Version: 5.1.2600 Service Pack 2 Build 2600 test_shutil 1 test OK. ---------- nosy: +JosephArmbruster __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 03:21:43 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Sat, 01 Mar 2008 02:21:43 -0000 Subject: [issue2047] shutil.destinsrc returns wrong result when source path matches beginning of destination path In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za> Message-ID: <1204338103.5.0.504720306613.issue2047@psf.upfronthosting.co.za> Joseph Armbruster added the comment: On another note, I just completed building the docs in windows and shutil.destinsrc does not appear to be documented. I did notice this description for shutil: "The shutil module offers a number of high-level operations on files and collections of files. In particular, functions are provided which support file copying and removal." I would have expected to find a function like this in os.path, not shutil. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 04:16:56 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Sat, 01 Mar 2008 03:16:56 -0000 Subject: [issue2047] shutil.destinsrc returns wrong result when source path matches beginning of destination path In-Reply-To: <1204338103.5.0.504720306613.issue2047@psf.upfronthosting.co.za> Message-ID: <2c51ecee0802291916g48d24a27t9b8861962f5b90a8@mail.gmail.com> Raghuram Devarakonda added the comment: On Fri, Feb 29, 2008 at 9:21 PM, Joseph Armbruster wrote: > On another note, I just completed building the docs in windows and > shutil.destinsrc does not appear to be documented. I did notice this > description for shutil: destinsrc() is an internal function used only in shutil.move(). __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 04:48:11 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 01 Mar 2008 03:48:11 -0000 Subject: [issue2047] shutil.destinsrc returns wrong result when source path matches beginning of destination path In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za> Message-ID: <1204343291.28.0.131781160017.issue2047@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Should it get a _ prepended to it then? ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 04:53:50 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Sat, 01 Mar 2008 03:53:50 -0000 Subject: [issue2047] shutil.destinsrc returns wrong result when source path matches beginning of destination path In-Reply-To: <1204343291.28.0.131781160017.issue2047@psf.upfronthosting.co.za> Message-ID: <2c51ecee0802291953x3a46be2cj5183c34cb29f79@mail.gmail.com> Raghuram Devarakonda added the comment: > Should it get a _ prepended to it then? Probably yes. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 07:12:23 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Sat, 01 Mar 2008 06:12:23 -0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1204351943.11.0.239179063759.issue1040026@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: How abount also check CLK_TCK? I know it's obsolute but maybe there are platforms without sysconf() and with CLK_TCK. ---------- nosy: +ocean-city _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 1 11:23:43 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Sat, 01 Mar 2008 10:23:43 -0000 Subject: [issue2065] trunk version does not compile with vs8 and vc6 In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za> Message-ID: <1204367023.89.0.508986514606.issue2065@psf.upfronthosting.co.za> Changes by Hirokazu Yamamoto: ---------- keywords: +patch Added file: http://bugs.python.org/file9577/ocean.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 16:45:19 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 01 Mar 2008 15:45:19 -0000 Subject: [issue2213] build_tkinter.py does not handle paths with spaces In-Reply-To: <1204331742.92.0.0412981555519.issue2213@psf.upfronthosting.co.za> Message-ID: <1204386319.64.0.338240033487.issue2213@psf.upfronthosting.co.za> Christian Heimes added the comment: Go ahead if you like to work on a patch. I'm +0. ---------- priority: -> low resolution: -> accepted versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 16:46:47 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 01 Mar 2008 15:46:47 -0000 Subject: [issue1672853] Error reading files larger than 4GB Message-ID: <1204386407.11.0.722606609647.issue1672853@psf.upfronthosting.co.za> Christian Heimes added the comment: How about Python 2.5? Have you tested the latest release as well? ---------- type: -> behavior _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 1 16:51:54 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 01 Mar 2008 15:51:54 -0000 Subject: [issue2047] shutil.destinsrc returns wrong result when source path matches beginning of destination path In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za> Message-ID: <1204386713.96.0.653236435753.issue2047@psf.upfronthosting.co.za> Christian Heimes added the comment: The function is just a one liner in 2.6 and it's used in one place only. Let's move it into move(). ---------- priority: normal -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 17:06:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 01 Mar 2008 16:06:18 -0000 Subject: [issue2200] find_executable fails to find .bat files on win32 In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za> Message-ID: <1204387578.88.0.316791888812.issue2200@psf.upfronthosting.co.za> Christian Heimes added the comment: Can you provide a patch which uses PATHEXT and falls back to .com, .exe and .bat? ---------- nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 17:24:18 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 01 Mar 2008 16:24:18 -0000 Subject: [issue2179] with should be as fast as try/finally In-Reply-To: <1203894641.18.0.492382147443.issue2179@psf.upfronthosting.co.za> Message-ID: <1204388658.02.0.0382301540889.issue2179@psf.upfronthosting.co.za> Nick Coghlan added the comment: A closer approximation of what the with statement is doing would be: exit = lock.release() lock.acquire() try: pass finally: exit() The problem with trying to store the result of the retrieval of __exit__ on the stack is that we need to leave the context manager itself on top of the stack for the next LOAD_ATTR opcode (when we're retrieving the __enter__ method). However, changing WITH_CLEANUP to take an argument indicating which local variable holds the bound __exit__ method sounds like it might work. ---------- nosy: +ncoghlan __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 17:31:02 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 01 Mar 2008 16:31:02 -0000 Subject: [issue2047] shutil.destinsrc returns wrong result when source path matches beginning of destination path In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za> Message-ID: <1204389062.17.0.918965274558.issue2047@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Here's a patch that moves destinsrc into move. Added file: http://bugs.python.org/file9578/shutil_remove_destinsrc.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 17:34:04 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 01 Mar 2008 16:34:04 -0000 Subject: [issue2179] with should be as fast as try/finally In-Reply-To: <1203894641.18.0.492382147443.issue2179@psf.upfronthosting.co.za> Message-ID: <1204389244.23.0.70804739067.issue2179@psf.upfronthosting.co.za> Nick Coghlan added the comment: Scratch the parentheses on that first line of sample code in my previous comment (isn't copy and paste wonderful?) __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 18:38:04 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Sat, 01 Mar 2008 17:38:04 -0000 Subject: [issue2047] shutil.destinsrc returns wrong result when source path matches beginning of destination path In-Reply-To: <1204386713.96.0.653236435753.issue2047@psf.upfronthosting.co.za> Message-ID: <2c51ecee0803010937x30c6859aje54e5c94c6e64525@mail.gmail.com> Raghuram Devarakonda added the comment: > The function is just a one liner in 2.6 and it's used in one place only. > Let's move it into move(). Isn't it clear from this issue's original description that there is a bug in the one liner that needs fix ? __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 22:38:50 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 01 Mar 2008 21:38:50 -0000 Subject: [issue2121] complex constructor doesn't accept string with nan and inf In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za> Message-ID: <1204407530.31.0.858297937643.issue2121@psf.upfronthosting.co.za> Mark Dickinson added the comment: Signed zeros cause difficulties with round-tripping, too: >>> z = complex(-0.0, -0.0); w = complex(repr(z)) >>> z -0j >>> w -0j >>> z.real -0.0 >>> w.real 0.0 ---------- nosy: +marketdickinson __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 22:44:57 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sat, 01 Mar 2008 21:44:57 -0000 Subject: [issue1193577] add server.shutdown() method and daemon arg to SocketServer Message-ID: <1204407897.5.0.821145170082.issue1193577@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Polling isn't a great way to handle shutdown, since it wastes CPU time and decreases responsiveness, but it's also easy and my attempt to avoid it isn't getting anywhere, so I'm planning to fix up your patch a bit and commit it. Thanks! I've merged your patch with my conflicting change in the trunk and re-attached it. Two things: 1) This patch may interfere with the existing timeout in await_request. We may be able to re-use that instead of having two select statements. 2) I believe it's important to provide a way to block until the server isn't accepting any more requests and to block until all active requests are finished running. If the active requests depend on other bits of the system, blocking until they're done would help them terminate gracefully. It would also be useful to give users a more proactive way to kill active requests, perhaps by listing the handler objects associated with them (or their PIDs for forking servers). It's surprisingly complicated to avoid race conditions in these implementations, especially without support from the Server object. Added file: http://bugs.python.org/file9579/polling_shutdown.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 1 22:55:32 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 01 Mar 2008 21:55:32 -0000 Subject: [issue2214] make htmlhelp raises non-reproducable exception In-Reply-To: <1204408532.2.0.853592374746.issue2214@psf.upfronthosting.co.za> Message-ID: <1204408532.2.0.853592374746.issue2214@psf.upfronthosting.co.za> New submission from Martin v. L?wis: Sometimes, when I run "make htmlhelp", I get a traceback of writing additional files... Traceback (most recent call last): File "tools/sphinx-build.py", line 24, in sys.exit(main(sys.argv)) File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/__init__.py", line 141, in main builderobj.build_update() File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/builder.py", line 202, in build_update summary='%d source files that are out of date' % len(to_build)) File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/builder.py", line 235, in build self.finish() File "/cygdrive/c/loewis/3k/python/Doc/tools/sphinx/builder.py", line 449, in finish download_base_url = self.config['download_base_url'], KeyError: 'download_base_url' make: *** [build] Fehler 1 When redoing "make htmlhelp", it immediately completes without error. ---------- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 63171 nosy: georg.brandl, loewis severity: normal status: open title: make htmlhelp raises non-reproducable exception __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 22:55:45 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sat, 01 Mar 2008 21:55:45 -0000 Subject: [issue1193577] add server.shutdown() method to SocketServer Message-ID: <1204408545.47.0.883488687857.issue1193577@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Also, Pedro's argument against a daemon_threads argument to TCPServer convinces me. I think we can add it in ThreadingMixIn.__init__ once this whole hierarchy is switched over to new-style classes. That's already done in 3.0, but I don't know what it would affect in 2.6. If anyone wants to keep pushing it, would you open a new bug? ---------- title: add server.shutdown() method and daemon arg to SocketServer -> add server.shutdown() method to SocketServer _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 1 23:19:20 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 01 Mar 2008 22:19:20 -0000 Subject: [issue2214] make htmlhelp raises non-reproducable exception In-Reply-To: <1204408532.2.0.853592374746.issue2214@psf.upfronthosting.co.za> Message-ID: <1204409960.24.0.28958436072.issue2214@psf.upfronthosting.co.za> Martin v. L?wis added the comment: After upgrading the tools, this problem is apparently gone. ---------- resolution: -> works for me status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 1 23:43:25 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sat, 01 Mar 2008 22:43:25 -0000 Subject: [issue1012468] Rational.py various bugfixes Message-ID: <1204411405.44.0.214952892904.issue1012468@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Yep. Removed in r61162. ---------- resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 2 02:42:19 2008 From: report at bugs.python.org (Jean Brouwers) Date: Sun, 02 Mar 2008 01:42:19 -0000 Subject: [issue2215] test_sqlite fails in 2.6a1 on MacOS X In-Reply-To: <1204422139.64.0.558749633793.issue2215@psf.upfronthosting.co.za> Message-ID: <1204422139.64.0.558749633793.issue2215@psf.upfronthosting.co.za> New submission from Jean Brouwers: One test fails on MacOS X 10.4.11 (Intel) after building 2.6a1 from source. test_sqlite test test_sqlite failed -- Traceback (most recent call last): File "/Users/jean/Tools/Python-2.6a1/Lib/sqlite3/test/regression.py", line 118, in CheckWorkaroundForBuggySqliteTransfer Bindings self.con.execute("create table if not exists foo(bar)") OperationalError: near "not": syntax error 29 tests are skipped (as expected) and 312 pass. ---------- components: Tests messages: 63175 nosy: MrJean1 severity: normal status: open title: test_sqlite fails in 2.6a1 on MacOS X versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 2 02:50:21 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 02 Mar 2008 01:50:21 -0000 Subject: [issue2215] test_sqlite fails in 2.6a1 on MacOS X In-Reply-To: <1204422139.64.0.558749633793.issue2215@psf.upfronthosting.co.za> Message-ID: <1204422621.81.0.658531191413.issue2215@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> ghaering components: +Macintosh nosy: +ghaering priority: -> normal type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 2 08:58:18 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Sun, 02 Mar 2008 07:58:18 -0000 Subject: [issue1759845] subprocess.call fails with unicode strings in command line Message-ID: <1204444698.57.0.850752196494.issue1759845@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: I tried to fix this problem using CreateProcessW. (environment variables are still ANSI) I don't know Python C API well, maybe I'm doing something wrong. (I confirmed test_subprocess.py passes) ---------- keywords: +patch nosy: +ocean-city Added file: http://bugs.python.org/file9580/CreateProcessW.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 2 09:18:39 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sun, 02 Mar 2008 08:18:39 -0000 Subject: [issue1193577] add server.shutdown() method to SocketServer Message-ID: <1204445919.95.0.824880430952.issue1193577@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: It seems that .await_request() was only added a month ago to fix issue 742598, so it's no great hardship to refactor it again now. Timeouts never worked for .serve_forever() because the try/except in .handle_request() turned their exception into a plain return, which didn't stop .server_forever() from looping. Timeouts also seem to be unnecessary in a situation in which shutdown works. Shutdown can only be called from a separate thread, and when you have more threads you can also do periodic tasks in them. So I've made that explicit: the .serve_forever/shutdown combination doesn't handle timeouts. [This has nothing to do with the fact that it takes three times as much code to handle them. Don't look at the excuse behind the curtain. ;)] This patch needs some more documentation and a NEWS entry before it gets submitted, but I want to check that everyone would be happy with the concept. ---------- nosy: +akuchling, pilcrow versions: +Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9581/polling_shutdown.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 2 10:56:25 2008 From: report at bugs.python.org (Pavel Vinogradov) Date: Sun, 02 Mar 2008 09:56:25 -0000 Subject: [issue2176] Undocumented lastrowid attribute i sqlite3 cursor class In-Reply-To: <1203862408.41.0.133171732382.issue2176@psf.upfronthosting.co.za> Message-ID: <1204451785.31.0.572256132239.issue2176@psf.upfronthosting.co.za> Pavel Vinogradov added the comment: This patch include brief lastrowid description based on my experience and Python DB API 2.0 PEP. ---------- keywords: +patch nosy: +pavel.vinogradov Added file: http://bugs.python.org/file9582/lastrowid_rst_desctiption.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 2 14:55:49 2008 From: report at bugs.python.org (Andrea Griffini) Date: Sun, 02 Mar 2008 13:55:49 -0000 Subject: [issue2216] Problems using logging module with idle In-Reply-To: <1204466149.08.0.371697565628.issue2216@psf.upfronthosting.co.za> Message-ID: <1204466149.08.0.371697565628.issue2216@psf.upfronthosting.co.za> New submission from Andrea Griffini: I'm not a user of idle, but when asked about a strange behaviour of the logging module I digged a bit and found what I think is indeed a problem in the module itself. The problem is visible if the module is used from idle (or any other IDE that keeps the same python instance running for multiple execution of user code); if you call basicConfig(filename="foo.txt"), do some logging and call shutdown() the handler is closed (correctly closing the file) but remains attached to the root logger, and gets called again at next run (giving an error for invalid I/O on a closed file). This can also be reproduced in a single run with import logging logging.basicConfig(filename="logtest.txt") logging.warning("This is a test") logging.shutdown() logging.basicConfig(filename="logtest2.txt") logging.warning("This is a test (2)") logging.shutdown() I think that it is not correct to close the handler but leave it in place, so I tried patching the module so that every handler keeps a list of all loggers it is attached to, and removes itself from loggers at close() time. This way the above code runs correctly (creating two files) and the logging module still passes the test suite. I must however admit that logging logic is a bit beyond my grasp (including a close() call commented out, some uses of lock/release I don't understand) so may be the attached patch is not correct even if passes the test. ---------- components: Library (Lib) files: logging.patch keywords: patch messages: 63179 nosy: ag6502 severity: normal status: open title: Problems using logging module with idle type: behavior versions: Python 2.4, Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9583/logging.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 2 16:29:33 2008 From: report at bugs.python.org (Lev Shamardin) Date: Sun, 02 Mar 2008 15:29:33 -0000 Subject: [issue2200] find_executable fails to find .bat files on win32 In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za> Message-ID: <1204471773.78.0.289237818016.issue2200@psf.upfronthosting.co.za> Lev Shamardin added the comment: Here is my vision of this patch. I don't think that it is necessary to fall back to 'com/exe/bat' if PATHEXT is not set, since it must be set on any correctly configured Win32 platform. ---------- keywords: +patch Added file: http://bugs.python.org/file9584/spawn.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 2 16:59:43 2008 From: report at bugs.python.org (Robert Schuppenies) Date: Sun, 02 Mar 2008 15:59:43 -0000 Subject: [issue687648] classic division in demos/ directory Message-ID: <1204473583.33.0.198736498402.issue687648@psf.upfronthosting.co.za> Robert Schuppenies added the comment: The attached patch applies floor division to all classic divisions where only integer input was used, and true division where at least on input parameter was of non-integral type. In cmptree.py I replaced "int(size/dt)" with "size//dt" as it has the same semantic but I thought it to be more explicit. ---------- keywords: +patch nosy: +okkoto Added file: http://bugs.python.org/file9585/demo_classicdivision.diff ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Mar 2 18:43:37 2008 From: report at bugs.python.org (Christoph Zwerschke) Date: Sun, 02 Mar 2008 17:43:37 -0000 Subject: [issue2217] Problem with if clause in generator expression on class level In-Reply-To: <1204479817.59.0.844396901804.issue2217@psf.upfronthosting.co.za> Message-ID: <1204479817.59.0.844396901804.issue2217@psf.upfronthosting.co.za> New submission from Christoph Zwerschke: The following code throws a NameError which seems to be a bug existing since Python 2.4 up to the current 2.5.2. class A: a = 'test' [c for c in a] (c for c in a) tuple(c for c in a) [c for c in a if c in a] (c for c in a if c in a) tuple(c for c in a if c in a) # --> NameError ---------- components: Interpreter Core, Library (Lib), Macintosh, Regular Expressions, Tests, Tkinter, Unicode, Windows, XML messages: 63182 nosy: cito severity: normal status: open title: Problem with if clause in generator expression on class level type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 2 18:56:46 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 02 Mar 2008 17:56:46 -0000 Subject: [issue2217] Problem with if clause in generator expression on class level In-Reply-To: <1204479817.59.0.844396901804.issue2217@psf.upfronthosting.co.za> Message-ID: <1204480606.08.0.960886529757.issue2217@psf.upfronthosting.co.za> Georg Brandl added the comment: This may seem odd, but is correct as per spec. The "if c in a" part is executed in a scope of its own, and class scopes don't contribute to nested scoping. ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 2 20:47:00 2008 From: report at bugs.python.org (Christoph Zwerschke) Date: Sun, 02 Mar 2008 19:47:00 -0000 Subject: [issue2217] Problem with if clause in generator expression on class level In-Reply-To: <1204479817.59.0.844396901804.issue2217@psf.upfronthosting.co.za> Message-ID: <1204487220.46.0.904733468424.issue2217@psf.upfronthosting.co.za> Christoph Zwerschke added the comment: Thanks for the quick explanation. I understand that class scopes don't extend and this is documented behavior. However, the question is why the if clause is executed in a scope of its own and where this is documented. You would expect that the problematic generator expression is equivalent to the following code which works fine: class A: a = 'test' def __g(a): for c in a: if c in a: yield c tuple(__g(a)) __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 2 21:23:08 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sun, 02 Mar 2008 20:23:08 -0000 Subject: [issue1193577] add server.shutdown() method to SocketServer Message-ID: <1204489388.69.0.0889600754805.issue1193577@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: I'll submit the attached patch in a couple days unless I get comments. Added file: http://bugs.python.org/file9586/polling_shutdown.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 2 21:47:49 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Sun, 02 Mar 2008 20:47:49 -0000 Subject: [issue1672853] Error reading files larger than 4GB Message-ID: <1204490869.79.0.66027723063.issue1672853@psf.upfronthosting.co.za> Joseph Armbruster added the comment: Just got in from New Smyrna beach... and the verdict is: URL: http://svn.python.org/projects/python/branches/release25-maint Revision: 61182 python bigfiletest1.py 10000 20000 30000 40000 50000 60000 70000 80000 90000 100000 110000 120000 130000 140000 150000 160000 170000 180000 190000 200000 210000 220000 230000 240000 250000 260000 270000 280000 290000 300000 310000 320000 330000 340000 350000 360000 370000 380000 390000 400000 410000 420000 430000 440000 450000 460000 470000 480000 490000 500000 510000 520000 530000 540000 550000 560000 570000 580000 590000 600000 610000 620000 630000 640000 650000 660000 670000 680000 690000 700000 710000 720000 730000 740000 750000 760000 770000 780000 790000 800000 810000 820000 830000 840000 850000 860000 870000 880000 890000 900000 910000 920000 930000 940000 950000 960000 970000 980000 990000 1000000 1010000 1020000 1030000 1040000 1050000 1060000 1070000 1080000 1090000 1100000 1110000 1120000 1130000 1140000 1150000 1160000 1170000 1180000 1190000 1200000 1210000 1220000 1230000 1240000 1250000 1260000 1270000 1280000 1290000 1300000 1310000 1320000 1330000 1340000 1350000 1360000 1370000 1380000 1390000 1400000 1410000 1420000 1430000 1440000 1450000 1460000 1470000 1480000 1490000 1500000 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 2 22:07:47 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 02 Mar 2008 21:07:47 -0000 Subject: [issue2217] Problem with if clause in generator expression on class level In-Reply-To: <1204479817.59.0.844396901804.issue2217@psf.upfronthosting.co.za> Message-ID: <1204492067.93.0.947119810532.issue2217@psf.upfronthosting.co.za> Georg Brandl added the comment: The actual equivalent would be class A: a = 'test' def __g(_x): for c in _x: if c in a: yield c tuple(__g(a)) i.e. the outmost iterator is evaluated in the enclosing scope; not the if clause is in its own scope, but the whole genexp. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 2 23:02:37 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 02 Mar 2008 22:02:37 -0000 Subject: [issue2215] test_sqlite fails in 2.6a1 on MacOS X In-Reply-To: <1204422139.64.0.558749633793.issue2215@psf.upfronthosting.co.za> Message-ID: <1204495357.91.0.779816472383.issue2215@psf.upfronthosting.co.za> Mark Dickinson added the comment: I don't think this is Mac specific---one of the linux buildbots has also been having this problem, it seems. I think it's a result of having an older version of sqlite3 installed. My OS X 10.4 box has sqlite3 version 3.1.3 installed, and that version doesn't support the 'if not exists ...' syntax. The test works fine on OS X 10.5, with sqlite3 version 3.4.0. I don't know what Python should be doing for older versions of sqlite3. ---------- nosy: +marketdickinson __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 2 23:27:56 2008 From: report at bugs.python.org (Christoph Zwerschke) Date: Sun, 02 Mar 2008 22:27:56 -0000 Subject: [issue2217] Problem with if clause in generator expression on class level In-Reply-To: <1204479817.59.0.844396901804.issue2217@psf.upfronthosting.co.za> Message-ID: <1204496876.92.0.69876725869.issue2217@psf.upfronthosting.co.za> Christoph Zwerschke added the comment: Thanks, this now makes sense to me. You're right, it's rather an ugly wart than a bug. But I think the Python reference needs to be improved to make this clear enough. How about the following proposed addtions (in square brackets) to section 5.2.5 (http://docs.python.org/ref/genexpr.html): "Variables used in the generator expression are evaluated lazily [in the scope of the generator function] when the next() method is called for [the] generator object (in the same fashion as normal generators). However, the leftmost for clause is immediately evaluated [in the current scope] so that [an] error produced by it can be seen before any other possible error in the code that handles the generator expression. Subsequent for [and if] clauses cannot be evaluated immediately since they may depend on the previous for loop." __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 00:16:09 2008 From: report at bugs.python.org (Jean Brouwers) Date: Sun, 02 Mar 2008 23:16:09 -0000 Subject: [issue2215] test_sqlite fails in 2.6a1 on MacOS X In-Reply-To: <1204422139.64.0.558749633793.issue2215@psf.upfronthosting.co.za> Message-ID: <1204499769.37.0.977047662616.issue2215@psf.upfronthosting.co.za> Jean Brouwers added the comment: Just for the record, the test continues to fail if rerun with 2.6a1. However, the (same?) test does *not* fail with 3.0a3 built on the same MacOS X system. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 00:17:47 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 02 Mar 2008 23:17:47 -0000 Subject: [issue2215] test_sqlite fails in 2.6a1 on MacOS X In-Reply-To: <1204422139.64.0.558749633793.issue2215@psf.upfronthosting.co.za> Message-ID: <1204499867.37.0.0964222622919.issue2215@psf.upfronthosting.co.za> Christian Heimes added the comment: Some modifications to the 2.6 code base didn't make it into 3.0 in time. See r61141 ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 00:21:33 2008 From: report at bugs.python.org (Jean Brouwers) Date: Sun, 02 Mar 2008 23:21:33 -0000 Subject: [issue2215] test_sqlite fails in 2.6a1 on MacOS X In-Reply-To: <1204422139.64.0.558749633793.issue2215@psf.upfronthosting.co.za> Message-ID: <1204500093.13.0.996817076125.issue2215@psf.upfronthosting.co.za> Jean Brouwers added the comment: In addition, the sqlite test did *not* fail with 2.5.2 and 2.5.1 built on the same MacOS X machine, about one week resp. several months ago. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 00:22:48 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 02 Mar 2008 23:22:48 -0000 Subject: [issue1736190] asyncore/asynchat patches Message-ID: <1204500168.08.0.787309103445.issue1736190@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: I've discussed a lot with Josiah via e-mail and this is the updated version of the patch including a fix for the two issues raised before. This update has been needed also because the original patch has been out-dated by some commits after r53734 involving the test suite and the documentation, which I both took off this patch. I also re-added simple_producer and fifo classes in asynchat.py since it seems they are needed for passing tests. The test suite has passed on Windows XP using Python 2.6 alpha 1. I have also successfully run the test suite of a project of mine based on asynchat which includes over 40 tests. Added file: http://bugs.python.org/file9587/patch.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 3 00:45:11 2008 From: report at bugs.python.org (Jean Brouwers) Date: Sun, 02 Mar 2008 23:45:11 -0000 Subject: [issue2218] Enhanced hotshot profiler with high-resolution timer In-Reply-To: <1204501511.28.0.993763550383.issue2218@psf.upfronthosting.co.za> Message-ID: <1204501511.28.0.993763550383.issue2218@psf.upfronthosting.co.za> New submission from Jean Brouwers: The _hotshot module uses the gettimeofday function to profile the run time. I enhanced the hotshot module in Python 2.5.2 to use a high resolution timer where available (RDTSC on x86/_64, MFTB/U on PowerPC and gethrtime on Solaris). The improved hotshot module has been tested on 32-bit MacOS X 10.4.11 Tiger (Intel) and 10.3.9 Panther (PPC), on 64-bit RHEL 3u7 (Opteron) and on 64-bit Solaris 10. The 3 modified files are Modules/_hotshot.c, Lib/hotshot/log.py and Lib/hotshot/stats.py are attached. ---------- components: Extension Modules files: hires_hotshot.tgz messages: 63194 nosy: MrJean1 severity: normal status: open title: Enhanced hotshot profiler with high-resolution timer type: feature request versions: Python 2.5 Added file: http://bugs.python.org/file9588/hires_hotshot.tgz __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 01:06:47 2008 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Mon, 03 Mar 2008 00:06:47 -0000 Subject: [issue2215] test_sqlite fails in 2.6a1 on MacOS X In-Reply-To: <1204422139.64.0.558749633793.issue2215@psf.upfronthosting.co.za> Message-ID: <1204502807.0.0.61480703174.issue2215@psf.upfronthosting.co.za> Gerhard H?ring added the comment: Revision 61141 made the test work with old SQLite versions. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 01:07:08 2008 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Mon, 03 Mar 2008 00:07:08 -0000 Subject: [issue2215] test_sqlite fails in 2.6a1 on MacOS X In-Reply-To: <1204422139.64.0.558749633793.issue2215@psf.upfronthosting.co.za> Message-ID: <1204502828.54.0.900630468231.issue2215@psf.upfronthosting.co.za> Changes by Gerhard H?ring: __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 01:07:47 2008 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Mon, 03 Mar 2008 00:07:47 -0000 Subject: [issue2215] test_sqlite fails in 2.6a1 on MacOS X In-Reply-To: <1204422139.64.0.558749633793.issue2215@psf.upfronthosting.co.za> Message-ID: <1204502867.26.0.219077479511.issue2215@psf.upfronthosting.co.za> Gerhard H?ring added the comment: r61174 made the tests work with old SQLite versions. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 01:29:46 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 03 Mar 2008 00:29:46 -0000 Subject: [issue2179] with should be as fast as try/finally In-Reply-To: <1203894641.18.0.492382147443.issue2179@psf.upfronthosting.co.za> Message-ID: <1204504186.96.0.866163577367.issue2179@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Here's a proof-of-concept patch that keeps the __exit__ method on the stack. It uses ROT_TWO to stuff it under the context object instead of storing it into a temporary. (Thanks Nick for pointing out that problem before I had to waste time on it.) test_with passes, although I need to update several more things and maybe fix a refleak. The patch changes the compilation of: def with_(l): with l: pass from 4 0 LOAD_FAST 0 (l) 3 DUP_TOP 4 LOAD_ATTR 0 (__exit__) 7 STORE_FAST 1 (_[1]) 10 LOAD_ATTR 1 (__enter__) 13 CALL_FUNCTION 0 16 POP_TOP 17 SETUP_FINALLY 4 (to 24) 5 20 POP_BLOCK 21 LOAD_CONST 0 (None) >> 24 LOAD_FAST 1 (_[1]) 27 DELETE_FAST 1 (_[1]) 30 WITH_CLEANUP 31 END_FINALLY 32 LOAD_CONST 0 (None) 35 RETURN_VALUE to 4 0 LOAD_FAST 0 (l) 3 DUP_TOP 4 LOAD_ATTR 0 (__exit__) 7 ROT_TWO 8 LOAD_ATTR 1 (__enter__) 11 CALL_FUNCTION 0 14 POP_TOP 15 SETUP_FINALLY 4 (to 22) 5 18 POP_BLOCK 19 LOAD_CONST 0 (None) >> 22 WITH_CLEANUP 23 END_FINALLY 24 LOAD_CONST 0 (None) 27 RETURN_VALUE And speeds it up from: $ ./python.exe -m timeit -s 'import thread; lock = thread.allocate_lock()' 'with lock: pass' 1000000 loops, best of 3: 0.832 usec per loop to: $ ./python.exe -m timeit -s 'import thread; lock = thread.allocate_lock()' 'with lock: pass' 1000000 loops, best of 3: 0.762 usec per loop That's only half of the way to parity with try/finally: $ ./python.exe -m timeit -s 'import thread; lock = thread.allocate_lock()' 'lock.acquire()' 'try: pass' 'finally: lock.release()' 1000000 loops, best of 3: 0.638 usec per loop What's strange is that calling __enter__ and __exit__ in a try/finally block brings the speed back to the faster 'with' speed, even though they call the same C functions: $ ./python.exe -m timeit -s 'import thread; lock = thread.allocate_lock()' 'lock.__enter__()' 'try: pass' 'finally: lock.__exit__()' 1000000 loops, best of 3: 0.754 usec per loop Any ideas? ---------- keywords: +patch Added file: http://bugs.python.org/file9589/faster_with.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 01:40:02 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 03 Mar 2008 00:40:02 -0000 Subject: [issue1740] use unittest for test_logging In-Reply-To: <1199583606.98.0.490636410107.issue1740@psf.upfronthosting.co.za> Message-ID: <1204504802.58.0.459774623576.issue1740@psf.upfronthosting.co.za> Brett Cannon added the comment: Committed in r61189 on the trunk. Thanks, Antoine! ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 01:40:31 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 03 Mar 2008 00:40:31 -0000 Subject: [issue1740] use unittest for test_logging In-Reply-To: <1199583606.98.0.490636410107.issue1740@psf.upfronthosting.co.za> Message-ID: <1204504831.37.0.301326654822.issue1740@psf.upfronthosting.co.za> Brett Cannon added the comment: Oh, and thanks Thomas for the port change. I made sure to keep it. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 03:34:14 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 03 Mar 2008 02:34:14 -0000 Subject: [issue2179] with should be as fast as try/finally In-Reply-To: <1203894641.18.0.492382147443.issue2179@psf.upfronthosting.co.za> Message-ID: <1204511654.09.0.378570154588.issue2179@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Now with documentation, a working test_compile, and one less refleak. Added file: http://bugs.python.org/file9590/faster_with.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 04:47:14 2008 From: report at bugs.python.org (Tony Nelson) Date: Mon, 03 Mar 2008 03:47:14 -0000 Subject: [issue795081] email.Message param parsing problem II Message-ID: <1204516034.48.0.674320358081.issue795081@psf.upfronthosting.co.za> Tony Nelson added the comment: If I understand RFC2822 3.2.2. Quoted characters (heh), unquoting must be done in one pass, so the current replace().replace() is wrong. It will change '\\"' to '"', but it should become '\"' when unquoted. This seems to work: re.sub(r'\\(.)',r'\1',s) I haven't encountered a problem with this; I just came across it while looking at the file Utils.py (Python 2.4, but unchanged in trunk). I will submit a new bug if desired. ---------- nosy: +tony_nelson ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 3 07:20:14 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 03 Mar 2008 06:20:14 -0000 Subject: [issue1107887] Speed up function calls/can add more introspection info Message-ID: <1204525214.1.0.171575725825.issue1107887@psf.upfronthosting.co.za> Changes by Jeffrey Yasskin: ---------- nosy: +jyasskin _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 3 09:12:37 2008 From: report at bugs.python.org (Mark Summerfield) Date: Mon, 03 Mar 2008 08:12:37 -0000 Subject: [issue2219] Py30a3: Possibly confusing message when module detection fails In-Reply-To: <1204531957.41.0.514268836397.issue2219@psf.upfronthosting.co.za> Message-ID: <1204531957.41.0.514268836397.issue2219@psf.upfronthosting.co.za> New submission from Mark Summerfield: On Fedora 8 I get this message: Failed to find the necessary bits to build these modules: _bsddb To find the necessary bits, look in setup.py in detect_modules() for the module's name. On Kubuntu 6.06 LTS I get the same message, but about different modules: _hashlib _ssl bz2 In previous versions when headers or libraries couldn't be found I thought the correct file to change was Modules/Setup or Modules/Setup.local. If this is still the case then the above error message should perhaps be changed? BTW For Fedora 8, bsddb won't work since according to Modules/Setup the most recent version supported is 4.0 while Fedora 8 has 4.4. ---------- components: Build messages: 63202 nosy: mark severity: normal status: open title: Py30a3: Possibly confusing message when module detection fails versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 09:35:38 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 03 Mar 2008 08:35:38 -0000 Subject: [issue2219] Py30a3: Possibly confusing message when module detection fails In-Reply-To: <1204531957.41.0.514268836397.issue2219@psf.upfronthosting.co.za> Message-ID: <1204533338.23.0.199110297918.issue2219@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Modules/Setup is out of date; _bsddb supports anything between 3.3 and 4.5. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 09:52:19 2008 From: report at bugs.python.org (Mark Summerfield) Date: Mon, 03 Mar 2008 08:52:19 -0000 Subject: [issue2219] Py30a3: Possibly confusing message when module detection fails In-Reply-To: <1204533338.23.0.199110297918.issue2219@psf.upfronthosting.co.za> Message-ID: <200803030848.29221.mark@qtrac.eu> Mark Summerfield added the comment: On 2008-03-03, Martin v. L?wis wrote: > Martin v. L?wis added the comment: > > Modules/Setup is out of date; _bsddb supports anything between 3.3 and 4.5. > FYI, only now I've just realised that Fedora 8's db version is 4.6.21, but I thought I'd try it anyway. % locate db-4.6 /lib/libdb-4.6.so /usr/lib/libdb-4.6.a /usr/lib/libdb-4.6.la /usr/lib/libdb-4.6.so % ls -l /usr/include/db.h lrwxrwxrwx 1 root root 8 2008-01-10 14:57 /usr/include/db.h -> db4/db.h I edited Modules/Setup as follows: DB=/usr DBLIBVER=4.6 DBINC=$(DB)/include DBLIB=$(DB)/lib _bsddb _bsddb.c -I$(DBINC) -L$(DBLIB) -ldb-$(DBLIBVER) The last gcc call is this: gcc -pthread -Xlinker -export-dynamic -o python \ Modules/python.o \ libpython3.0.a -lpthread -ldl -lutil -L/usr/lib -ldb-4.6 -lm running build running build_ext Failed to find the necessary bits to build these modules: _bsddb I can't see the DB -I or -L lines but I'm no makefile expert so maybe they come from somewhere else. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 10:02:08 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 03 Mar 2008 09:02:08 -0000 Subject: [issue2219] Py30a3: Possibly confusing message when module detection fails In-Reply-To: <1204531957.41.0.514268836397.issue2219@psf.upfronthosting.co.za> Message-ID: <1204534928.95.0.947552058756.issue2219@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Rereading your report, I cannot quite understand what issue specifically you are reporting. What error message do you find confusing, and what do you think should it say instead? In any case, it is deliberate that db 4.6 is not supported - that release doesn't really work. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 10:44:22 2008 From: report at bugs.python.org (Mark Summerfield) Date: Mon, 03 Mar 2008 09:44:22 -0000 Subject: [issue2219] Py30a3: Possibly confusing message when module detection fails In-Reply-To: <1204534928.95.0.947552058756.issue2219@psf.upfronthosting.co.za> Message-ID: <200803030940.31997.mark@qtrac.eu> Mark Summerfield added the comment: On 2008-03-03, Martin v. L?wis wrote: > Martin v. L?wis added the comment: > > Rereading your report, I cannot quite understand what issue specifically > you are reporting. What error message do you find confusing, and what do > you think should it say instead? What I find confusing is: Failed to find the necessary bits to build these modules: To find the necessary bits, look in setup.py in detect_modules() for the module's name. I find it confusing because AFAIK if a module can't be built it usually means that you should change the Modules/Setup file and not setup.py itself. (My impression is that the message is aimed at Python developers rather than Python users.) If Modules/Setup is still the correct file for users to edit perhaps the message should be something like: Failed to find the necessary bits to build these modules: If you want these modules and they are on your system, try editing Modules/Setup to be able to find them. > In any case, it is deliberate that db 4.6 is not supported - that > release doesn't really work. OK. (But that is a pity since a lot of people use Fedora 8.) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 11:39:31 2008 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 03 Mar 2008 10:39:31 -0000 Subject: [issue2216] Problems using logging module with idle In-Reply-To: <1204466149.08.0.371697565628.issue2216@psf.upfronthosting.co.za> Message-ID: <1204540771.05.0.79750607345.issue2216@psf.upfronthosting.co.za> Vinay Sajip added the comment: I don't think this is a bug, though possibly the documentation could be clarified. The shutdown() method is meant to be called at application exit; its main purpose is to flush any output in handler buffers. It doesn't do a complete reversal of what basicConfig() does. I'll keep this as pending to remind me to update the documentation for shutdown(). ---------- assignee: -> vsajip nosy: +vsajip resolution: -> invalid status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 11:49:39 2008 From: report at bugs.python.org (Lorenz Quack) Date: Mon, 03 Mar 2008 10:49:39 -0000 Subject: [issue2220] bug in rlcompleter In-Reply-To: <1204541379.7.0.080847401337.issue2220@psf.upfronthosting.co.za> Message-ID: <1204541379.7.0.080847401337.issue2220@psf.upfronthosting.co.za> New submission from Lorenz Quack: The following code would raise a TypeError: >>> rlcompleter.Completer().complete("print self.foo", 0) with this fix it will just return None ---------- components: Library (Lib) files: rlcompleter.patch keywords: patch messages: 63208 nosy: donlorenzo severity: normal status: open title: bug in rlcompleter type: crash versions: Python 2.5 Added file: http://bugs.python.org/file9591/rlcompleter.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 12:34:29 2008 From: report at bugs.python.org (Mark Summerfield) Date: Mon, 03 Mar 2008 11:34:29 -0000 Subject: [issue2221] Py30a3: calltip produces error output to stderr In-Reply-To: <1204544069.74.0.858936575145.issue2221@psf.upfronthosting.co.za> Message-ID: <1204544069.74.0.858936575145.issue2221@psf.upfronthosting.co.za> New submission from Mark Summerfield: In IDLE for Py30a3 if you enter: >>> class A( as soon as you type the ( you get the following output to stderr (on Fedora 8 with Tcl/Tk 8.4): : *** Internal Error: rpc.py:SocketIO.localcall() Object: exec Method: > Args: ('A',) Traceback (most recent call last): File "/home/mark/opt/python30a3/lib/python3.0/idlelib/rpc.py", line 188, in localcall ret = method(*args, **kwargs) File "/home/mark/opt/python30a3/lib/python3.0/idlelib/run.py", line 316, in get_the_calltip return self.calltip.fetch_tip(name) File "/home/mark/opt/python30a3/lib/python3.0/idlelib/CallTips.py", line 103, in fetch_tip entity = self.get_entity(name) File "/home/mark/opt/python30a3/lib/python3.0/idlelib/CallTips.py", line 112, in get_entity return eval(name, namespace) SystemError: error return without exception set It does not appear to affect IDLE's functionality. ---------- components: IDLE messages: 63209 nosy: mark severity: minor status: open title: Py30a3: calltip produces error output to stderr versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 12:44:01 2008 From: report at bugs.python.org (Andrea Griffini) Date: Mon, 03 Mar 2008 11:44:01 -0000 Subject: [issue2216] Problems using logging module with idle In-Reply-To: <1204466149.08.0.371697565628.issue2216@psf.upfronthosting.co.za> Message-ID: <1204544641.93.0.838688288715.issue2216@psf.upfronthosting.co.za> Andrea Griffini added the comment: I thougt it was a bug because when calling close() handlers are removed from some data structure (the global dictionary and the global list) but they're left inside the loggers they're attached to. Now I understand that this is a responsibility of who attached the handler; probably my patch would break or just behave differently with code that already managed to remove logging handlers from loggers explicitly or that relied on the fact that even a "closed" handler can still be notified. Having the logging module to work correctly in IDLE and other environments that keep a running instance of the interpreter provided that shutdown is called would have been just a lucky nice side effect of "fixing" handler.close (of course those IDEs will still have potential problems with any module that keeps an internal state). __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 14:05:34 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Mon, 03 Mar 2008 13:05:34 -0000 Subject: [issue2222] Memory leak in os.rename? In-Reply-To: <1204549533.94.0.102574866059.issue2222@psf.upfronthosting.co.za> Message-ID: <1204549533.94.0.102574866059.issue2222@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto: Hello. Probably I found memory leak. When first convert_to_unicode succeeds and second one fails, first unicode object is not freed. # ex: os.rename("a", 3) Thank you. ---------- components: Extension Modules files: fix_leak.patch keywords: patch messages: 63211 nosy: ocean-city severity: normal status: open title: Memory leak in os.rename? type: resource usage versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9592/fix_leak.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 15:01:34 2008 From: report at bugs.python.org (Lorenz Quack) Date: Mon, 03 Mar 2008 14:01:34 -0000 Subject: [issue2220] bug in rlcompleter In-Reply-To: <1204541379.7.0.080847401337.issue2220@psf.upfronthosting.co.za> Message-ID: <1204552894.08.0.276145859015.issue2220@psf.upfronthosting.co.za> Lorenz Quack added the comment: Some more information: the dot in the example causes complete() to call self.attr_matches(text) which in turn performes the following call re.match(r"(\w+(\.\w+)*)\.(\w*)", text) and return None if there is no match. the complete method unconditionally accesses the return value like a list via matches[state] which raises the TypeError. The obvious solution was to return an empty list instead of None which is also the behaviour in all other cases where no completion is found. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 15:11:49 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 03 Mar 2008 14:11:49 -0000 Subject: [issue2221] Py30a3: calltip produces error output to stderr In-Reply-To: <1204544069.74.0.858936575145.issue2221@psf.upfronthosting.co.za> Message-ID: <1204553509.51.0.614524508921.issue2221@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> kbk nosy: +kbk priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 16:12:57 2008 From: report at bugs.python.org (Lev Shamardin) Date: Mon, 03 Mar 2008 15:12:57 -0000 Subject: [issue2200] find_executable fails to find .bat files on win32 In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za> Message-ID: <1204557177.74.0.86459809828.issue2200@psf.upfronthosting.co.za> Lev Shamardin added the comment: I can't see this issue on the 'open issues' list nor in the search results. Is something wrong? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 16:16:52 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Mar 2008 15:16:52 -0000 Subject: [issue2222] Memory leak in os.rename? In-Reply-To: <1204549533.94.0.102574866059.issue2222@psf.upfronthosting.co.za> Message-ID: <1204557412.38.0.283176542337.issue2222@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: It looks like non-windows code has a similar problem: static PyObject * posix_2str(PyObject *args, char *format, int (*func)(const char *, const char *)) { char *path1 = NULL, *path2 = NULL; int res; if (!PyArg_ParseTuple(args, format, Py_FileSystemDefaultEncoding, &path1, Py_FileSystemDefaultEncoding, &path2)) return NULL; If decoding of path2 fails, path1 is never freed. On the patch itself, arguably Py_XDECREF(o2) is not necessary, but leaving it in is probably good defensive programming (e.g. if more args are added in the future.) I am +1 on the patch as is. Please add a unit test that exercises the new code. Check that the leak is detected when the unit test is ran with gc.set_debug(gc.DEBUG_LEAK). ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 16:27:57 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Mar 2008 15:27:57 -0000 Subject: [issue2179] with should be as fast as try/finally In-Reply-To: <1203894641.18.0.492382147443.issue2179@psf.upfronthosting.co.za> Message-ID: <1204558077.06.0.21217655206.issue2179@psf.upfronthosting.co.za> Changes by Alexander Belopolsky: ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 17:27:09 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Mon, 03 Mar 2008 16:27:09 -0000 Subject: [issue2223] regrtest.py -R not working In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> Message-ID: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto: Sorry, I don't have patch, but regrtest.py -R not working now. E:\python-dev\trunk\Lib\test>py25 regrtest.py -R :: test_grammar test_grammar skipped -- No module named _abcoll E:\python-dev\trunk\Lib\test>py regrtest.py -R :: test_grammar test_grammar skipped -- cannot import name _Abstract E:\python-dev\trunk\Lib\test>py3k regrtest.py -R :: File "regrtest.py", line 174 print __doc__ ^ SyntaxError: invalid syntax ---------- components: Tests messages: 63215 nosy: ocean-city severity: normal status: open title: regrtest.py -R not working type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 17:57:39 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 03 Mar 2008 16:57:39 -0000 Subject: [issue2200] find_executable fails to find .bat files on win32 In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za> Message-ID: <1204563459.22.0.766641124291.issue2200@psf.upfronthosting.co.za> Christian Heimes added the comment: By default issues are sorted by priority. I've given the bug the priority "normal". Have a look on page 3 or 4. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 18:21:21 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Mon, 03 Mar 2008 17:21:21 -0000 Subject: [issue2222] Memory leak in os.rename? In-Reply-To: <1204549533.94.0.102574866059.issue2222@psf.upfronthosting.co.za> Message-ID: <1204564881.66.0.43995483648.issue2222@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: I cannot write patch to use gc.set_debug(gc.DEBUG_LEAK), so I tried regrtest.py -R :: instead. (This functionality is not working now, so I tried after reverted r61098) E:\python-dev\trunk\Lib\test>py regrtest.py -R :: test_os.py test_os beginning 9 repetitions 123456789 ......... test_os leaked [1, 1, 1, 1] references, sum=4 1 test OK. [38282 refs] Added file: http://bugs.python.org/file9593/test_os.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 18:31:28 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 03 Mar 2008 17:31:28 -0000 Subject: [issue2224] branches/trunk-math patch In-Reply-To: <1204565487.81.0.141440413352.issue2224@psf.upfronthosting.co.za> Message-ID: <1204565487.81.0.141440413352.issue2224@psf.upfronthosting.co.za> New submission from Christian Heimes: "svnmerge.py merge" integration patch of Mark and my trunk-math branch. I created the patch to make the review process easier. Name: svnmerge-integrated - /python/branches/trunk-math:1-60195 + /python/branches/trunk-math:1-61203 ---------- components: Interpreter Core files: trunk-math.patch keywords: patch messages: 63218 nosy: marketdickinson, tiran priority: high severity: normal status: open title: branches/trunk-math patch type: feature request versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9594/trunk-math.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 18:44:28 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Mon, 03 Mar 2008 17:44:28 -0000 Subject: [issue2065] trunk version does not compile with vs8 and vc6 In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za> Message-ID: <1204566268.05.0.827325067926.issue2065@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Failed to compile py3k again, created patch for three branches. You can close issue1720 and issue1700463 because they are duplicated issues. # I merged Amaury's patch, I hope this patch also # works for VS8. Added file: http://bugs.python.org/file9595/ocean.zip __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 18:50:03 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Mon, 03 Mar 2008 17:50:03 -0000 Subject: [issue2223] regrtest.py -R not working In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> Message-ID: <1204566603.23.0.195246485422.issue2223@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Sorry, I was stupid. I ran test in wrong directory. release25-maint runs fine, and other two has same error. test_grammar test_grammar skipped -- cannot import name _Abstract ---------- versions: -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 18:53:33 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 03 Mar 2008 17:53:33 -0000 Subject: [issue2223] regrtest.py -R not working In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> Message-ID: <1204566813.83.0.866811302619.issue2223@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm going to work on the issue later ---------- nosy: +tiran priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 19:03:03 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Mar 2008 18:03:03 -0000 Subject: [issue2223] regrtest.py -R not working In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> Message-ID: <1204567383.51.0.114342560519.issue2223@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: It looks like you are running regrtest from the trunk with the py3k interpretor. Works for me. ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 19:17:20 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Mon, 03 Mar 2008 18:17:20 -0000 Subject: [issue2223] regrtest.py -R not working In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> Message-ID: <1204568240.65.0.0916664671564.issue2223@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Yes, I did mistake first, but py3k fails even in correct directory. E:\python-dev\py3k\Lib\test>py3k --version Python 3.0a3+ E:\python-dev\py3k\Lib\test>py3k regrtest.py -R :: test_os.py test_os test_os skipped -- cannot import name _Abstract 1 test skipped: test_os 1 skip unexpected on win32: test_os [43267 refs] abc._Abstract seems to be gone at r61098, but regrtest.py still references to it. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 19:49:55 2008 From: report at bugs.python.org (Jean Brouwers) Date: Mon, 03 Mar 2008 18:49:55 -0000 Subject: [issue2218] Enhanced hotshot profiler with high-resolution timer In-Reply-To: <1204501511.28.0.993763550383.issue2218@psf.upfronthosting.co.za> Message-ID: <1204570195.61.0.463498528419.issue2218@psf.upfronthosting.co.za> Jean Brouwers added the comment: Do *not* use the attached files. A fix is forthcoming. My apologies. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 19:55:04 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Mar 2008 18:55:04 -0000 Subject: [issue2223] regrtest.py -R not working In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> Message-ID: <1204570503.99.0.196566013816.issue2223@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: attached simple patch seems to fix the problem but should be reviewed by Christian. ---------- keywords: +patch Added file: http://bugs.python.org/file9596/regrtest.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 20:15:09 2008 From: report at bugs.python.org (Chris AtLee) Date: Mon, 03 Mar 2008 19:15:09 -0000 Subject: [issue2225] py_compile.main() does not return error code In-Reply-To: <1204571709.66.0.797996976518.issue2225@psf.upfronthosting.co.za> Message-ID: <1204571709.66.0.797996976518.issue2225@psf.upfronthosting.co.za> New submission from Chris AtLee: When using the py_compile module from the command line, and a SyntaxError is encountered, python still exits with a 0 return code. This usually indicates that the process completely successfully. Could py_compile.main() be modified to return a non-zero return code if an exception was raised? ---------- components: Library (Lib) messages: 63226 nosy: catlee severity: normal status: open title: py_compile.main() does not return error code type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 20:23:32 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 03 Mar 2008 19:23:32 -0000 Subject: [issue2223] regrtest.py -R not working In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> Message-ID: <1204572212.42.0.103115007445.issue2223@psf.upfronthosting.co.za> Christian Heimes added the comment: It seems r61204 has fixed the bug. Can you test it on your machine please? My old laptop is too slow. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 20:56:41 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Mar 2008 19:56:41 -0000 Subject: [issue2223] regrtest.py -R not working In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> Message-ID: <1204574201.09.0.049762897184.issue2223@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > Can you test it on your machine please? Running on a 4-core Opteron (2.6GHz). Should complete in an hour or so ... __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 21:02:11 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Mar 2008 20:02:11 -0000 Subject: [issue2223] regrtest.py -R not working In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> Message-ID: <1204574531.36.0.237609841827.issue2223@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: test_collections fails (with -R :: only). Does not look like something related to the recent changes, rather test is not happy about being repeated. $ ./python Lib/test/regrtest.py -R :: test_collections test_collections beginning 9 repetitions 123456789 test test_collections failed -- Traceback (most recent call last): File "Lib/doctest.py", line 2131, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for collections.namedtuple File "Lib/collections.py", line 13, in namedtuple .. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 21:55:02 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Mar 2008 20:55:02 -0000 Subject: [issue2198] code_hash() can be the same for different code objects In-Reply-To: <1204148860.69.0.229152092841.issue2198@psf.upfronthosting.co.za> Message-ID: <1204577702.25.0.313807542836.issue2198@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I would say filename/lineno are excluded from hash on purpose because they are ignored in comparisons: >>> compile("0", "a", "eval") == compile("0", "b", "eval") True Include/code.h has the following comment: /* The rest doesn't count for hash/cmp */ PyObject *co_filename; /* string (where it was loaded from) */ PyObject *co_name; /* string (name, for reference) */ int co_firstlineno; /* first source line number */ .. Can you describe your specific problem in more detail? Why does your debugger need to hash/compare code objects? ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 21:59:46 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 03 Mar 2008 20:59:46 -0000 Subject: [issue2223] regrtest.py -R not working In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> Message-ID: <1204577986.5.0.992852385943.issue2223@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Here are the results from regrtest.py -R :: .. 301 tests OK. 7 tests failed: test_collections test_cprofile test_frozen test_inspect test_logging test_pkg test_profile .. $ cat reflog.txt test_cmd_line leaked [-23, 0, 0, 23] references, sum=0 test_compiler leaked [0, 0, 18, 0] references, sum=18 test_deque leaked [100, 100, 100, 100] references, sum=400 test_ftplib leaked [0, 172, -6, -166] references, sum=0 test_heapq leaked [108, 130, 121, 114] references, sum=473 test_itertools leaked [7380, 7380, 7380, 7380] references, sum=29520 test_list leaked [50, 50, 50, 50] references, sum=200 test_set leaked [680, 680, 680, 680] references, sum=2720 test_smtplib leaked [0, 0, -86, 86] references, sum=0 test_threading leaked [0, 86, -86, 86] references, sum=86 test_urllib2_localnet leaked [3, 3, 3, 3] references, sum=12 test_userlist leaked [50, 50, 50, 50] references, sum=200 Do buildbots run -R regressions? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 22:22:10 2008 From: report at bugs.python.org (Armin Ronacher) Date: Mon, 03 Mar 2008 21:22:10 -0000 Subject: [issue2226] Small _abcoll Bugs / Oddities Message-ID: <1204579330.81.0.211644715466.issue2226@psf.upfronthosting.co.za> Changes by Armin Ronacher: ---------- components: Library (Lib) nosy: aronacher severity: normal status: open title: Small _abcoll Bugs / Oddities versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 22:25:01 2008 From: report at bugs.python.org (Armin Ronacher) Date: Mon, 03 Mar 2008 21:25:01 -0000 Subject: [issue2226] Small _abcoll Bugs / Oddities In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za> Message-ID: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za> New submission from Armin Ronacher: _abcoll.py references intertools.chain but doesn't import it. This breaks Set subclasses. Additionally the abstract base classes don't provide the right hand operator callbacks or how you want to call them. So __add__ is there but __radd__ not which for example leads to the problem that "foo() + set()" works but "set() + foo" not. And the third oddity in that module is that Callable defines an abstract method for __contains__ which makes no sense but none for __call__. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 22:26:32 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 03 Mar 2008 21:26:32 -0000 Subject: [issue2226] Small _abcoll Bugs / Oddities In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za> Message-ID: <1204579592.42.0.912740468932.issue2226@psf.upfronthosting.co.za> Georg Brandl added the comment: I fixed the import in r61211. Raymond, can you sort out the set operations? ---------- assignee: -> rhettinger nosy: +georg.brandl, rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 22:32:41 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 03 Mar 2008 21:32:41 -0000 Subject: [issue2217] Problem with if clause in generator expression on class level In-Reply-To: <1204479817.59.0.844396901804.issue2217@psf.upfronthosting.co.za> Message-ID: <1204579961.03.0.27159454368.issue2217@psf.upfronthosting.co.za> Georg Brandl added the comment: Good idea! I've committed these changes in r61212. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 22:34:36 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Mon, 03 Mar 2008 21:34:36 -0000 Subject: [issue2198] code_hash() can be the same for different code objects In-Reply-To: <1204148860.69.0.229152092841.issue2198@psf.upfronthosting.co.za> Message-ID: <1204580076.97.0.111375655324.issue2198@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: Hashes being equal for different objects cannot be a bug. At most an enhancement request... ---------- nosy: +_doublep __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 22:41:26 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 03 Mar 2008 21:41:26 -0000 Subject: [issue2227] time.strptime too strict? should it assume current year? In-Reply-To: <1204580486.17.0.196786227347.issue2227@psf.upfronthosting.co.za> Message-ID: <1204580486.17.0.196786227347.issue2227@psf.upfronthosting.co.za> New submission from Gregory P. Smith: Some common python utilities had problems on Feb 29 this year when parsing dates using format strings that did not include a year in them. >>> time.strptime('Feb 29', '%b %d') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/_strptime.py", line 425, in strptime julian = datetime_date(year, month, day).toordinal() - \ ValueError: day is out of range for month This is apparently because python assumes the year is 1900 unless it explicitly parses another year out of the string. Applications can work around this by always adding a year and a %Y to the string they are parsing. But not all date manipulating applications care about years. In this case the application was fail2ban, bug report and patches to it here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468382 Should the year default to 1900 (the equivalent of what the much more forgiving C API does by leaving struct tm tm_year = 0) or should this error be raised? If the answer is yes, works as is this is easy and just turns into us adding a note in the documentation to mention the behavior. I do believe this was a valid bug in fail2ban as assuming the current year for date parsing is a bad idea and will do the wrong thing when parsing across a year change. Python's strptime is much more strict than C strptime (glibc's C strptime is happy to return tm_mon 2 tm_mday 31. Its range checking is minimal. here's a C test case to play with its behavior: #include #include #include int main(int argc, char *argv[]) { unsigned long ret, parsed; assert(argc == 2); struct tm tm = { 0 }; ret = strptime(argv[1], "%b %d", &tm); parsed = ret - (unsigned long)(argv[1]); printf("ret 0x%x parsed %d tm_mon %d tm_mday %d tm_year %d\n", ret, parsed, tm.tm_mon, tm.tm_mday, tm.tm_year); } % ./foo 'Feb 28' ret 0xffffda8a parsed 6 tm_mon 1 tm_mday 28 tm_year 0 % ./foo 'Feb 29' ret 0xffffda8a parsed 6 tm_mon 1 tm_mday 29 tm_year 0 % ./foo 'Feb 31' ret 0xffffda8a parsed 6 tm_mon 1 tm_mday 31 tm_year 0 % ./foo 'Feb 32' ret 0x0 parsed 9596 tm_mon 1 tm_mday 0 tm_year 0 ---------- components: Library (Lib) keywords: easy messages: 63236 nosy: gregory.p.smith priority: low severity: minor status: open title: time.strptime too strict? should it assume current year? type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 22:42:06 2008 From: report at bugs.python.org (Aaron Kaplan) Date: Mon, 03 Mar 2008 21:42:06 -0000 Subject: [issue2228] Imaplib speedup patch In-Reply-To: <1204580526.67.0.16390655339.issue2228@psf.upfronthosting.co.za> Message-ID: <1204580526.67.0.16390655339.issue2228@psf.upfronthosting.co.za> New submission from Aaron Kaplan: In some versions of John Goergen's program offlineimap, he includes a copy of imaplib.py with the attached changes. It results in a speedup of more than 50% compared to using the stock imaplib.py. ---------- files: imaplib-patch messages: 63237 nosy: aaronkaplan severity: normal status: open title: Imaplib speedup patch type: resource usage Added file: http://bugs.python.org/file9597/imaplib-patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 23:04:47 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 03 Mar 2008 22:04:47 -0000 Subject: [issue2228] Imaplib speedup patch In-Reply-To: <1204580526.67.0.16390655339.issue2228@psf.upfronthosting.co.za> Message-ID: <1204581886.99.0.835666174726.issue2228@psf.upfronthosting.co.za> Changes by Benjamin Peterson: ---------- nosy: +pierslauder __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 23:08:24 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 03 Mar 2008 22:08:24 -0000 Subject: [issue2218] Enhanced hotshot profiler with high-resolution timer In-Reply-To: <1204501511.28.0.993763550383.issue2218@psf.upfronthosting.co.za> Message-ID: <1204582104.85.0.458343949189.issue2218@psf.upfronthosting.co.za> Changes by Benjamin Peterson: ---------- nosy: +fdrake __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 23:09:23 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 03 Mar 2008 22:09:23 -0000 Subject: [issue2220] bug in rlcompleter In-Reply-To: <1204541379.7.0.080847401337.issue2220@psf.upfronthosting.co.za> Message-ID: <1204582163.13.0.657811722438.issue2220@psf.upfronthosting.co.za> Changes by Benjamin Peterson: ---------- type: crash -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 23:21:53 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 03 Mar 2008 22:21:53 -0000 Subject: [issue2227] time.strptime too strict? should it assume current year? In-Reply-To: <1204580486.17.0.196786227347.issue2227@psf.upfronthosting.co.za> Message-ID: <1204582913.63.0.804412587525.issue2227@psf.upfronthosting.co.za> Brett Cannon added the comment: The documentation already mentions that the default values when information left out is (1900, 1, 1, 0, 0, 0, 0, 1, -1) so the docs are already clear. If you want to generate a patch to make the default year be this year I would be willing to review it and consider applying it. I doubt very much code would break because of this. ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 23:22:05 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 03 Mar 2008 22:22:05 -0000 Subject: [issue2226] Small _abcoll Bugs / Oddities In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za> Message-ID: <1204582925.23.0.718831986537.issue2226@psf.upfronthosting.co.za> Raymond Hettinger added the comment: * Removed the dependency on itertools: r61213. * Fixed nasty cut-and-paste error in Callable: r61214 Leaving the other one for Guido. I suspect the __radd__ style methods are can of worms best left unopened for now. The right solution probably involves visiting every piece of code in Python that makes a concrete isinstance/issubclass test and replacing it with an abstract test. That may have unexpected side-effects, may be hard to test, and may kill performance. ---------- assignee: rhettinger -> gvanrossum nosy: +gvanrossum versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 3 23:46:11 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 03 Mar 2008 22:46:11 -0000 Subject: [issue2219] Py30a3: Possibly confusing message when module detection fails In-Reply-To: <200803030940.31997.mark@qtrac.eu> Message-ID: <47CC7FAF.4040307@v.loewis.de> Martin v. L?wis added the comment: > What I find confusing is: > > Failed to find the necessary bits to build these modules: > > To find the necessary bits, look in setup.py in detect_modules() for the > module's name. > > I find it confusing because AFAIK if a module can't be built it usually > means that you should change the Modules/Setup file and not setup.py > itself. (My impression is that the message is aimed at Python developers > rather than Python users.) No, not at all. If you see that message, it usually means you are on a Linux system, and you have forgotten to install the header files for the library the module relies on. You need to look into setup.py to find out what those header files are, and install them. Changing Modules/Setup won't help at all, as you don't *have* the header files. It's true that sometimes, you can work around the problem by editing Modules/Setup (in particular, if your system is not Linux). However, this is not the case the message is aimed at. > If Modules/Setup is still the correct file > for users to edit Yes, it is. > perhaps the message should be something like: > > Failed to find the necessary bits to build these modules: > > If you want these modules and they are on your system, try editing > Modules/Setup to be able to find them. No, that change should not be made. >> In any case, it is deliberate that db 4.6 is not supported - that >> release doesn't really work. > > OK. (But that is a pity since a lot of people use Fedora 8.) Please complain to Oracle. Regards, Martin __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 01:33:00 2008 From: report at bugs.python.org (Miki Tebeka) Date: Tue, 04 Mar 2008 00:33:00 -0000 Subject: [issue2229] Search in 2.6 docs does not work In-Reply-To: <1204590780.07.0.631438682332.issue2229@psf.upfronthosting.co.za> Message-ID: <1204590780.07.0.631438682332.issue2229@psf.upfronthosting.co.za> New submission from Miki Tebeka: Try searching for anything on http://docs.python.org/dev/search.html No result is shown (at least on FireFox and IE7). ---------- components: Documentation messages: 63242 nosy: tebeka severity: normal status: open title: Search in 2.6 docs does not work type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 03:22:25 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 04 Mar 2008 02:22:25 -0000 Subject: [issue2230] Document PyArg_Parse* behavior on failed conversion In-Reply-To: <1204597345.35.0.8894806646.issue2230@psf.upfronthosting.co.za> Message-ID: <1204597345.35.0.8894806646.issue2230@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: Much of existing code relies on PyArg_Parse* leaving C variables unmodified when conversion failed. Attached patch documents that behavior. ---------- files: doc-arg.diff keywords: patch messages: 63243 nosy: belopolsky severity: normal status: open title: Document PyArg_Parse* behavior on failed conversion Added file: http://bugs.python.org/file9598/doc-arg.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 03:23:19 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 04 Mar 2008 02:23:19 -0000 Subject: [issue2230] Document PyArg_Parse* behavior on failed conversion In-Reply-To: <1204597345.35.0.8894806646.issue2230@psf.upfronthosting.co.za> Message-ID: <1204597399.2.0.762785198958.issue2230@psf.upfronthosting.co.za> Changes by Alexander Belopolsky: ---------- components: +Documentation severity: normal -> minor type: -> feature request versions: +Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 04:38:25 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 04 Mar 2008 03:38:25 -0000 Subject: [issue2230] Document PyArg_Parse* behavior on failed conversion In-Reply-To: <1204597345.35.0.8894806646.issue2230@psf.upfronthosting.co.za> Message-ID: <1204601905.57.0.327616503903.issue2230@psf.upfronthosting.co.za> Changes by Benjamin Peterson: ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 05:27:17 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Tue, 04 Mar 2008 04:27:17 -0000 Subject: [issue2223] regrtest.py -R not working In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> Message-ID: <1204604837.18.0.316976859447.issue2223@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: I can see test_collections.py failure even on r61203 (just before Christian's commit) - r61098 (removed abc._Abstract) E:\python-dev\trunk\Lib\test>py regrtest.py -R :: test_collections.py test_collections beginning 9 repetitions 123456789 test test_collections failed -- Traceback (most recent call last): File "e:\python-dev\trunk\lib\doctest.py", line 2131, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for collections.namedtuple File "e:\python-dev\trunk\lib\collections.py", line 13, in namedtuple ---------------------------------------------------------------------- File "e:\python-dev\trunk\lib\collections.py", line 16, in collections.namedtupl e Failed example: Point = namedtuple('Point', 'x y') Exception raised: Traceback (most recent call last): File "e:\python-dev\trunk\lib\doctest.py", line 1231, in __run compileflags, 1) in test.globs File "", line 1, in Point = namedtuple('Point', 'x y') NameError: name 'namedtuple' is not defined (snip) I'll run py regrtest.py -R :: on r61203 - r61098 and compare its result to Alexander's result, but my machine is damn slow, probably it'll take long time. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 07:52:25 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 04 Mar 2008 06:52:25 -0000 Subject: [issue2226] Small _abcoll Bugs / Oddities In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za> Message-ID: <1204613545.61.0.111901409143.issue2226@psf.upfronthosting.co.za> Changes by Raymond Hettinger: __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 07:59:21 2008 From: report at bugs.python.org (Mark Summerfield) Date: Tue, 04 Mar 2008 06:59:21 -0000 Subject: [issue2219] Py30a3: Possibly confusing message when module detection fails In-Reply-To: <47CC7FAF.4040307@v.loewis.de> Message-ID: <200803040655.23491.mark@qtrac.eu> Mark Summerfield added the comment: On 2008-03-03, Martin v. L?wis wrote: > Martin v. L?wis added the comment: > > What I find confusing is: > > > > Failed to find the necessary bits to build these modules: > > > > To find the necessary bits, look in setup.py in detect_modules() for the > > module's name. > > > > I find it confusing because AFAIK if a module can't be built it usually > > means that you should change the Modules/Setup file and not setup.py > > itself. (My impression is that the message is aimed at Python developers > > rather than Python users.) > > No, not at all. If you see that message, it usually means you are on > a Linux system, and you have forgotten to install the header files > for the library the module relies on. You need to look into setup.py > to find out what those header files are, and install them. Changing > Modules/Setup won't help at all, as you don't *have* the header > files. Then why isn't the message something like: Failed to find the necessary bits to build these modules: To find the necessary bits, look in setup.py in detect_modules() for the module's name and the header files it requires. [snip] > >> In any case, it is deliberate that db 4.6 is not supported - that > >> release doesn't really work. > > > > OK. (But that is a pity since a lot of people use Fedora 8.) > > Please complain to Oracle. I thought it was owned by Berkeley University... oh well. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 08:33:41 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 04 Mar 2008 07:33:41 -0000 Subject: [issue2230] Document PyArg_Parse* behavior on failed conversion In-Reply-To: <1204597345.35.0.8894806646.issue2230@psf.upfronthosting.co.za> Message-ID: <1204616021.86.0.0638970318625.issue2230@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed in r61226, thank you! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 08:37:54 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 04 Mar 2008 07:37:54 -0000 Subject: [issue2229] Search in 2.6 docs does not work In-Reply-To: <1204590780.07.0.631438682332.issue2229@psf.upfronthosting.co.za> Message-ID: <1204616274.28.0.226829948944.issue2229@psf.upfronthosting.co.za> Georg Brandl added the comment: This is known and will be fixed before final release. ---------- nosy: +georg.brandl resolution: -> later status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 10:03:06 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Tue, 04 Mar 2008 09:03:06 -0000 Subject: [issue2223] regrtest.py -R not working In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> Message-ID: <1204621386.86.0.821602878141.issue2223@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: >I'll run py regrtest.py -R :: on r61203 - r61098 and compare its >result to Alexander's result, but my machine is damn slow, probably >it'll take long time. Sorry, I abandoned this at test_compiler. Please forget this sentense... Anyway, Christian's fix greatly works for me. Thanks! >E:\python-dev\trunk\Lib\test>py regrtest.py -R :: test_collections.py For this error, I could write a minimam code to reproduce it. Please expand the attached zip file into lib/test and run a.py. You'll see similar error. Added file: http://bugs.python.org/file9599/doctest_twice.zip __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 10:21:52 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 04 Mar 2008 09:21:52 -0000 Subject: [issue2127] sqlite3 docs should mention utf8 requirement In-Reply-To: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za> Message-ID: <1204622512.86.0.447263810397.issue2127@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Sorry, my patch corrected only sqlite3.Connection(). I join a new version, which also changes sqlite3.connect(). By the way, the test should test that the file is created with the correct name. A call to os.stat() could be enough. Added file: http://bugs.python.org/file9600/sqlite_connect2.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 10:22:02 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 04 Mar 2008 09:22:02 -0000 Subject: [issue2127] sqlite3 docs should mention utf8 requirement In-Reply-To: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za> Message-ID: <1204622522.43.0.763969467601.issue2127@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc: Removed file: http://bugs.python.org/file9474/sqlite_connect.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 11:39:31 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Tue, 04 Mar 2008 10:39:31 -0000 Subject: [issue2223] regrtest.py -R not working In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> Message-ID: <1204627171.16.0.804680556945.issue2223@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: I wrote simple patch to workaround this problem. (avoid to reuse DocTestSuite) # To my eyes, doctest.DocTestSuite(module=collections) # and test_support.run_doctest(collections, verbose) # are doing same test??? Added file: http://bugs.python.org/file9601/fix_test_collections.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 13:54:35 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 04 Mar 2008 12:54:35 -0000 Subject: [issue2222] Memory leak in os.rename? In-Reply-To: <1204549533.94.0.102574866059.issue2222@psf.upfronthosting.co.za> Message-ID: <1204635275.89.0.888171602239.issue2222@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: The affected code is the only case I could find in stdlib where O& format was used to populate PyObject* variables. Although it appears to be valid usage, the code presents an exception to the following note at http://docs.python.org/dev/c-api/arg.html : "Note that any Python object references which are provided to the caller are borrowed references; do not decrement their reference count!" Should we add that O& a possible exception to this rule? I'll propose a specific change if we agree in principle. I am not sure if O& documentation should make any recommendations to the writers of conversion functions. For example, O& convertors returning a borrowed reference may be discouraged in favor of O or O& variants or returning PyObject* from a convertor may be discouraged altogether. I am adding Georg who accepted my other documentation changes in this area to the "nosy" list. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 14:10:44 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Tue, 04 Mar 2008 13:10:44 -0000 Subject: [issue2231] Memory leak in itertools.chain() In-Reply-To: <1204636244.39.0.268718353736.issue2231@psf.upfronthosting.co.za> Message-ID: <1204636244.39.0.268718353736.issue2231@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto: Fixed memory leak in itertools.chain(). This fixes following refleak errors shown in issue2223. test_deque test_heapq test_itertools test_list test_set test_userlist ---------- components: Extension Modules files: fix_leak.patch keywords: patch messages: 63252 nosy: ocean-city severity: normal status: open title: Memory leak in itertools.chain() type: resource usage versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9602/fix_leak.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 14:54:29 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 04 Mar 2008 13:54:29 -0000 Subject: [issue2231] Memory leak in itertools.chain() In-Reply-To: <1204636244.39.0.268718353736.issue2231@psf.upfronthosting.co.za> Message-ID: <1204638869.93.0.640545189906.issue2231@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Good catch, Hirokazu! The patch looks correct to me. Works as advertised on Mac OS 10.4. ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 17:26:27 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 04 Mar 2008 16:26:27 -0000 Subject: [issue2231] Memory leak in itertools.chain() In-Reply-To: <1204636244.39.0.268718353736.issue2231@psf.upfronthosting.co.za> Message-ID: <1204647987.82.0.956691824485.issue2231@psf.upfronthosting.co.za> Changes by Raymond Hettinger: ---------- assignee: -> rhettinger nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 17:27:20 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 04 Mar 2008 16:27:20 -0000 Subject: [issue2223] regrtest.py -R not working In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> Message-ID: <1204648040.31.0.386938499282.issue2223@psf.upfronthosting.co.za> Changes by Raymond Hettinger: ---------- assignee: -> rhettinger nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 18:01:21 2008 From: report at bugs.python.org (Trent Nelson) Date: Tue, 04 Mar 2008 17:01:21 -0000 Subject: [issue2232] Current os.tmpfile() implementation requires admin privs on Vista/2k8. In-Reply-To: <1204650081.4.0.741104668485.issue2232@psf.upfronthosting.co.za> Message-ID: <1204650081.4.0.741104668485.issue2232@psf.upfronthosting.co.za> New submission from Trent Nelson: posix_tmpfile() needs to be reworked such that tmpfile() isn't used if MS_WINDOWS is defined, as it requires administrative privileges to run (it creates the file in the root directory) on Vista/2k8 (although there are reports of this not working on XP w/ 2.5: http://www.thescripts.com/forum/thread600423.html). The recommended approach in MSDN is to use, quote, "tmpname or tempnam in conjunction with fopen": http://msdn2.microsoft.com/en- us/library/x8x7sakw(VS.80).aspx Assuming no one beats me to it, I'll look at creating a patch in the next day or two when I get some spare time. ---------- components: Windows messages: 63254 nosy: Trent.Nelson severity: normal status: open title: Current os.tmpfile() implementation requires admin privs on Vista/2k8. type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 18:14:23 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 04 Mar 2008 17:14:23 -0000 Subject: [issue2222] Memory leak in os.rename? In-Reply-To: <1204549533.94.0.102574866059.issue2222@psf.upfronthosting.co.za> Message-ID: <1204650863.03.0.364120475511.issue2222@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: On the test_os patch: I would rename LeakTest to ErrorTest and leave it on for all platforms. BTW, I cannot produce a definitive proof that posix_2str leaks when second conversion fails (regrtest -R does not catch it because the leaked buffer is not a PyObject). Nevertheless, it would be a good idea to add tests that exercise os.rename("foo", 0), os.link("foo", 0) and os.symlink("foo", 0) errors on all platforms. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 18:26:01 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Tue, 04 Mar 2008 17:26:01 -0000 Subject: [issue2225] py_compile.main() does not return error code In-Reply-To: <1204571709.66.0.797996976518.issue2225@psf.upfronthosting.co.za> Message-ID: <1204651561.21.0.0332172539934.issue2225@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 18:47:51 2008 From: report at bugs.python.org (Jason Tishler) Date: Tue, 04 Mar 2008 17:47:51 -0000 Subject: [issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail In-Reply-To: <1204652870.95.0.330326965123.issue2233@psf.upfronthosting.co.za> Message-ID: <1204652870.95.0.330326965123.issue2233@psf.upfronthosting.co.za> New submission from Jason Tishler: Makefile.pre.in contains extra slash before $(DESTDIR) in two locations as in the following: sharedinstall: $(RUNSHARED) ./$(BUILDPYTHON) -E $(srcdir)/setup.py install \ --prefix=$(prefix) \ --install-scripts=$(BINDIR) \ --install-platlib=$(DESTSHARED) \ --root=/$(DESTDIR) This causes Cygwin builds to fail if DESTDIR is set as follows: creating //tmp error: could not create '//tmp': No such host or network path The following Open Group Specification: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html indicates the following: 4.11 Pathanme Resolution [snip] A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner,... IMO, these extra slashes should be removed as indicated in the attached patch. OK to commit? If so, to which branches? ---------- assignee: jlt63 components: Build files: python.patch keywords: patch, patch messages: 63256 nosy: jlt63 priority: low severity: normal status: open title: Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail type: compile error versions: Python 2.5 Added file: http://bugs.python.org/file9603/python.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 19:43:40 2008 From: report at bugs.python.org (Lenard Lindstrom) Date: Tue, 04 Mar 2008 18:43:40 -0000 Subject: [issue2234] cygwinccompiler.py fails for latest MinGW releases. In-Reply-To: <1204656219.89.0.991339984516.issue2234@psf.upfronthosting.co.za> Message-ID: <1204656219.89.0.991339984516.issue2234@psf.upfronthosting.co.za> New submission from Lenard Lindstrom: The cygwinccompiler.py module for distutils on Pythons 2.5 and 2.4 fails with an exception for the latest MinGW tools. running build_ext Traceback (most recent call last): File "setup.py", line 224, in setup(**PACKAGEDATA) File "C:\PRG\PYTHON25\lib\distutils\core.py", line 151, in setup dist.run_commands() File "C:\PRG\PYTHON25\lib\distutils\dist.py", line 974, in run_commands self.run_command(cmd) File "C:\PRG\PYTHON25\lib\distutils\dist.py", line 994, in run_command cmd_obj.run() File "C:\PRG\PYTHON25\lib\distutils\command\build.py", line 112, in run self.run_command(cmd_name) File "C:\PRG\PYTHON25\lib\distutils\cmd.py", line 333, in run_command self.distribution.run_command(command) File "C:\PRG\PYTHON25\lib\distutils\dist.py", line 994, in run_command cmd_obj.run() File "setup.py", line 186, in run build_ext.run(self) File "C:\PRG\PYTHON25\lib\distutils\command\build_ext.py", line 264, in run force=self.force) File "C:\prg\pygame\trunk_\mingw32distutils.py", line 31, in new_compiler return Mingw32DefaultCCompiler (None, dry_run, force) File "C:\PRG\PYTHON25\lib\distutils\cygwinccompiler.py", line 292, in __init__ CygwinCCompiler.__init__ (self, verbose, dry_run, force) File "C:\PRG\PYTHON25\lib\distutils\cygwinccompiler.py", line 84, in __init__ get_versions() File "C:\PRG\PYTHON25\lib\distutils\cygwinccompiler.py", line 424, in get_vers ions ld_version = StrictVersion(result.group(1)) File "C:\PRG\PYTHON25\lib\distutils\version.py", line 40, in __init__ self.parse(vstring) File "C:\PRG\PYTHON25\lib\distutils\version.py", line 107, in parse raise ValueError, "invalid version number '%s'" % vstring ValueError: invalid version number '2.18.50.20080109' For instance "ld -v" now returns "GNU ld (GNU Binutils) 2.18.50.20080109", not "GNU ld version 2.17.50 20060824". The extra period between the version number and date causes class StrictVersion to raise a ValueError. A fix is to alter the regular expressions in cygwinccompiler.get_versions(). This enclosed patch to cygwinccompiler.py has been tested with the current and previous linker as well as gcc 4.2.1 and gcc 3.4.5. ---------- components: Distutils files: cygwinccompiler.patch keywords: patch messages: 63257 nosy: kermode severity: normal status: open title: cygwinccompiler.py fails for latest MinGW releases. versions: Python 2.5 Added file: http://bugs.python.org/file9604/cygwinccompiler.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 20:23:09 2008 From: report at bugs.python.org (Jason Tishler) Date: Tue, 04 Mar 2008 19:23:09 -0000 Subject: [issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail In-Reply-To: <1204652870.95.0.330326965123.issue2233@psf.upfronthosting.co.za> Message-ID: <1204658589.59.0.4004785627.issue2233@psf.upfronthosting.co.za> Changes by Jason Tishler: __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 20:49:24 2008 From: report at bugs.python.org (jason kirtland) Date: Tue, 04 Mar 2008 19:49:24 -0000 Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into account In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za> Message-ID: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za> New submission from jason kirtland: In 2.6a, seems like the __hash__ implementation and __eq__ must be defined together, in the same class. See also #1549. Ensuring that a __hash__ implementation isn't being pulled from a builtin type is probably a sufficient check...? >>> class Base(object): ... def __init__(self, name): ... self.name = name ... def __eq__(self, other): ... return self.name == other.name ... def __hash__(self): ... return hash(self.name) ... >>> class Extended(Base): ... def __eq__(self, other): ... print "trace: __eq__ called" ... return Base.__eq__(self, other) ... >>> hash(Base('b1')) 603887253 >>> hash(Extended('e1')) Traceback (most recent call last): File "", line 1, in TypeError: unhashable type: 'Extended' ---------- components: Interpreter Core messages: 63258 nosy: jek severity: normal status: open title: __eq__ / __hash__ check doesn't take inheritance into account type: crash versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 21:56:48 2008 From: report at bugs.python.org (Henrique Romano) Date: Tue, 04 Mar 2008 20:56:48 -0000 Subject: [issue2236] Distutils' mkpath implementation ignoring the "mode" parameter In-Reply-To: <1204664208.81.0.312695054648.issue2236@psf.upfronthosting.co.za> Message-ID: <1204664208.81.0.312695054648.issue2236@psf.upfronthosting.co.za> New submission from Henrique Romano: The default value for mkpath's mode parameter is 0777 but it isn't used at any place; attached is a patch that just pass the parameter to os.mkdir call, this seems to fix the problem. ---------- components: Library (Lib) files: python2.5-distutils_mkpath_filemode.v1.diff keywords: patch messages: 63259 nosy: henrique severity: normal status: open title: Distutils' mkpath implementation ignoring the "mode" parameter type: resource usage versions: Python 2.5 Added file: http://bugs.python.org/file9605/python2.5-distutils_mkpath_filemode.v1.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 22:14:59 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 04 Mar 2008 21:14:59 -0000 Subject: [issue2232] Current os.tmpfile() implementation requires admin privs on Vista/2k8. In-Reply-To: <1204650081.4.0.741104668485.issue2232@psf.upfronthosting.co.za> Message-ID: <1204665299.92.0.853916900122.issue2232@psf.upfronthosting.co.za> Christian Heimes added the comment: Side note: I've removed the methods from Python 3.0 about half a year ago. Code should use the tempfile module anyway. Does any of the Python 2.6 stdlib code use an os.tmp* method? ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 22:37:08 2008 From: report at bugs.python.org (Sylwester Warecki) Date: Tue, 04 Mar 2008 21:37:08 -0000 Subject: [issue2237] Inconsistent variable lookup In-Reply-To: <1204666628.06.0.657463410912.issue2237@psf.upfronthosting.co.za> Message-ID: <1204666628.06.0.657463410912.issue2237@psf.upfronthosting.co.za> New submission from Sylwester Warecki: Hi! An example below shows how differently local variables are treated in case of simple variables and classes. In case of objects the variable refers to global object, in case of simple number - it refers to a local. Example 2 shows worse case scenario. >From the text alone of the test2() function it is impossible to forsee its behavior (!). If there is no global variable 'a' then it crashes although without declaration of 'a' as a global it runs fine with the '+' operator on 'a'. However that will not be the case IF test3() is invoked. That is illogical. Example 3 shows the worst case scenario. functions z0 and z1 differ only by the variable name on the left side of the equation. In first case a is understood as global in second as local. What makes no sense is that the right side of equation does not change, however its interpretation is based on the left side of the equation. Example 4 This is an alteration of example 3 that shows the problem in full swing. 2 functions differ only by 2 last lines and yet they interpret the variables in completely different way. In other words, adding a line to end the code AFFECTS its beginning. That is least to say bizzaare. .................. I tried to keep examples simple - hopefully that will help. Regards, Sylwester ================================================================= class cheat: def __init__( self ): self.q = 4 a = cheat( ) b = 3 def test(): a.q = 22 b = 65 print "test a=", a.q print "test b=", b print "a=", a.q print "b=", b test() print "a=", a.q print "b=", b ================================= example 2 class cheat2: def __init__( self ): self.q = 4 def __add__( self, val ): self.q += val a=cheat2() def test2(): c = a + 4 print a.q def test3(): a += 4 test2() test3() =================================================== example 3 def z0(): c = a + 2 def z1(): a = a + 2 a = 10 z0() z1() ================================================================= example 4 def t1(): print a x=a+2 print x An example below shows how differently local variables are treated in case of simple variables and classes. In case of objects the variable refers to global object, in case of simple number - it refers to a local. Example 2 shows worse case scenario. >From the text alone of the test2() function it is impossible to forsee its behavior (!). If there is no global variable 'a' then it crashes although without declaration of 'a' as a global it runs fine with the '+' operator on 'a'. However that will not be the case IF test3() is invoked. That is illogical. Example 3 shows the worst case scenario. functions z0 and z1 differ only by the variable name on the left side of the equation. In first case a is understood as global in second as local. What makes no sense is that the right side of equation does not change, however its interpretation is based on the left side of the equation. Example 4 This is an alteration of example 3 that shows the problem in full swing. 2 functions differ only by 2 last lines and yet they interpret the variables in completely different way. In other words, adding a line to end the code AFFECTS its beginning. That is least to say bizzaare. .................. I tried to keep examples simple - hopefully that will help. Regards, Sylwester ================================================================= class cheat: def __init__( self ): self.q = 4 a = cheat( ) b = 3 def test(): a.q = 22 b = 65 print "test a=", a.q print "test b=", b print "a=", a.q print "b=", b test() print "a=", a.q print "b=", b ================================= example 2 class cheat2: def __init__( self ): self.q = 4 def __add__( self, val ): self.q += val a=cheat2() def test2(): c = a + 4 print a.q def test3(): a += 4 test2() test3() =================================================== example 3 def z0(): c = a + 2 def z1(): a = a + 2 # crash will happen here a = 10 z0() z1() ================================================================= example 4 def t1(): print a x=a+2 print x def t2(): print a #crash will happen here x=a+2 print x a=a+4 print a t1() t2() # this one will crash! ---------- components: Interpreter Core messages: 63261 nosy: swarecki severity: normal status: open title: Inconsistent variable lookup versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 22:46:27 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 04 Mar 2008 21:46:27 -0000 Subject: [issue2237] Inconsistent variable lookup In-Reply-To: <1204666628.06.0.657463410912.issue2237@psf.upfronthosting.co.za> Message-ID: <1204667187.94.0.444205657003.issue2237@psf.upfronthosting.co.za> Changes by Benjamin Peterson: ---------- type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 22:52:10 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 04 Mar 2008 21:52:10 -0000 Subject: [issue2232] Current os.tmpfile() implementation requires admin privs on Vista/2k8. In-Reply-To: <1204650081.4.0.741104668485.issue2232@psf.upfronthosting.co.za> Message-ID: <1204667530.41.0.0803203013682.issue2232@psf.upfronthosting.co.za> Benjamin Peterson added the comment: According to grep, the only place where os.tmp* is referenced is in test_os. ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 22:56:09 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 04 Mar 2008 21:56:09 -0000 Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into account In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za> Message-ID: <1204667769.92.0.325915798071.issue2235@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This issue is similar to issue1549. Note that only new-style classes are concerned. I think the change was intentional. Guido, do you confirm? However there should be some documentation about it, a NEWS entry or an item in the "porting to 2.6" section. The initial modification appeared in the py3k branch (r51454): """ Change the way __hash__ is inherited; when __eq__ or __cmp__ is overridden but __hash__ is not, set __hash__ explicitly to None (and tp_hash to NULL). """ ---------- nosy: +amaury.forgeotdarc, gvanrossum type: crash -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 23:15:28 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 04 Mar 2008 22:15:28 -0000 Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into account In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za> Message-ID: <1204668928.51.0.805097467566.issue2235@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Wouldn't you expect this sort of thing to break code? Does it meet the criteria for backporting to 2.6? ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 23:17:36 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 04 Mar 2008 22:17:36 -0000 Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into account In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za> Message-ID: <1204669056.08.0.369908005168.issue2235@psf.upfronthosting.co.za> Guido van Rossum added the comment: The py3k feature was intentional. I'm not sure who did the backport (could've been me, long ago). I think the backport should be replaced with a warning that is only issued when -3 is given. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 23:20:13 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 04 Mar 2008 22:20:13 -0000 Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into account In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za> Message-ID: <1204669213.68.0.71886267362.issue2235@psf.upfronthosting.co.za> Changes by Raymond Hettinger: ---------- priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 23:21:50 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 04 Mar 2008 22:21:50 -0000 Subject: [issue2237] Inconsistent variable lookup In-Reply-To: <1204666628.06.0.657463410912.issue2237@psf.upfronthosting.co.za> Message-ID: <1204669310.46.0.567425308522.issue2237@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > ... adding a line to end the code AFFECTS its beginning ... Exactly. Please see http://docs.python.org/dev/reference/executionmodel.html """ If a name binding operation occurs anywhere within a code block, all uses of the name within the block are treated as references to the current block. This can lead to errors when a name is used within a block before it is bound. This rule is subtle. Python lacks declarations and allows name binding operations to occur anywhere within a code block. The local variables of a code block can be determined by scanning the entire text of the block for name binding operations. """ For more general discussions, see also: http://www.python.org/doc/faq/programming/#what-are-the-rules-for-local-and-global-variables-in-python http://docs.python.org/dev/tutorial/classes.html#python-scopes-and-name-spaces In other words, this is one of the key features of the python language, and I don't see how it could change. ---------- nosy: +amaury.forgeotdarc resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 4 23:34:02 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 04 Mar 2008 22:34:02 -0000 Subject: [issue2231] Memory leak in itertools.chain() In-Reply-To: <1204636244.39.0.268718353736.issue2231@psf.upfronthosting.co.za> Message-ID: <1204670042.73.0.637089131966.issue2231@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Fixed in r61237. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 00:52:35 2008 From: report at bugs.python.org (Jean Brouwers) Date: Tue, 04 Mar 2008 23:52:35 -0000 Subject: [issue2218] Enhanced hotshot profiler with high-resolution timer In-Reply-To: <1204501511.28.0.993763550383.issue2218@psf.upfronthosting.co.za> Message-ID: <1204674755.77.0.600910272374.issue2218@psf.upfronthosting.co.za> Jean Brouwers added the comment: Attached are the improved hotspot files, rev 2. The changes are rather drastic, in particular since hires time delta's may exceed 32-bit int. These 3 files have been tested with Python 2.5.2 only and on 32-bit Linux and MacOS X and on 64-bit Linux and Solaris 10. They do pass the hotspot and other tests. However, no other platforms or compilers have been tested. Except for 64-bit PPC, the code should fall back to the previous behavior using gettimeofday. Added file: http://bugs.python.org/file9606/hires_hotshot2.tgz __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 01:00:52 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 05 Mar 2008 00:00:52 -0000 Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into account In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za> Message-ID: <1204675252.54.0.949388139911.issue2235@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The attached patch reverts r59576 and the part of r59106 about the tp_hash slot. It also adds the py3k warning:: type defines __eq__ but not __hash__, and will not be hashable in 3.x printed when calling hash() on such an object. ---------- keywords: +patch Added file: http://bugs.python.org/file9607/inherit_hash.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 01:05:34 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 05 Mar 2008 00:05:34 -0000 Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into account In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za> Message-ID: <1204675534.46.0.248429057265.issue2235@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I noticed that my patch uses Py_TYPE(self)->tp_hash, whereas normal processing of slot_tp_hash() uses lookup_method(self,"__hash__",hash_str). I am almost sure that both expressions return the same value. Is this correct? Py_TYPE(self)->tp_hash seems much faster. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 01:12:30 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 05 Mar 2008 00:12:30 -0000 Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into account In-Reply-To: <1204675534.46.0.248429057265.issue2235@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > I noticed that my patch uses Py_TYPE(self)->tp_hash, whereas normal > processing of slot_tp_hash() uses lookup_method(self,"__hash__",hash_str). > > I am almost sure that both expressions return the same value. > Is this correct? Py_TYPE(self)->tp_hash seems much faster. HERE BE DRAGONS There are cases where Py_TYPE(self)->tp_hash is the function currently executing (some wrapper(s) in typeobject.c). OTOH, lookup_method(...) finds the Python code in the class __dict__s along the MRO. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 01:48:32 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 05 Mar 2008 00:48:32 -0000 Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into account In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za> Message-ID: <1204678112.38.0.949774053316.issue2235@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Ah, I remember that it took me some time to understand the boundaries between a slot and the corresponding special method. Here is another version of the patch, which does not test tp_hash while we are currently running the tp_hash function... I also added the warning for old-style classes. Added file: http://bugs.python.org/file9608/inherit_hash2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 01:53:16 2008 From: report at bugs.python.org (Nathan Collins) Date: Wed, 05 Mar 2008 00:53:16 -0000 Subject: [issue2238] TypeError instead of SyntaxError for syntactically invalid gen exp In-Reply-To: <1204678396.78.0.214556638013.issue2238@psf.upfronthosting.co.za> Message-ID: <1204678396.78.0.214556638013.issue2238@psf.upfronthosting.co.za> New submission from Nathan Collins: I have a file f1.py $ cat f1.py import os (lambda **x:x)(**dict(y,y for y in ())) and when I run it $ python f1.py Traceback (most recent call last): File "f1.py", line 1, in import os TypeError: 'int' object is not iterable Notice that the TypeError exception is from the import os on line 1. But the import isn't the problem. The problem is the illegal generator expression on line 2. I.e. if $ cat f2.py #import os dict(y,y for y in ()) then $ python f2.py File "f2.py", line 2 dict(y,y for y in ()) SyntaxError: Generator expression must be parenthesized if not sole argument The mess (lambda **x:x)(**dict(y,y for y in ())) is a simplified version of something I had about 100 lines into a file, but the resulting TypeError still complains about an import on line 1, which is really confusing. I'm using Python 2.5.2 (r252:60911, Mar 4 2008, 14:33:51) [GCC 3.4.4] on linux2 for python. ################################################################################ The above is probably a good enough description, but here's some more weirdness in case it's helpful: Some variations of f1.py cause the same error, but others don't. E.g. if f4.py is for c in [1]: pass (lambda **x:x)(**dict(y,y for y in ())) I get Traceback (most recent call last): File "f4.py", line 1, in for c in [1]: pass TypeError: 'int' object is not iterable as before. But if f5.py is for c in "1": pass (lambda **x:x)(**dict(y,y for y in ())) running the script results in no output and a successful run $ echo $? 0 Finally, if f6.py is just the single line (lambda **x:x)(**dict(y,y for y in ())) then my 2.5.2 python has the same successful with no output result as for f5.py, but if I run f6.py in an older Python 2.5 (r25:51908, Oct 30 2006, 16:20:39) [GCC 3.4.4] on linux2 python I get Exception exceptions.SyntaxError: ('Generator expression must be parenthesized if not sole argument', 1) in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection zsh: abort (core dumped) python f6.py The older 2.5 python runs f5.py successfully with no output like 2.5.2 does. I searched the bug tracker for "TypeError: 'int' object is not iterable" and didn't find anything, so I'm assuming this bug is unknown. I'm sure someone will let me know if I'm mistaken =) I'd guess the problem has to do with a bad parse. ---------- components: None messages: 63273 nosy: NathanCollins severity: normal status: open title: TypeError instead of SyntaxError for syntactically invalid gen exp versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 02:51:12 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 05 Mar 2008 01:51:12 -0000 Subject: [issue2238] TypeError instead of SyntaxError for syntactically invalid gen exp In-Reply-To: <1204678396.78.0.214556638013.issue2238@psf.upfronthosting.co.za> Message-ID: <1204681872.26.0.737376642275.issue2238@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Interestingly, in debug mode, the message "XXX undetected error" is printed to stderr. And this gives the solution: in ast.c, some calls did not check the return status. Committed revision 61240, will backport to 2.5. Thanks for the report! Thanks for the report! ---------- nosy: +amaury.forgeotdarc resolution: -> fixed status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 07:15:34 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 05 Mar 2008 06:15:34 -0000 Subject: [issue2223] regrtest.py -R not working In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> Message-ID: <1204697734.53.0.663490459151.issue2223@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: I did more investigation. Failure on second DocTestSuite run happens because lib/doctest.py (2107) test.globs.clear() is executed after first test runs. I don't know if this is bug or not. Document in doctest.py says test.globs will be untouched on failure but become empty on success, but this behavior prevents reusage of DocTestSuite. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 15:31:31 2008 From: report at bugs.python.org (Tim Golden) Date: Wed, 05 Mar 2008 14:31:31 -0000 Subject: [issue2239] Tiny patch to cmdline docs In-Reply-To: <1204727491.16.0.495455810446.issue2239@psf.upfronthosting.co.za> Message-ID: <1204727491.16.0.495455810446.issue2239@psf.upfronthosting.co.za> New submission from Tim Golden: The docs for the PYTHONPATH var indicate that its items are separated by colons. In fact they're separated by whatever's customary for the O/S. Patch attached. ---------- components: Documentation files: doc-using-cmdline-r61249.patch keywords: patch messages: 63276 nosy: georg.brandl, tim.golden severity: normal status: open title: Tiny patch to cmdline docs versions: Python 2.6 Added file: http://bugs.python.org/file9609/doc-using-cmdline-r61249.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 15:42:13 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 05 Mar 2008 14:42:13 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> New submission from Guilherme Polo: Right now Python misses a wrapper for setitimer and getitimer and I believe it would be interesting to include them. I'm (almost) sure some other people may find it useful too. I'm attaching a standalone module, but if it gets to be included in Python, I think it would be better to create a patch against signal module. Also, its tests are pretty poor. Improvements are welcomed. ---------- files: py-itimer-0.1.1.tar.gz messages: 63277 nosy: gpolo severity: normal status: open title: setitimer, getitimer wrapper type: feature request versions: Python 3.0 Added file: http://bugs.python.org/file9610/py-itimer-0.1.1.tar.gz __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 15:46:17 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 05 Mar 2008 14:46:17 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204728377.71.0.705089718173.issue2240@psf.upfronthosting.co.za> Guilherme Polo added the comment: I forgot to remove an unwanted comment from it =) Attaching new version. Added file: http://bugs.python.org/file9611/py-itimer-0.1.2.tar.gz __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 15:49:02 2008 From: report at bugs.python.org (Trent Nelson) Date: Wed, 05 Mar 2008 14:49:02 -0000 Subject: [issue2232] Current os.tmpfile() implementation requires admin privs on Vista/2k8. In-Reply-To: <1204650081.4.0.741104668485.issue2232@psf.upfronthosting.co.za> Message-ID: <1204728542.16.0.991751228498.issue2232@psf.upfronthosting.co.za> Trent Nelson added the comment: With Chris and Ben's comments taken into account, what's the best way to handle this? 1. Change the test: if the user is not admin, assert os.tmpfile() returns a permission denied OSError, otherwise, assert return value is a current file. 2. Alter posix_tmpfile() to warn the user of the situation if the call fails and we're on Windows: Index: posixmodule.c =================================================================== --- posixmodule.c (revision 61233) +++ posixmodule.c (working copy) @@ -7029,8 +7029,15 @@ FILE *fp; fp = tmpfile(); - if (fp == NULL) + if (fp == NULL) { +#ifdef MS_WINDOWS + PyErr_Warn(PyExc_RuntimeWarning, + "tmpfile creates a file in the root directory and " \ + "requires administrative privileges, consider using " \ + "tempfile.mkstemp() instead"); +#endif return posix_error(); + } return PyFile_FromFile(fp, "", "w+b", fclose); } #endif 3. Alter posix_tmpfile() to use _tempnam() on Windows instead, such admin privileges are no longer required. (Possibly adding a similar warning that tempfile.mkstemp should be used instead though, as above?) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 15:58:27 2008 From: report at bugs.python.org (Thomas Heller) Date: Wed, 05 Mar 2008 14:58:27 -0000 Subject: [issue1292] libffi needs an update to support mips64, arm and armeabi on linux In-Reply-To: <1192699386.49.0.555660775493.issue1292@psf.upfronthosting.co.za> Message-ID: <1204729107.74.0.0323361235343.issue1292@psf.upfronthosting.co.za> Thomas Heller added the comment: libffi3-branch has been merged to trunk; the Modules/_ctypes/libffi files are from the libffi 3.0.4 release now. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 16:00:03 2008 From: report at bugs.python.org (Facundo Batista) Date: Wed, 05 Mar 2008 15:00:03 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204729203.71.0.772366018832.issue2240@psf.upfronthosting.co.za> Changes by Facundo Batista: Removed file: http://bugs.python.org/file9610/py-itimer-0.1.1.tar.gz __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 16:07:51 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 05 Mar 2008 15:07:51 -0000 Subject: [issue2239] Tiny patch to cmdline docs In-Reply-To: <1204727491.16.0.495455810446.issue2239@psf.upfronthosting.co.za> Message-ID: <1204729671.01.0.288744453754.issue2239@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: PYTHONPATH variable is likely to be defined by sysadmins who may not know what os.pathsep is. Maybe it is better to say "OS-dependent separator (';' on Windows, ':' on Linux and other UNIX-like OSes or ',' on some less-known systems.)" ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 16:12:07 2008 From: report at bugs.python.org (Tim Golden) Date: Wed, 05 Mar 2008 15:12:07 -0000 Subject: [issue2239] Tiny patch to cmdline docs In-Reply-To: <1204729671.01.0.288744453754.issue2239@psf.upfronthosting.co.za> Message-ID: <47CEB869.8070300@timgolden.me.uk> Tim Golden added the comment: Alexander Belopolsky wrote: > Alexander Belopolsky added the comment: > > PYTHONPATH variable is likely to be defined by sysadmins who may not know > what os.pathsep is. Maybe it is better to say "OS-dependent separator > (';' on Windows, ':' on Linux and other UNIX-like OSes or ',' on some > less-known systems.)" Maybe, but I have made the doc reference a link to the os.pathsep doc which basically says what you just did. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 17:17:54 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 05 Mar 2008 16:17:54 -0000 Subject: [issue433030] SRE: (?>...) is not supported Message-ID: <1204733874.6.0.221766420106.issue433030@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Also referred to as an atomic group: see http://www.regular-expressions.info/atomic.html for a discussion. Fredrik, when you say "the engine has code for this", what do you mean? ---------- nosy: +akuchling ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Mar 5 17:24:33 2008 From: report at bugs.python.org (Brian White) Date: Wed, 05 Mar 2008 16:24:33 -0000 Subject: [issue2241] Additional Flag For Unit-Test Module: There Can Be Only One (Error) In-Reply-To: <1204734272.92.0.489101809074.issue2241@psf.upfronthosting.co.za> Message-ID: <1204734272.92.0.489101809074.issue2241@psf.upfronthosting.co.za> New submission from Brian White: The attached diff adds a "-o" ("--one") option to the "unittest" module that causes the run to abort on the first error encountered. I name my tests so that the lowest-level tests get run first so stopping at the first error tends to prevent a lot of dependent errors and speed debugging. During development, I typically run the tests I'm writing with "-ov". During a full test run, I omit both those flags. ---------- components: Library (Lib) files: unittest-diff25.py messages: 63285 nosy: bcwhite severity: normal status: open title: Additional Flag For Unit-Test Module: There Can Be Only One (Error) type: feature request versions: Python 2.5 Added file: http://bugs.python.org/file9612/unittest-diff25.py __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 17:27:20 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 05 Mar 2008 16:27:20 -0000 Subject: [issue2239] Tiny patch to cmdline docs In-Reply-To: <1204727491.16.0.495455810446.issue2239@psf.upfronthosting.co.za> Message-ID: <1204734440.28.0.120540504013.issue2239@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > .. but I have made the doc reference a link to the os.pathsep I knew you would say that :-). I was making my comment out of real life experience: sysadmins rarely know python language, but can do good job administering python installations. For better or worse, the target audience for PYTHONPATH documentation is likely not to be interested in being educated in the python programming language. Having to lookup the meaning of os.pathsep just to understand the format of PYTHONPATH is a distraction. Another problem with the link is that cmdline page is likely to be printed out for a quick reference and the link will obviously not work in the printout. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 17:32:19 2008 From: report at bugs.python.org (Tim Golden) Date: Wed, 05 Mar 2008 16:32:19 -0000 Subject: [issue2239] Tiny patch to cmdline docs In-Reply-To: <1204734440.28.0.120540504013.issue2239@psf.upfronthosting.co.za> Message-ID: <47CECB38.70908@timgolden.me.uk> Tim Golden added the comment: Alexander Belopolsky wrote: > Alexander Belopolsky added the comment: > >> .. but I have made the doc reference a link to the os.pathsep > > I knew you would say that :-). I was making my comment out of real life > experience: sysadmins rarely know python language, but can do good job > administering python installations. For better or worse, the target > audience for PYTHONPATH documentation is likely not to be interested in > being educated in the python programming language. Having to lookup the > meaning of os.pathsep just to understand the format of PYTHONPATH is a distraction. Another problem with the link is that cmdline page is > likely to be printed out for a quick reference and the link will > obviously not work in the printout. I don't feel strongly about it. Feel free to propose an alternative wording for the patch :) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 17:33:41 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 05 Mar 2008 16:33:41 -0000 Subject: [issue433030] SRE: (?>...) is not supported Message-ID: <1204734821.16.0.450059890024.issue433030@psf.upfronthosting.co.za> A.M. Kuchling added the comment: There's also an alternate syntax for this, called possessive quantifiers: a*+, a++, a{m,n}+. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Mar 5 17:35:37 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 05 Mar 2008 16:35:37 -0000 Subject: [issue2220] bug in rlcompleter In-Reply-To: <1204541379.7.0.080847401337.issue2220@psf.upfronthosting.co.za> Message-ID: <1204734937.46.0.608024169232.issue2220@psf.upfronthosting.co.za> Changes by A.M. Kuchling: ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 17:52:20 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 05 Mar 2008 16:52:20 -0000 Subject: [issue2239] Tiny patch to cmdline docs In-Reply-To: <1204727491.16.0.495455810446.issue2239@psf.upfronthosting.co.za> Message-ID: <1204735940.78.0.535184268267.issue2239@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > Feel free to propose an alternative wording for the patch I thought I already did in my first post. The complete sentence should read: """ The format is the same as the shell's :envvar:`PATH`: one or more directory pathnames separated by an OS-dependent character (';' on Windows, ':' on Linux and other UNIX-like OSes or ',' on some less-known systems.) """ __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 18:01:22 2008 From: report at bugs.python.org (Tim Golden) Date: Wed, 05 Mar 2008 17:01:22 -0000 Subject: [issue2239] Tiny patch to cmdline docs In-Reply-To: <1204735940.78.0.535184268267.issue2239@psf.upfronthosting.co.za> Message-ID: <47CED203.1050106@timgolden.me.uk> Tim Golden added the comment: Alexander Belopolsky wrote: > Alexander Belopolsky added the comment: > >> Feel free to propose an alternative wording for the patch > > I thought I already did in my first post. The complete sentence should > read: > > """ > The format is the same as the shell's :envvar:`PATH`: one or more > directory pathnames separated by an OS-dependent character (';' on > Windows, ':' on Linux and other UNIX-like OSes or ',' on some > less-known systems.) > """ Ah. Lazily, I meant: feel free to upload a patch containing the wording you think good. TJG __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 19:39:38 2008 From: report at bugs.python.org (Malte Helmert) Date: Wed, 05 Mar 2008 18:39:38 -0000 Subject: [issue1040026] os.times() is bogus Message-ID: <1204742378.22.0.984846902904.issue1040026@psf.upfronthosting.co.za> Malte Helmert added the comment: I think it's better only to only add another fallback if the unit tests show that such platforms exist. Avoiding cruft is important, too. After all, sysconf is a standard POSIX API, and from my (admittedly limited) research was already available in that form back in 1988. So my suggestion is to apply the current patches. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Mar 5 20:32:07 2008 From: report at bugs.python.org (Georg Brandl) Date: Wed, 05 Mar 2008 19:32:07 -0000 Subject: [issue2239] Tiny patch to cmdline docs In-Reply-To: <1204727491.16.0.495455810446.issue2239@psf.upfronthosting.co.za> Message-ID: <1204745527.46.0.911581741611.issue2239@psf.upfronthosting.co.za> Georg Brandl added the comment: I took the best of both worlds and committed in r61255. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 21:36:14 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 05 Mar 2008 20:36:14 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204749374.24.0.829745084328.issue2240@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I can see nothing wrong with including setitimer support for systems where it is available, and I agree that the signal module would be the right place. So whoever wants to complete it, feel free to produce a complete patch against the trunk. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 22:35:37 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 05 Mar 2008 21:35:37 -0000 Subject: [issue2232] Current os.tmpfile() implementation requires admin privs on Vista/2k8. In-Reply-To: <1204650081.4.0.741104668485.issue2232@psf.upfronthosting.co.za> Message-ID: <1204752937.78.0.51108847062.issue2232@psf.upfronthosting.co.za> Benjamin Peterson added the comment: > With Chris and Ben's comments taken into account, what's the best way to > handle this? I think, given that is being removed, we can safely go with option 1. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 22:37:36 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 05 Mar 2008 21:37:36 -0000 Subject: [issue2241] Additional Flag For Unit-Test Module: There Can Be Only One (Error) In-Reply-To: <1204734272.92.0.489101809074.issue2241@psf.upfronthosting.co.za> Message-ID: <1204753056.86.0.190809017774.issue2241@psf.upfronthosting.co.za> Changes by Benjamin Peterson: ---------- nosy: +purcell __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 22:43:25 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 05 Mar 2008 21:43:25 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204753405.92.0.821356735061.issue2240@psf.upfronthosting.co.za> Guilherme Polo added the comment: Martin, thanks for supporting the idea. I'm attaching a patch. It is against rev 61255, py3k branch. It patches configure, configure.in, Modules/signalmodule.c and pyconfig.h.in I wasn't sure if I should attach a diff for each file, so they are all packed in the same diff. Also, I wasn't sure if I should append the "configure" diff, but I did. Documentation in "Doc/" and tests aren't done yet, if someone want to pick this task, please say it. ---------- keywords: +patch Added file: http://bugs.python.org/file9613/setitimer_getitimer_wrapper.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 22:54:20 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Wed, 05 Mar 2008 21:54:20 -0000 Subject: [issue1858] Make .pypirc handle multiple servers In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za> Message-ID: <1204754059.87.0.157299687571.issue1858@psf.upfronthosting.co.za> Tarek Ziad? added the comment: I have changed the code: the pypirc module is now called config. Added file: http://bugs.python.org/file9614/distutils.2008-03-05.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 22:55:22 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 05 Mar 2008 21:55:22 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204754122.2.0.462465850061.issue2240@psf.upfronthosting.co.za> Guilherme Polo added the comment: I noticed that I forgot to change setitimer and getitimer functions from itimer_setitimer to signal_setitimer (same for getitimer). I'm attaching a patch that should be applied after the previous one to do this renaming. Added file: http://bugs.python.org/file9615/setitimer_getitimer_wrapper_rename.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 23:18:13 2008 From: report at bugs.python.org (=?utf-8?q?Jean-Fran=C3=A7ois_Bastien?=) Date: Wed, 05 Mar 2008 22:18:13 -0000 Subject: [issue1524] os.system() fails for commands with multiple quoted file names In-Reply-To: <1196367416.9.0.40290581495.issue1524@psf.upfronthosting.co.za> Message-ID: <1204755493.1.0.565403615536.issue1524@psf.upfronthosting.co.za> Jean-Fran?ois Bastien added the comment: I confirm the problem. To resolve it try: os.system('call "TheCommand" > "MyOutput"') ---------- nosy: +jfbastien __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 23:45:32 2008 From: report at bugs.python.org (Trent Nelson) Date: Wed, 05 Mar 2008 22:45:32 -0000 Subject: [issue2232] Current os.tmpfile() implementation requires admin privs on Vista/2k8. In-Reply-To: <1204650081.4.0.741104668485.issue2232@psf.upfronthosting.co.za> Message-ID: <1204757132.74.0.370770632009.issue2232@psf.upfronthosting.co.za> Trent Nelson added the comment: I agree. Following patch fixes the issue for me: Index: test_os.py =================================================================== --- test_os.py (revision 61260) +++ test_os.py (working copy) @@ -65,6 +65,44 @@ def test_tmpfile(self): if not hasattr(os, "tmpfile"): return + # As with test_tmpnam() below, the Windows implementation of tmpfile() + # attempts to create a file in the root directory of the current drive. + # On Vista and Server 2008, this test will always fail for normal users + # as writing to the root directory requires elevated privileges. With + # XP and below, the semantics of tmpfile() are the same, but the user + # running the test is more likely to have administrative privileges on + # their account already. If that's the case, then os.tmpfile () should + # work. In order to make this test as useful as possible, rather than + # trying to detect Windows versions or whether or not the user has the + # right permissions, just try and create a file in the root directory + # and see if it raises a 'Permission denied' OSError. If it does, then + # test that a subsequent call to os.tmpfile() raises the same error. If + # it doesn't, assume we're on XP or below and the user running the test + # has administrative privileges, and proceed with the test as normal. + if sys.platform == 'win32': + name = '\\python_test_os_test_tmpfile.txt' + if os.path.exists(name): + os.remove(name) + try: + fp = open(name, 'w') + except IOError, first: + # open() failed, assert tmpfile() fails in the same way. + # Although open() raises an IOError and os.tmpfile() raises an + # OSError(), 'args' will be (12, 'Permission denied') in both + # cases. + try: + fp = os.tmpfile() + except OSError, second: + self.assertEqual(first.args, second.args) + else: + self.fail("expected os.tmpfile() to raise OSError") + return + else: + # open() worked, therefore, tmpfile() should work. Close our + # dummy file and proceed with the test as normal. + fp.close() + os.remove(name) + fp = os.tmpfile() fp.write("foobar") fp.seek(0,0) ---------- keywords: +patch Added file: http://bugs.python.org/file9616/test_os.py.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 5 23:53:15 2008 From: report at bugs.python.org (Trent Nelson) Date: Wed, 05 Mar 2008 22:53:15 -0000 Subject: [issue2232] Current os.tmpfile() implementation requires admin privs on Vista/2k8. In-Reply-To: <1204650081.4.0.741104668485.issue2232@psf.upfronthosting.co.za> Message-ID: <1204757595.33.0.843528361115.issue2232@psf.upfronthosting.co.za> Trent Nelson added the comment: Er, errno being referred to in a comment in that last patch should be 13, not 12. Added file: http://bugs.python.org/file9617/test_os.py.2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 00:47:37 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Wed, 05 Mar 2008 23:47:37 -0000 Subject: [issue2232] Current os.tmpfile() implementation requires admin privs on Vista/2k8. In-Reply-To: <1204650081.4.0.741104668485.issue2232@psf.upfronthosting.co.za> Message-ID: <1204760857.12.0.0246596509215.issue2232@psf.upfronthosting.co.za> Joseph Armbruster added the comment: Tested patch against: http://svn.python.org/projects/python/trunk @ 61260 OS Name: Microsoft Windows XP Professional OS Version: 5.1.2600 Service Pack 2 Build 260 rt test_os Deleting .pyc/.pyo files ... (57, '.pyc deleted,', 0, '.pyo deleted') python -E -tt ../lib/test/regrtest.py test_os test_os 1 test OK. ---------- nosy: +JosephArmbruster __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 02:56:42 2008 From: report at bugs.python.org (ozzeng) Date: Thu, 06 Mar 2008 01:56:42 -0000 Subject: [issue2225] py_compile.main() does not return error code In-Reply-To: <1204571709.66.0.797996976518.issue2225@psf.upfronthosting.co.za> Message-ID: <1204768602.79.0.703976525517.issue2225@psf.upfronthosting.co.za> ozzeng added the comment: This patch was generated against the trunk but py_compile.py is unchanged from the version in the release 2.5-maint branch. ---------- keywords: +patch nosy: +ozzeng versions: +Python 2.6 Added file: http://bugs.python.org/file9618/py_compile.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 03:31:03 2008 From: report at bugs.python.org (Chris Palmer) Date: Thu, 06 Mar 2008 02:31:03 -0000 Subject: [issue2242] Decoding UTF-7 with "ignore warnings" crashes Python on Windows Vista In-Reply-To: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za> Message-ID: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za> New submission from Chris Palmer: When decoding some data as UTF-7 with the optional "ignore" argument, Python (I am using 2.5.2) crashes. This happens only on Windows Vista (I also tried Py 2.5.1 on Windows XP, Ubuntu 7, and FreeBSD 6). To reproduce, set WinDbg as your post-mortem debugger and run this code: import os while True: a = os.urandom(16).decode("utf7", "ignore") In WinDbg, you will see that Python died in isalnum with a bad pointer dereference: (f64.13b0): Access violation - code c0000005 (!!! second chance !!!) eax=7c39a550 ebx=018e6837 ecx=0000ffe3 edx=00000003 esi=018edd66 edi=0000ffe3 eip=7c373977 esp=0021fc40 ebp=0000ffe3 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\system32\MSVCR71.dll - MSVCR71!isalnum+0x35: 7c373977 0fb70448 movzx eax,word ptr [eax+ecx*2] ds:0023:7c3ba516=???? 0:000> kb ChildEBP RetAddr Args to Child WARNING: Stack unwind information not available. Following frames may be wrong. 0021fc3c 1e0dd81e 0000ffe3 00ff1030 0000012e MSVCR71!isalnum+0x35 00000000 00000000 00000000 00000000 00000000 python25!PyUnicode_DecodeUTF7+0x10e It seems that a sanity check present in other Windows versions is missing in Vista. The simplest possible test program: #include "stdafx.h" #include int _tmain(int argc, _TCHAR* argv[]) { isalnum(0xff8b); return 0; } causes Visual Studio 2005 to raise a debug assertion failure warning. I guess that the assert is missing in the release build, and Python can be tricked into providing the unsafe input to isalnum. ---------- components: Interpreter Core messages: 63303 nosy: cpalmer severity: normal status: open title: Decoding UTF-7 with "ignore warnings" crashes Python on Windows Vista type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 07:47:46 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Mar 2008 06:47:46 -0000 Subject: [issue1725737] Distutils default exclude doesn't match top level .svn Message-ID: <1204786066.49.0.888433529817.issue1725737@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed as r61263. I'll let Martin decide about a backport. ---------- assignee: -> loewis nosy: +loewis resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 6 07:57:47 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Mar 2008 06:57:47 -0000 Subject: [issue2232] Current os.tmpfile() implementation requires admin privs on Vista/2k8. In-Reply-To: <1204650081.4.0.741104668485.issue2232@psf.upfronthosting.co.za> Message-ID: <1204786667.08.0.79381145245.issue2232@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch. Committed as r61264 and r61266. ---------- nosy: +loewis resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 07:59:42 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Mar 2008 06:59:42 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204786782.1.0.452477089387.issue2240@psf.upfronthosting.co.za> Georg Brandl added the comment: Patch review: * ItimerError should be signal.ItimerError, not signal.error. * It should probably inherit from EnvironmentError or IOError. * itimer_retval will leak the new tuple if one of the PyFloat_FromDouble fails. * Do you have test and doc patches, too? * What does the "which" argument mean, is it an arbitrary integer identifying the timer? ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 08:15:52 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Mar 2008 07:15:52 -0000 Subject: [issue1725737] Distutils default exclude doesn't match top level .svn Message-ID: <1204787752.88.0.0264309493924.issue1725737@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Backported as r61268. Georg, can you please add a NEWS entry for the trunk as well? ---------- assignee: loewis -> georg.brandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 6 08:34:14 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 06 Mar 2008 07:34:14 -0000 Subject: [issue2242] Decoding UTF-7 with "ignore warnings" crashes Python on Windows Vista In-Reply-To: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za> Message-ID: <1204788854.92.0.986155419958.issue2242@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: I reproduced this bug with VC6 + Win2000SP4 + following code. '+\xc1'.decode("utf7", "ignore") and this simple patch prevented crash. Index: Objects/unicodeobject.c =================================================================== --- Objects/unicodeobject.c (revision 61262) +++ Objects/unicodeobject.c (working copy) @@ -1506,7 +1506,7 @@ e = s + size; while (s < e) { - Py_UNICODE ch; + char ch; restart: ch = *s; Probably this is due to integer conversion, but I didn't look at logic so much. ---------- nosy: +ocean-city __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 08:36:11 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 06 Mar 2008 07:36:11 -0000 Subject: [issue2242] Decoding UTF-7 with "ignore warnings" crashes Python on Windows Vista In-Reply-To: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za> Message-ID: <1204788971.37.0.194801537965.issue2242@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: One more thing. "ignore" is not needed. '+\xc1'.decode("utf7") crashed my interpreter. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 08:37:29 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Mar 2008 07:37:29 -0000 Subject: [issue2242] Decoding UTF-7 with "ignore warnings" crashes Python on Windows Vista In-Reply-To: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za> Message-ID: <1204789049.82.0.651954011693.issue2242@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- priority: -> urgent severity: normal -> urgent versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 08:41:40 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Mar 2008 07:41:40 -0000 Subject: [issue2225] py_compile.main() does not return error code In-Reply-To: <1204571709.66.0.797996976518.issue2225@psf.upfronthosting.co.za> Message-ID: <1204789300.01.0.875279215244.issue2225@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed patch and new docs in r61273. Thanks! ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 08:43:22 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Mar 2008 07:43:22 -0000 Subject: [issue1725737] Distutils default exclude doesn't match top level .svn Message-ID: <1204789402.8.0.908466938259.issue1725737@psf.upfronthosting.co.za> Georg Brandl added the comment: Done! _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 6 08:46:44 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 06 Mar 2008 07:46:44 -0000 Subject: [issue2220] bug in rlcompleter In-Reply-To: <1204541379.7.0.080847401337.issue2220@psf.upfronthosting.co.za> Message-ID: <1204789604.36.0.877413708457.issue2220@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r61275, r61276 (2.5). ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 09:27:28 2008 From: report at bugs.python.org (Steve Purcell) Date: Thu, 06 Mar 2008 08:27:28 -0000 Subject: [issue2241] Additional Flag For Unit-Test Module: There Can Be Only One (Error) In-Reply-To: <1204734272.92.0.489101809074.issue2241@psf.upfronthosting.co.za> Message-ID: <1204792048.58.0.243202663791.issue2241@psf.upfronthosting.co.za> Steve Purcell added the comment: Hi Brian; The module is intended for test suites where the unit tests are written to be independent of each other, which is the "standard" way to do things. Note, for instance, that there is no convenient support for changing the order in which tests run. When tests are written like that, you can interrupt a bulk test run at any point, and you can run a single test to reproduce and then debug a failure. Given your test suite, I can see how this '--one' option is helpful to you, but I don't believe it should be made standard. (I've never seen it in any XP-inspired test framework or related IDE UI.) However, you can easily write a custom TestRunner that provides this "fast abort" behaviour that you want, and then hook it into unittest as follows: unittest.main(testRunner=MyCustomTestRunner()) (BTW, regarding the implementation, it's not ideal to pass the 'onlyOne' parameter down and through to the run() method; much better would be to initialise a TestResult subclass with the 'onlyOne' option, so that it could then abort when 'addError' or 'addFailure' is called. You can use that trick in any custom test runner you might write.) Best wishes, -Steve ---------- assignee: -> purcell resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 10:18:27 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Thu, 06 Mar 2008 09:18:27 -0000 Subject: [issue1725737] Distutils default exclude doesn't match top level .svn Message-ID: <1204795107.38.0.637969962752.issue1725737@psf.upfronthosting.co.za> Ralf Schmitt added the comment: _svn might also be a candidate. it is used on windows when SVN_ASP_DOT_NET_HACK is set. (see http://svn.collab.net/repos/svn/trunk/notes/asp-dot-net-hack.txt). But, I don't care enough to provide a patch. What do you thinkm about excluding *~ and .*# ? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 6 11:12:26 2008 From: report at bugs.python.org (Guilherme Polo) Date: Thu, 06 Mar 2008 10:12:26 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204798346.04.0.864621167854.issue2240@psf.upfronthosting.co.za> Guilherme Polo added the comment: Thanks for the review, corrections and suggestions Georg. For the first three items: I will be working on this later today. For the last item: "which" is one of those three new constants added. I believe if you pass something else setitimer/getitimer might raise an error (not tested). I still have to write doc and tests. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 11:17:05 2008 From: report at bugs.python.org (begemoth) Date: Thu, 06 Mar 2008 10:17:05 -0000 Subject: [issue2243] urllib2. strange behavior for getting chuncked transfer-ecnoded data In-Reply-To: <1204798625.87.0.148151937521.issue2243@psf.upfronthosting.co.za> Message-ID: <1204798625.87.0.148151937521.issue2243@psf.upfronthosting.co.za> New submission from begemoth: Through urllib2 open web pages from some sites (www.rbc.ru, www.rambler.ru, www.yandex.ru). Their servers send data in chuncked transfer-encoding. httplib (which is used by urllib2) "unchunk" data but I recieve "transfer-encoding: chuncked" in response header nevertheless. It seems to me that this key in header need to be removed from the header if httplib "unchuncked" the data. ---------- components: Library (Lib) messages: 63316 nosy: begemoth severity: normal status: open title: urllib2. strange behavior for getting chuncked transfer-ecnoded data type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 11:45:34 2008 From: report at bugs.python.org (Martin Wilck) Date: Thu, 06 Mar 2008 10:45:34 -0000 Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails Message-ID: <1204800334.22.0.0454000071673.issue1424152@psf.upfronthosting.co.za> Martin Wilck added the comment: The recipe in its current form doesn't work with urllib2 in python 2.5 The reason it fails is that the HTTPConnection.request() method isn't passed the request itself (with the proxy host and port info). No easy solution to be seen. ---------- nosy: +mwilck _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 6 11:52:44 2008 From: report at bugs.python.org (Martin Wilck) Date: Thu, 06 Mar 2008 10:52:44 -0000 Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails Message-ID: <1204800764.45.0.904697961907.issue1424152@psf.upfronthosting.co.za> Martin Wilck added the comment: I think this is a major issue because urllib2 is widely used, and any application using it is useless behind a HTTPS proxy. A Prominent example in the Linux world is yum, the Fedora Linux package management tool. HTTPS proxies are a extermely common in the corporate world. The cookbook recipe shows that it is possible to implement a CONNECT proxy (with quite a few lines of code, actually), but because it's not part of urllib2 it has been broken by python 2.5. ---------- severity: normal -> major _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 6 12:48:16 2008 From: report at bugs.python.org (Guilherme Polo) Date: Thu, 06 Mar 2008 11:48:16 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204804096.63.0.624982039289.issue2240@psf.upfronthosting.co.za> Guilherme Polo added the comment: I'm attaching another patch, this should be applied after the other ones have been applied. It fixes what Georg mentioned. I have chosen to let ItimerError inherit from IOError, and improved the docstring of setitimer. Added file: http://bugs.python.org/file9619/setitimer_getitimer_wrapper_fixes.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 14:26:39 2008 From: report at bugs.python.org (Guilherme Polo) Date: Thu, 06 Mar 2008 13:26:39 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204809999.45.0.73593778903.issue2240@psf.upfronthosting.co.za> Guilherme Polo added the comment: Updated Doc/library/signal.rst, follows a patch. Added file: http://bugs.python.org/file9620/setitimer_getitimer_wrapper_doc.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 15:03:01 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 06 Mar 2008 14:03:01 -0000 Subject: [issue2241] Additional Flag For Unit-Test Module: There Can Be Only One (Error) In-Reply-To: <1204734272.92.0.489101809074.issue2241@psf.upfronthosting.co.za> Message-ID: <1204812181.29.0.265589518504.issue2241@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Actually, py.test and nose both have the -x option for this purpose. I use it very often during development, mostly during a refactoring phase: failures are easy to correct, and I don't want to wait for the complete suite to complete and display tons of tracebacks. Even while developing on core python, this option would have helped me a couple of times. Please, reopen this item! ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 15:15:29 2008 From: report at bugs.python.org (Steve Purcell) Date: Thu, 06 Mar 2008 14:15:29 -0000 Subject: [issue2241] Additional Flag For Unit-Test Module: There Can Be Only One (Error) In-Reply-To: <1204734272.92.0.489101809074.issue2241@psf.upfronthosting.co.za> Message-ID: <1204812929.81.0.86993471295.issue2241@psf.upfronthosting.co.za> Steve Purcell added the comment: I guess I don't completely agree with the rationale, because I've never wanted this feature; when running tests en-masse after refactoring, I want an overview of what was broken. If the codebase is in good shape, the test failures will be few and close together, and then I can usually re-run one of the individual test cases to debug the error. However, this isn't a big issue for me, and if someone's willing to prepare a new patch with the different implementation I described previously, I'm happy to re-open this ticket and sign off on it. I'd suggest using the same argument names as nose and py.test in this case. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 16:54:01 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 06 Mar 2008 15:54:01 -0000 Subject: [issue2179] with should be as fast as try/finally In-Reply-To: <1203894641.18.0.492382147443.issue2179@psf.upfronthosting.co.za> Message-ID: <1204818841.82.0.38885303536.issue2179@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > What's strange is that calling __enter__ and __exit__ in a > try/finally block brings the speed back to the faster 'with' speed, > even though they call the same C functions Looking carefully at the code, there are two reasons for this: - LockType has no methods! try "dir(thread.LockType)". Instead, LockType defines a tp_getattr which does a *linear* search in a PyMethodDef array. First items are served faster... - After converting this to use the usual tp_methods slot, there is still a performance difference, due to the fact that release() is a METH_NOARGS method, while __exit__() uses METH_VARARGS. Phew. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 17:10:10 2008 From: report at bugs.python.org (Carl Meyer) Date: Thu, 06 Mar 2008 16:10:10 -0000 Subject: [issue2244] urllib and urllib2 decode userinfo multiple times In-Reply-To: <1204819810.33.0.413464262118.issue2244@psf.upfronthosting.co.za> Message-ID: <1204819810.33.0.413464262118.issue2244@psf.upfronthosting.co.za> New submission from Carl Meyer: Both urllib and urllib2 call urllib.unquote() multiple times on data in the userinfo section of an FTP URL. One call occurs at the end of the urllib.splituser() function. In urllib, the other call appears in URLOpener.open_ftp(). In urllib2, the other two occur in FTPHandler.ftp_open() and Request.get_host(). The effect of this is that if the userinfo section of an FTP url should need to contain a literal % sign followed by two digits, the % sign must be double-encoded as %2525 (for urllib) or triple-encoded as %252525 (for urllib2) in order for the URL to be accessed. The proper behavior would be to only ever unquote a given data segment once. The W3's URI: Generic Syntax RFC (http://gbiv.com/protocols/uri/rfc/rfc3986.html) addresses this very issue in section 2.4 (When to Encode or Decode): "Implementations must not percent-encode or decode the same string more than once, as decoding an already decoded string might lead to misinterpreting a percent data octet as the beginning of a percent-encoding, or vice versa in the case of percent-encoding an already percent-encoded string." The solution would be to standardize where in urllib and urllib2 the unquoting happens, and then make sure it happens nowhere else. I'm not familiar enough with the libraries to know where it should be removed without possibly breaking other behavior. It seems that just removing the map/unquote call in urllib.splituser() would fix the problem in urllib. I would guess the call in urllib2 Request.get_host() should also be removed, as the RFC referenced above says clearly that only individual data segments of the URL should be decoded, not larger portions that might contain delimiters (: and @). I've attached a patchset for these suggested changes. Very superficial testing suggests that the patch doesn't break anything obvious, but I make no guarantees. ---------- components: Library (Lib) files: urllib-issue.patch keywords: patch messages: 63324 nosy: carljm severity: normal status: open title: urllib and urllib2 decode userinfo multiple times type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9621/urllib-issue.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 17:23:27 2008 From: report at bugs.python.org (Guilherme Polo) Date: Thu, 06 Mar 2008 16:23:27 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204820607.47.0.421738670115.issue2240@psf.upfronthosting.co.za> Changes by Guilherme Polo: Added file: http://bugs.python.org/file9622/setitimer_getitimer_wrapper_doc_update.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 17:26:17 2008 From: report at bugs.python.org (Guilherme Polo) Date: Thu, 06 Mar 2008 16:26:17 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204820777.24.0.536403791168.issue2240@psf.upfronthosting.co.za> Guilherme Polo added the comment: I've done some tests for getitimer/setitimer, diff is attached. Added file: http://bugs.python.org/file9623/setitimer_getitimer_wrapper_test.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 17:52:24 2008 From: report at bugs.python.org (Oki Mikito) Date: Thu, 06 Mar 2008 16:52:24 -0000 Subject: [issue2245] aifc cannot handle unrecognised chunk type "CHAN" In-Reply-To: <1204822344.2.0.466596380411.issue2245@psf.upfronthosting.co.za> Message-ID: <1204822344.2.0.466596380411.issue2245@psf.upfronthosting.co.za> New submission from Oki Mikito: When aifc tries to open an AIFF audio file, it collects the file's chunk information. Apparently some AIFF files contain a chunk type string "CHAN", and the module just won't open the files... Here's a captured error message: ------------ >>> import os >>> os.getcwd() 'C:??Documents and Settings??loki' >>> import aifc >>> f=aifc.open('tr_04.aif','r') Traceback (most recent call last): File "", line 1, in File "C:?Python25?lib?aifc.py", line 928, in open return Aifc_read(f) File "C:?Python25?lib?aifc.py", line 341, in __init__ self.initfp(f) File "C:?Python25?lib?aifc.py", line 320, in initfp raise Error, 'unrecognized chunk type '+chunk.chunkname Error: unrecognized chunk type CHAN >>> ------------ Solution: Add 'CHAN' in the list of _skiplist item, in lib/aifc.py, line 147 ---------- components: Library (Lib) messages: 63326 nosy: loki_dePlume severity: normal status: open title: aifc cannot handle unrecognised chunk type "CHAN" type: feature request versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 19:11:44 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Mar 2008 18:11:44 -0000 Subject: [issue1725737] Distutils default exclude doesn't match top level .svn Message-ID: <1204827104.52.0.148532638261.issue1725737@psf.upfronthosting.co.za> Martin v. L?wis added the comment: -1 on including anything that is a temporary file of some program. It's the job of the packager to clean the directory before packaging. I personally don't want to spend any more time on this issue. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 6 19:29:28 2008 From: report at bugs.python.org (Chris Palmer) Date: Thu, 06 Mar 2008 18:29:28 -0000 Subject: [issue2242] Decoding UTF-7 with "ignore warnings" crashes Python on Windows Vista In-Reply-To: <1204770663.59.0.831409423961.issue2242@psf.upfronthosting.co.za> Message-ID: <1204828168.57.0.723039548155.issue2242@psf.upfronthosting.co.za> Chris Palmer added the comment: You could also fix the problem by using iswalnum function instead of isalnum. Sorry I didn't mention this in the original report. http://msdn2.microsoft.com/en-us/library/k84c0490(VS.71).aspx __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 19:36:15 2008 From: report at bugs.python.org (Jamie Bliss) Date: Thu, 06 Mar 2008 18:36:15 -0000 Subject: [issue2211] Cookie.Morsel interface needs update In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za> Message-ID: <1204828575.17.0.76306168525.issue2211@psf.upfronthosting.co.za> Jamie Bliss added the comment: Sure, I'll do that. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 19:48:19 2008 From: report at bugs.python.org (Mads Kiilerich) Date: Thu, 06 Mar 2008 18:48:19 -0000 Subject: [issue1227748] subprocess: inheritance of std descriptors inconsistent Message-ID: <1204829299.08.0.282049409818.issue1227748@psf.upfronthosting.co.za> Mads Kiilerich added the comment: Note to others searching for a solution to this and similar problems: http://svn.python.org/view/python/trunk/Lib/subprocess.py?rev=60115&view=auto shows that this now (for 2.6?) has been changed so that close_fds now controls inheritance through the CreateProcess parameter bInheritHandles Thanks! ---------- nosy: +kiilerix _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 6 20:10:55 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 06 Mar 2008 19:10:55 -0000 Subject: [issue1714] ConfigParser.py do not allow leading (and trailing) space in values. In-Reply-To: <1199115002.03.0.289718233868.issue1714@psf.upfronthosting.co.za> Message-ID: <1204830655.46.0.334243273711.issue1714@psf.upfronthosting.co.za> Changes by Raghuram Devarakonda: ---------- nosy: +draghuram __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 20:11:11 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 06 Mar 2008 19:11:11 -0000 Subject: [issue1524825] ConfigParser: accept leading whitespace on options+comments Message-ID: <1204830671.25.0.466720877793.issue1524825@psf.upfronthosting.co.za> Changes by Raghuram Devarakonda: ---------- nosy: +draghuram _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 6 20:14:54 2008 From: report at bugs.python.org (Jamie Bliss) Date: Thu, 06 Mar 2008 19:14:54 -0000 Subject: [issue2211] Cookie.Morsel interface needs update In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za> Message-ID: <1204830894.22.0.231821344684.issue2211@psf.upfronthosting.co.za> Jamie Bliss added the comment: * Should be backwards compatible with people who actually use Morsel * Didn't even attempt to document it * Instead of having the Morsel dict being filled initially, unset attributes are, well, unset * .key, .value, and .coded_value are now property()s * .value is considered the actual value (eg, .coded_value is ignore for __eq__()) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 20:39:29 2008 From: report at bugs.python.org (Jeroen Ruigrok van der Werven) Date: Thu, 06 Mar 2008 19:39:29 -0000 Subject: [issue2246] itertools.groupby() leaks memory with circular reference In-Reply-To: <1204832369.47.0.680636098879.issue2246@psf.upfronthosting.co.za> Message-ID: <1204832369.47.0.680636098879.issue2246@psf.upfronthosting.co.za> New submission from Jeroen Ruigrok van der Werven: Quoting from my email to Raymond: In the Trac/Genshi community we've been tracking a bit obscure memory leak that causes us a lot of problems. Please see http://trac.edgewall.org/ticket/6614 and then http://genshi.edgewall.org/ticket/190 for background. We reduced the case to the following Python only code and believe it is a bug within itertool's groupby. As Armin Ronacher explains in Genshi ticket 190: "Looks like genshi is not to blame. itertools.groupby has a grouper with a reference to the groupby type but no traverse func. As soon as a circular reference ends up in the groupby (which happens thanks to the func_globals in our lambda) genshi leaks." This can be demonstrated with the following code (testcase attachment present with this issue): import gc from itertools import groupby def run(): keyfunc = lambda x: x for i, j in groupby(range(100), key=keyfunc): keyfunc.x = j for x in xrange(20): gc.collect() run() print len(gc.get_objects()) On executing this in will show numerical output of the garbage collector, but every iteration will be +4 from the previous, as Armin specifies: "a frame, a grouper, a keyfunc and a groupby object" We have been unable to come up with a decent patch and thus I am logging this issue now. ---------- files: testcase.py messages: 63332 nosy: asmodai, rhettinger severity: normal status: open title: itertools.groupby() leaks memory with circular reference type: resource usage versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9624/testcase.py __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 20:54:32 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Mar 2008 19:54:32 -0000 Subject: [issue1533486] long -> Py_ssize_t (C/API 1.2.1) Message-ID: <1204833272.63.0.294436161002.issue1533486@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- assignee: -> georg.brandl components: +None nosy: +georg.brandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 6 20:54:42 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Mar 2008 19:54:42 -0000 Subject: [issue1533486] long -> Py_ssize_t (C/API 1.2.1) Message-ID: <1204833282.85.0.527475515453.issue1533486@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- components: -None _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 6 20:59:04 2008 From: report at bugs.python.org (Brian White) Date: Thu, 06 Mar 2008 19:59:04 -0000 Subject: [issue2241] Additional Flag For Unit-Test Module: There Can Be Only One (Error) In-Reply-To: <1204734272.92.0.489101809074.issue2241@psf.upfronthosting.co.za> Message-ID: <1204833544.93.0.405379126952.issue2241@psf.upfronthosting.co.za> Brian White added the comment: Having tests run independently of each other is not the same as having tests be completely independent. I'd argue that the latter is impossible. You're never going to test the entire system in a single test case and thus the tests work together (i.e. not independently) to test everything. If one function under test calls another function that is also tested, then it makes sense to test the lower-level function first and display any problems as it will be easier/faster to find the root of the trouble than when the error causes unexpected results in the higher-level function. To make things easier, I simply name my tests such that lower-level functions are tested first. Each individual tests still runs independently, of course. The point of the "--one" option is just to have it stop when the first test fails, allowing me to fix the lowest level error. If that same error causes a dozen other tests to also fail and I just pick one failure randomly to start debugging, it's going to take me longer, perhaps a lot longer, to track down the problem. As for the method of implementation, I'm sure there are better ways to do it. Though I can write fully functional programs in Python, I by no means consider myself an expert in the language. I did it this way because the only other solution I saw was a global variable and figured that would be a poor way to do it. As such, I'd appreciate help on exactly how it should "properly" be done. :-) I'll let somebody else actually re-open this issue if it's a desired item since I'm not knowledgeable enough to see the solution you propose. Thanks! __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 21:29:04 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Mar 2008 20:29:04 -0000 Subject: [issue2247] Test auto-assignment Message-ID: <1204835344.33.0.569915653385.issue2247@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- assignee: georg.brandl components: Documentation tools (Sphinx) nosy: georg.brandl, loewis severity: normal status: open title: Test auto-assignment __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 21:29:21 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 06 Mar 2008 20:29:21 -0000 Subject: [issue2247] Test auto-assignment Message-ID: <1204835361.52.0.553318828532.issue2247@psf.upfronthosting.co.za> Changes by Martin v. L?wis: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 21:32:11 2008 From: report at bugs.python.org (Steve Purcell) Date: Thu, 06 Mar 2008 20:32:11 -0000 Subject: [issue2241] Additional Flag For Unit-Test Module: There Can Be Only One (Error) In-Reply-To: <1204734272.92.0.489101809074.issue2241@psf.upfronthosting.co.za> Message-ID: <1204835531.05.0.858870556559.issue2241@psf.upfronthosting.co.za> Steve Purcell added the comment: Hi Brian - thanks for going into some details of your rationale! You might be surprised to hear that it's indeed possible to make all of your unit tests mutually independent; check out the area of 'mock objects'. It turns out to be possible, and indeed desirable once the "zen" of the technique clicks, to test every class in isolation without referring to other neighbouring classes. I was surprised by the enormous effectiveness of this somewhat hardcore technique when I was forced into it by working with one of the original Mock Object paper authors. Having already spent years coaching developers in XP techniques, I thought I was already a testing whiz. In most real-world cases, though, a class under test will be tested using its interaction with other separately-tested classes in the system, and the associated unit tests therefore bear some relation to one another. It's usually not helpful to divide those classes into layers that can be tested in order from the lowest layer to the highest, because classes tend to form clumps rather than layers. When a big suite of tests is run, failures therefore form clumps too, and often the underlying programming error is easier to see by looking at the clump rather than just the first failure. I think this explains why most people get by without an option like '-o'. Of course, it often makes sense to have separate test suites for different areas of the system under test so that they can be run in isolation. Rather than relying on test naming, you might consider explicitly building TestSuites that run your test cases in the desired order. As for preparing an updated patch, I'll get to it if I get a few minutes. All the best from this Brit in Germany. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 21:48:10 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 06 Mar 2008 20:48:10 -0000 Subject: [issue2246] itertools.groupby() leaks memory with circular reference In-Reply-To: <1204832369.47.0.680636098879.issue2246@psf.upfronthosting.co.za> Message-ID: <1204836490.07.0.80404182444.issue2246@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: With the following patch: =================================================================== --- Lib/test/test_itertools.py (revision 61284) +++ Lib/test/test_itertools.py (working copy) @@ -707,6 +707,12 @@ a = [] self.makecycle(takewhile(bool, [1, 0, a, a]), a) + def test_issue2246(self): + n = 10 + keyfunc = lambda x: x + for i, j in groupby(xrange(n), key=keyfunc): + keyfunc.__dict__.setdefault('x',[]).append(j) + def R(seqn): 'Regular generator' for i in seqn: $ ./python Lib/test/regrtest.py -R :: test_itertools reports n*3 + 13 reference leaks. This should give a clue ... ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 21:53:49 2008 From: report at bugs.python.org (Armin Ronacher) Date: Thu, 06 Mar 2008 20:53:49 -0000 Subject: [issue2246] itertools.groupby() leaks memory with circular reference In-Reply-To: <1204832369.47.0.680636098879.issue2246@psf.upfronthosting.co.za> Message-ID: <1204836829.1.0.908436839542.issue2246@psf.upfronthosting.co.za> Changes by Armin Ronacher: ---------- nosy: +aronacher __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 22:05:44 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 06 Mar 2008 21:05:44 -0000 Subject: [issue2246] itertools.groupby() leaks memory with circular reference In-Reply-To: <1204832369.47.0.680636098879.issue2246@psf.upfronthosting.co.za> Message-ID: <1204837544.92.0.0624020916856.issue2246@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: It looks like the problem is that the internal grouper object becomes a part of a cycle: keyfunc -> grouper(x) -> keyfunc(tgtkey), but its type does not support GC. I will try to come up with a patch. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 22:07:18 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 06 Mar 2008 21:07:18 -0000 Subject: [issue2246] itertools.groupby() leaks memory with circular reference In-Reply-To: <1204832369.47.0.680636098879.issue2246@psf.upfronthosting.co.za> Message-ID: <1204837638.95.0.850462457824.issue2246@psf.upfronthosting.co.za> Raymond Hettinger added the comment: No need. I'm already working on adding GC to the grouper. ---------- assignee: -> rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 22:21:49 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 06 Mar 2008 21:21:49 -0000 Subject: [issue2246] itertools.groupby() leaks memory with circular reference In-Reply-To: <1204832369.47.0.680636098879.issue2246@psf.upfronthosting.co.za> Message-ID: <1204838509.45.0.516585870058.issue2246@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Oops. Here is my patch anyways. ---------- keywords: +patch Added file: http://bugs.python.org/file9625/groupby-leak.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 22:32:21 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Thu, 06 Mar 2008 21:32:21 -0000 Subject: [issue2246] itertools.groupby() leaks memory with circular reference In-Reply-To: <1204832369.47.0.680636098879.issue2246@psf.upfronthosting.co.za> Message-ID: <1204839141.49.0.751245337712.issue2246@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: Damn, I wrote a patch too ;) ---------- nosy: +_doublep __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 23:53:12 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 06 Mar 2008 22:53:12 -0000 Subject: [issue2246] itertools.groupby() leaks memory with circular reference In-Reply-To: <1204832369.47.0.680636098879.issue2246@psf.upfronthosting.co.za> Message-ID: <1204843992.55.0.408579794745.issue2246@psf.upfronthosting.co.za> Raymond Hettinger added the comment: r61286. Applied a patch substantially similar to Alexanders. Thanks for the test case and the report. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 6 23:59:05 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 06 Mar 2008 22:59:05 -0000 Subject: [issue2196] Fix hasattr's exception problems In-Reply-To: <1204066315.71.0.0794011213674.issue2196@psf.upfronthosting.co.za> Message-ID: <1204844345.44.0.141034482795.issue2196@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I suppose another way we could do this is propagate any exception which doesn't inherit Exception. I, however, like just having just those 2 specific exceptions continue. ---------- assignee: -> georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 00:07:52 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 06 Mar 2008 23:07:52 -0000 Subject: [issue2245] aifc cannot handle unrecognised chunk type "CHAN" In-Reply-To: <1204822344.2.0.466596380411.issue2245@psf.upfronthosting.co.za> Message-ID: <1204844872.9.0.30706367641.issue2245@psf.upfronthosting.co.za> Changes by Benjamin Peterson: ---------- nosy: +sjoerd __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 00:52:15 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Thu, 06 Mar 2008 23:52:15 -0000 Subject: [issue1725737] Distutils default exclude doesn't match top level .svn Message-ID: <1204847535.0.0.612843943588.issue1725737@psf.upfronthosting.co.za> Ralf Schmitt added the comment: then close this one and also http://bugs.python.org/issue1095784 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 7 00:53:53 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Thu, 06 Mar 2008 23:53:53 -0000 Subject: [issue1095784] exclude CVS conflict files in sdist command Message-ID: <1204847633.8.0.801708355438.issue1095784@psf.upfronthosting.co.za> Ralf Schmitt added the comment: related issue: http://bugs.python.org/issue1725737 ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 7 03:03:34 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 07 Mar 2008 02:03:34 -0000 Subject: [issue1533486] long -> Py_ssize_t (C/API 1.2.1) Message-ID: <1204855414.34.0.192968212553.issue1533486@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I think it should be changed to "because sizeof(Py_ssize_t) == sizeof(void*)" ---------- nosy: +belopolsky _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 7 07:27:47 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Fri, 07 Mar 2008 06:27:47 -0000 Subject: [issue1193577] add server.shutdown() method to SocketServer Message-ID: <1204871267.66.0.417225162681.issue1193577@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Hearing no objections, I've submitted this as r61289. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 7 08:42:58 2008 From: report at bugs.python.org (Kei Funagayama) Date: Fri, 07 Mar 2008 07:42:58 -0000 Subject: [issue2248] quit() method of SMTP instance (of smtplib) doesn't return it's result In-Reply-To: <1204875778.72.0.769426067571.issue2248@psf.upfronthosting.co.za> Message-ID: <1204875778.72.0.769426067571.issue2248@psf.upfronthosting.co.za> New submission from Kei Funagayama: Hi, I've found that the quit() method of SMTP instance (of smtplib) doesn't return it's result (such as '221 2.0.0 Bye') . Other methods such as helo(), ehlo(), verify() etc.. returns it's result correctly so I suppose it's a kind of bug. I've made a small patch for this so please take a look at it (It looks like someone just forgot to return the value of docmd()). below is the code piece to represent the problem. >>> import smtplib >>> s = smtplib.SMTP('localhost') >>> s.helo() #<---- returns result code (250, 'localhost') >>> s.vrfy('user at example.com') #<---- returns result code (554, '5.7.1 <>: Relay access denied') >>> s.quit() #<----- doesn't return anything >>> Thanks, Kei ---------- components: Library (Lib) files: smtplib.py.patch keywords: patch messages: 63346 nosy: funagayama severity: normal status: open title: quit() method of SMTP instance (of smtplib) doesn't return it's result versions: Python 2.4, Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9626/smtplib.py.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 09:39:25 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Fri, 07 Mar 2008 08:39:25 -0000 Subject: [issue2249] To document "assertTrue" in unittest In-Reply-To: <1204879165.33.0.589242853874.issue2249@psf.upfronthosting.co.za> Message-ID: <1204879165.33.0.589242853874.issue2249@psf.upfronthosting.co.za> New submission from Jes?s Cea Avi?n: Python 2.4 and 2.5 unittest includes a "assertTrue" method undocumented. Document it. It is the same method as "assert_" and "failUnless", but the name seems clearer. ---------- assignee: georg.brandl components: Documentation messages: 63347 nosy: georg.brandl, jcea severity: minor status: open title: To document "assertTrue" in unittest versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 09:39:44 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Fri, 07 Mar 2008 08:39:44 -0000 Subject: [issue2249] To document "assertTrue" in unittest In-Reply-To: <1204879165.33.0.589242853874.issue2249@psf.upfronthosting.co.za> Message-ID: <1204879184.74.0.383664655006.issue2249@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n: ---------- versions: +Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 11:16:29 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Fri, 07 Mar 2008 10:16:29 -0000 Subject: [issue2222] Memory leak in os.rename? In-Reply-To: <1204549533.94.0.102574866059.issue2222@psf.upfronthosting.co.za> Message-ID: <1204884989.32.0.351246293802.issue2222@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Alexander, I've looked into Python/getargs.c, I think posix_2str code is fine. (PyArg_ParseTuple with format "et") After conversion succeeded on path1, addcleanup() adds memory buffer for path1 into freelist. When error happend on path2, its memory will be freed on cleanreturn(). __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 11:24:19 2008 From: report at bugs.python.org (vila) Date: Fri, 07 Mar 2008 10:24:19 -0000 Subject: [issue1389051] imaplib causes excessive fragmentation for large documents Message-ID: <1204885459.53.0.911110902029.issue1389051@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 7 11:24:42 2008 From: report at bugs.python.org (vila) Date: Fri, 07 Mar 2008 10:24:42 -0000 Subject: [issue1092502] Memory leak in socket.py on Mac OS X Message-ID: <1204885482.47.0.374576945832.issue1092502@psf.upfronthosting.co.za> Changes by vila: ---------- nosy: +vila _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 7 11:49:57 2008 From: report at bugs.python.org (Lorenz Quack) Date: Fri, 07 Mar 2008 10:49:57 -0000 Subject: [issue2250] rlcompleter raises Exception on bad input In-Reply-To: <1204886997.65.0.75088007868.issue2250@psf.upfronthosting.co.za> Message-ID: <1204886997.65.0.75088007868.issue2250@psf.upfronthosting.co.za> New submission from Lorenz Quack: in line 130 rlcompleter calls eval on the first part (before the last dot) of the input text. if that part is not valid it will raise an exception which is likely to crash a calling application. example 1: ========== import rlcompleter rlcompleter.Completer().complete("foo.", 0) -> raises NameError example 2: ========== import rlcompleter foo = 5 rlcompleter.Completer().complete("foo.bar.", 0) -> raises AttributeError the patch puts the eval call in a try-except block and catches Name- and AttributeErrors and returns an empty list (the behavior when no matches are found). ---------- components: Library (Lib) files: rlcompleter.patch keywords: patch messages: 63349 nosy: donlorenzo severity: normal status: open title: rlcompleter raises Exception on bad input type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9627/rlcompleter.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 12:10:14 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Fri, 07 Mar 2008 11:10:14 -0000 Subject: [issue2196] Fix hasattr's exception problems In-Reply-To: <1204066315.71.0.0794011213674.issue2196@psf.upfronthosting.co.za> Message-ID: <1204888214.59.0.0552295614113.issue2196@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: I think it would be better not to hardcode specific 2 exceptional cases and indeed follow that second way of instanceof(..., Exception). I think it was introduced exactly to separate "things that can be caught by default" from "things that may be caught only in very special cases". I don't find it good Python interpreter not following its own rules. ---------- nosy: +_doublep __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 12:17:51 2008 From: report at bugs.python.org (Goten Xiao) Date: Fri, 07 Mar 2008 11:17:51 -0000 Subject: [issue2251] tarfile using nonexistent function In-Reply-To: <1204888671.17.0.924407894486.issue2251@psf.upfronthosting.co.za> Message-ID: <1204888671.17.0.924407894486.issue2251@psf.upfronthosting.co.za> New submission from Goten Xiao: Steps to reproduce: Create test.py with the following contents: tar = tarfile.open("test.tar", "w") tar.addfile("testdir") tar.close() Run the following commands (or equivalent on alternative platforms): mkdir testdir touch testdir/testfile python test.py Resultant output: Traceback (most recent call last): File "test.py", line 4, in tar.addfile("testdir") File "/usr/lib/python2.5/tarfile.py", line 1492, in addfile buf = tarinfo.tobuf(self.posix) AttributeError: 'str' object has no attribute 'tobuf' Tested on Python 2.5.1 and 2.5.2 from slackware-current packages. ---------- components: Library (Lib) messages: 63351 nosy: GotenXiao severity: major status: open title: tarfile using nonexistent function type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 12:18:34 2008 From: report at bugs.python.org (Goten Xiao) Date: Fri, 07 Mar 2008 11:18:34 -0000 Subject: [issue2251] tarfile using nonexistent function In-Reply-To: <1204888671.17.0.924407894486.issue2251@psf.upfronthosting.co.za> Message-ID: <1204888714.35.0.619927827658.issue2251@psf.upfronthosting.co.za> Goten Xiao added the comment: Whoops, add: import tarfile to the top of test.py. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 13:01:48 2008 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 07 Mar 2008 12:01:48 -0000 Subject: [issue2179] with should be as fast as try/finally In-Reply-To: <1203894641.18.0.492382147443.issue2179@psf.upfronthosting.co.za> Message-ID: <1204891308.94.0.117142725423.issue2179@psf.upfronthosting.co.za> Nick Coghlan added the comment: Patch applied cleanly for me and all tests pass. It also looked good on a visual scan over the diff text. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 13:10:23 2008 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Fri, 07 Mar 2008 12:10:23 -0000 Subject: [issue2251] tarfile using nonexistent function In-Reply-To: <1204888671.17.0.924407894486.issue2251@psf.upfronthosting.co.za> Message-ID: <1204891823.86.0.353609410475.issue2251@psf.upfronthosting.co.za> Lars Gust?bel added the comment: This is in fact misuse of the addfile() method on your side. The docs (http://docs.python.org/dev/library/tarfile.html#tarfile.TarFile.addfile) state that the first argument is supposed to be a TarInfo object not a pathname. You should use the add() method instead. ---------- assignee: -> lars.gustaebel nosy: +lars.gustaebel resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 15:17:52 2008 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 07 Mar 2008 14:17:52 -0000 Subject: [issue2179] with should be as fast as try/finally In-Reply-To: <1203894641.18.0.492382147443.issue2179@psf.upfronthosting.co.za> Message-ID: <1204899472.69.0.0918447424775.issue2179@psf.upfronthosting.co.za> Nick Coghlan added the comment: I went ahead and committed the change to the bytecode generation as r61290. The deficiencies in the lock implementation should probably be raised as a separate issue, so I'm closing this one. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 15:43:03 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 07 Mar 2008 14:43:03 -0000 Subject: [issue2179] with should be as fast as try/finally In-Reply-To: <1203894641.18.0.492382147443.issue2179@psf.upfronthosting.co.za> Message-ID: <1204900983.55.0.450469121291.issue2179@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Hm, my tests do not see any speedup with this patch. I used VS2005 on win2K, and VS2008 on winXP. Timings are very similar before and after this patch. Maybe the optimization is only useful with gcc? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 16:56:02 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 07 Mar 2008 15:56:02 -0000 Subject: [issue2222] Memory leak in os.rename? In-Reply-To: <1204549533.94.0.102574866059.issue2222@psf.upfronthosting.co.za> Message-ID: <1204905362.96.0.267342659823.issue2222@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Aha! I did not know about the cleanup. Maybe that should be documented as well. This shows that using O& with a converter returning a PyObject* is a bad idea. (General clean-up is not possible for O& because there is no way to tell what type the converter returns.) I am still +1 on your original patch. It is obviously correct and fixes the bug with minimum of changes. However, win32 code in posixmodule.c needs some clean-up. convert_to_unicode should be eliminated in favor of the approach used in win32_1str. It may also make sense to move conversion/api selection code to a win32_2str function. Even if it will be only used for rename, it will make the code more readable by making win32 code structure similar to posix. All this is a topic for another issue. I believe the only thing that needs to be done here is to enable error case testing for all platforms in the unit test. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 18:11:44 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 07 Mar 2008 17:11:44 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204909904.89.0.676069749373.issue2240@psf.upfronthosting.co.za> Changes by Ralf Schmitt: ---------- nosy: +schmir __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 18:18:25 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 07 Mar 2008 17:18:25 -0000 Subject: [issue1683] Thread local storage and PyGILState_* mucked up by os.fork() In-Reply-To: <1198263226.4.0.968502752614.issue1683@psf.upfronthosting.co.za> Message-ID: <1204910305.86.0.0115612200836.issue1683@psf.upfronthosting.co.za> Changes by Ralf Schmitt: ---------- nosy: +schmir __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 19:10:12 2008 From: report at bugs.python.org (Ben Pfaff) Date: Fri, 07 Mar 2008 18:10:12 -0000 Subject: [issue2252] "continue" documentation Message-ID: <1204913412.29.0.439518703627.issue2252@psf.upfronthosting.co.za> Changes by Ben Pfaff: ---------- assignee: georg.brandl components: Documentation nosy: blp, georg.brandl severity: normal status: open title: "continue" documentation versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 19:12:29 2008 From: report at bugs.python.org (Ben Pfaff) Date: Fri, 07 Mar 2008 18:12:29 -0000 Subject: [issue2253] "continue" documentation internally inconsistent In-Reply-To: <1204913549.67.0.904198445457.issue2253@psf.upfronthosting.co.za> Message-ID: <1204913549.67.0.904198445457.issue2253@psf.upfronthosting.co.za> New submission from Ben Pfaff: The "continue" documentation says: "continue may only occur syntactically nested in a for or while loop, but not nested in a function or class definition or finally statement within that loop." In a footnote to that documentation, it says: "The restriction on occurring in the try clause is implementor's laziness and will eventually be lifted." But the documentation doesn't say that continue may not occur in the try clause. So there is an internal inconsistency here. Either the sentence in the footnote is wrong and should be removed, or the main documentation for continue should say that continue may not occur in a try clause. ---------- assignee: georg.brandl components: Documentation messages: 63358 nosy: blp, georg.brandl severity: minor status: open title: "continue" documentation internally inconsistent versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 19:19:33 2008 From: report at bugs.python.org (Ben Pfaff) Date: Fri, 07 Mar 2008 18:19:33 -0000 Subject: [issue2252] "continue" documentation In-Reply-To: <1204913973.62.0.410162362524.issue2252@psf.upfronthosting.co.za> Message-ID: <1204913973.62.0.410162362524.issue2252@psf.upfronthosting.co.za> New submission from Ben Pfaff: Apologies for filing this issue report: I hit "Enter" at the wrong time. Issue 2253 was what I really meant to file. You can close this issue. Sorry about that. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 19:43:15 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 07 Mar 2008 18:43:15 -0000 Subject: [issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString. In-Reply-To: <1201473895.18.0.771876708371.issue1950@psf.upfronthosting.co.za> Message-ID: <1204915395.68.0.838343903686.issue1950@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Your description of the patch is a bit misleading. As far as I can tell only the first chunk (Python/import.c changes) addresses a potential buffer overflow. For example the last chunk (Modules/posixmodule.c changes) simply eliminates an unused variable. While a worthwhile change, it should not be bundled with what is potentially a security patch. I have a few suggestions: 1. It will really help if you produce a test case that crashes the interpretor. I am sure that will get noticed. 2. If any of buffer overflows apply to the current production versions (2.4 or 2.5) or even the alpha release (2.6a1), it would make sense to backport it to the trunk. Once again, security issues in the trunk will get noticed much faster than in py3k branch. ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 19:52:44 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 07 Mar 2008 18:52:44 -0000 Subject: [issue2252] "continue" documentation In-Reply-To: <1204913973.62.0.410162362524.issue2252@psf.upfronthosting.co.za> Message-ID: <1204915964.83.0.524767823789.issue2252@psf.upfronthosting.co.za> Changes by Georg Brandl: ---------- resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 20:59:45 2008 From: report at bugs.python.org (sumar) Date: Fri, 07 Mar 2008 19:59:45 -0000 Subject: [issue2254] Python CGIHTTPServer information disclosure In-Reply-To: <1204919985.1.0.220899639338.issue2254@psf.upfronthosting.co.za> Message-ID: <1204919985.1.0.220899639338.issue2254@psf.upfronthosting.co.za> New submission from sumar: ================================================================================ Summary: ================================================================================ An information disclosure flaw exists in standard python CGIHTTPServer module. Bug is confirmed in python 2.5 @ fedora 7 (python-2.5-15.fc7). ================================================================================ Description: ================================================================================ Requesting cgi script (in example test.py) without / in the beginnig of URL cause return script content/code instead of script execution. It could lead to disclose some secret information eg. password. ================================================================================ Exploit code: ================================================================================ Connected to localhost. Escape character is '^]'. GET cgi-bin/test.py HTTP/1.0 HTTP/1.0 200 OK Server: SimpleHTTP/0.6 Python/2.5 Date: Fri, 07 Mar 2008 14:55:30 GMT Content-type: text/plain Content-Length: 150 Last-Modified: Fri, 07 Mar 2008 14:55:04 GMT #!/usr/bin/env python print 'Content-Type: text/html' print 'Cache-Control: no-cache' print print 'Hello' passwd='secret' path=/opt/myapp/secretpath Connection closed by foreign host. ================================================================================ correct request: ================================================================================ Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET /cgi-bin/test.py HTTP/1.0 HTTP/1.0 200 Script output follows Server: SimpleHTTP/0.6 Python/2.5 Date: Fri, 07 Mar 2008 15:01:03 GMT Content-Type: text/html Cache-Control: no-cache Hello Connection closed by foreign host. ================================================================================ ---------- components: Library (Lib) messages: 63361 nosy: m.sucajtys severity: normal status: open title: Python CGIHTTPServer information disclosure type: security versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 21:09:48 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 07 Mar 2008 20:09:48 -0000 Subject: [issue771479] pyconfig.h duplicates common defines Message-ID: <1204920588.35.0.822695461503.issue771479@psf.upfronthosting.co.za> Martin v. L?wis added the comment: None of the PACKAGE_ macros gets defined anymore. For the other ones, I'll close the report as "won't fix". ---------- resolution: -> wont fix status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 7 21:19:24 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 07 Mar 2008 20:19:24 -0000 Subject: [issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString. In-Reply-To: <1201473895.18.0.771876708371.issue1950@psf.upfronthosting.co.za> Message-ID: <1204921164.2.0.188543247579.issue1950@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I tried to produce a buffer overflow in get_parent (import.c), but an attempt to import a module with non-ascii characters is aborted in getargs.c before get_parent is reached: >>> __import__("\u0080xyz") Traceback (most recent call last): File "", line 1, in TypeError: __import__() argument 1 must be string without null bytes, not str This looks like a bug. At the very least the error message is misleading because there are no null bytes in "\u0080xyz" string. The offending code is if ((Py_ssize_t)strlen(*p) != PyUnicode_GetSize(arg)) return converterr("string without null bytes", arg, msgbuf, bufsize); at getargs.c:826 However, given the preceding "XXX WAAAAH!" comment, this is probably a sign of not yet implemented feature rather than a bug. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 22:06:03 2008 From: report at bugs.python.org (Guilherme Polo) Date: Fri, 07 Mar 2008 21:06:03 -0000 Subject: [issue2254] Python CGIHTTPServer information disclosure In-Reply-To: <1204919985.1.0.220899639338.issue2254@psf.upfronthosting.co.za> Message-ID: <1204923963.2.0.893091394705.issue2254@psf.upfronthosting.co.za> Guilherme Polo added the comment: I'm attaching a patch that fixes this, it was done for rev 61179 (trunk). Note that is_cgi method is incorrectly documented, even more now. Only the first line in its docstring is correct now, before this patch, last paragraph was correct too. ---------- keywords: +patch nosy: +gpolo Added file: http://bugs.python.org/file9628/CGIHTTPServer_is_cgi_fix.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 22:10:20 2008 From: report at bugs.python.org (Guilherme Polo) Date: Fri, 07 Mar 2008 21:10:20 -0000 Subject: [issue2254] Python CGIHTTPServer information disclosure In-Reply-To: <1204919985.1.0.220899639338.issue2254@psf.upfronthosting.co.za> Message-ID: <1204924219.95.0.802489958197.issue2254@psf.upfronthosting.co.za> Guilherme Polo added the comment: oops, I was doing some tests in the last patch and left a bug in it. I'm attaching a new one. Added file: http://bugs.python.org/file9629/CGIHTTPServer_is_cgi_fix2.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 22:31:59 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 07 Mar 2008 21:31:59 -0000 Subject: [issue2196] Fix hasattr's exception problems In-Reply-To: <1204066315.71.0.0794011213674.issue2196@psf.upfronthosting.co.za> Message-ID: <1204925519.31.0.855404649674.issue2196@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Here's a patch for that. Personally, I'm +1 on either option; I just want it fixed. :) I suppose the only (minor) problem with propagate things which are not Exception is libraries where the exceptions don't extend Exception. However, the ability to do this is being removed in Py3k, so it's not huge. Added file: http://bugs.python.org/file9630/hasattr_fixes2.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 22:34:05 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 07 Mar 2008 21:34:05 -0000 Subject: [issue2196] Fix hasattr's exception problems In-Reply-To: <1204066315.71.0.0794011213674.issue2196@psf.upfronthosting.co.za> Message-ID: <1204925645.28.0.784584613781.issue2196@psf.upfronthosting.co.za> Benjamin Peterson added the comment: That last patch is malformed. Added file: http://bugs.python.org/file9631/hasattr_fixes2-real.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 22:38:39 2008 From: report at bugs.python.org (Guilherme Polo) Date: Fri, 07 Mar 2008 21:38:39 -0000 Subject: [issue2254] Python CGIHTTPServer information disclosure In-Reply-To: <1204919985.1.0.220899639338.issue2254@psf.upfronthosting.co.za> Message-ID: <1204925919.23.0.728959652805.issue2254@psf.upfronthosting.co.za> Guilherme Polo added the comment: This corrects is_cgi docstring (maybe this should be done in a new issue?). It also removes a part of it that I believe to not be necessary, someone correct me if I'm wrong. Added file: http://bugs.python.org/file9632/CGIHTTPServer_is_cgi_doc_fix.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 23:00:30 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 07 Mar 2008 22:00:30 -0000 Subject: [issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString. In-Reply-To: <1201473895.18.0.771876708371.issue1950@psf.upfronthosting.co.za> Message-ID: <1204927230.5.0.748063074783.issue1950@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Here are my comments on the other parts of the patch: Python/structmember.c The existing code is safe, but would silently produce wrong result if T_CHAR attribute is assigned a non-ascii character. With the patch this situation will be detected and an exception raised. I am not sure that would be a desired behavior of py3k. I could not find any examples of using T_CHAR member in the stdlib, but an alternative solution would be to change T_CHAR code to mean PY_UNICODE_TYPE instead of char member. Objects/typeobject.c "%s" -> ".400s" is an obviously good change. The existing __doc__ processing code is correct. Proposed code may be marginally faster, but will allow docstrings with embedded null characters, which may or may not be desirable (and may break other code that uses tp_doc). Finally PyUnicode_AsStringAndSize always returns null-terminated strings, so memcpy logic does not need to be altered. Objects/structseq.c Change from macros to enums is purely stylistic and python C style seem to favor macros. I don't think a repr of a python object can contain embedded null characters, but even if that were the case, the patched code would not support it because the resulting buffer is returned with PyUnicode_FromString(buf). Modules/datetimemodule.c Existing code compensates for an error in initial estimate of totalnew when it checks for overflow, but the proposed change will make code more efficient. Modules/zipimport.c Since 's' format unit in PyArg_ParseTuple does not properly support unicode yet, it is hard to tell if the current code is wrong, but unicode paths cannot have embedded null characters, so use of 's#' is not necessary. Modules/timemodule.c Supporting format strings with null characters is probably a good idea, but that would be an RFE rather than a bug fix. Modules/parsermodule.c Looks like there is a bug there. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 23:14:24 2008 From: report at bugs.python.org (=?utf-8?q?Nicolas_L=C3=A9cureuil?=) Date: Fri, 07 Mar 2008 22:14:24 -0000 Subject: [issue2255] Change Mandrake by Mandriva for platform.dist() In-Reply-To: <1204928063.97.0.960198270628.issue2255@psf.upfronthosting.co.za> Message-ID: <1204928063.97.0.960198270628.issue2255@psf.upfronthosting.co.za> New submission from Nicolas L?cureuil: here is a patch fixing the issue by changing mandrake to mandriva ---------- components: Library (Lib) files: python-2.5-change-mandrake.patch keywords: patch messages: 63370 nosy: neoclust severity: normal status: open title: Change Mandrake by Mandriva for platform.dist() type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9633/python-2.5-change-mandrake.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 23:29:52 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 07 Mar 2008 22:29:52 -0000 Subject: [issue2249] To document "assertTrue" in unittest In-Reply-To: <1204879165.33.0.589242853874.issue2249@psf.upfronthosting.co.za> Message-ID: <1204928992.17.0.875206031483.issue2249@psf.upfronthosting.co.za> Changes by Benjamin Peterson: ---------- nosy: +purcell __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 7 23:36:31 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 07 Mar 2008 22:36:31 -0000 Subject: [issue2255] Change Mandrake by Mandriva for platform.dist() In-Reply-To: <1204928063.97.0.960198270628.issue2255@psf.upfronthosting.co.za> Message-ID: <1204929391.98.0.802227295216.issue2255@psf.upfronthosting.co.za> Changes by Benjamin Peterson: ---------- nosy: +lemburg __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 00:33:47 2008 From: report at bugs.python.org (Jim Kleckner) Date: Fri, 07 Mar 2008 23:33:47 -0000 Subject: [issue2256] Install failure of 2.6a1 on Windows XP without VS8 installed In-Reply-To: <1204932826.89.0.672189283054.issue2256@psf.upfronthosting.co.za> Message-ID: <1204932826.89.0.672189283054.issue2256@psf.upfronthosting.co.za> New submission from Jim Kleckner: When I install 2.6a1 onto a Windoze machine I get a dialog: There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Note that it didn't have VS2008 or any other new code installed. The problem appears related to Tkinter but that isn't clear. When running the Python console, running import Tkinter results in an error saying that _tkinter can't be loaded. DLL load failed. The system can't find _tkinter.pyd _tkinter.pyd and tcl84.dll and tk84.dll are in DLLs and appear to have reasonable permissions. I suspect something in the install failed to set something in the registry. This is on a current-patch XP system and that I also tried python-2.6.13944.msi from the buildbot just in case after uninstalling/reinstalling with no difference. Attached is a compressed log of the install. Perhaps this "PROPERTY CHANGE: Deleting SECONDSEQUENCE" is the problem? Here is an excerpt from the log file: Property(S): Privileged = 1 Property(S): DATABASE = C:\WINDOWS\Installer\5f5ad0.msi Property(S): OriginalDatabase = C:\cygwin\tmp\python-2.6a1.msi Property(S): UILevel = 5 Property(S): Preselected = 1 Property(S): CostingComplete = 1 Property(S): OutOfDiskSpace = 0 Property(S): OutOfNoRbDiskSpace = 0 Property(S): PrimaryVolumeSpaceAvailable = 0 Property(S): PrimaryVolumeSpaceRequired = 0 Property(S): PrimaryVolumeSpaceRemaining = 0 Property(S): SOURCEDIR = C:\cygwin\tmp\ Property(S): SourcedirProduct = {0BA82E1B-52FD-4E03-8610-A6C76238E8A8} Property(S): ProductToBeRegistered = 1 MSI (s) (FC:D0) [16:38:30:939]: MainEngineThread is returning 1603 MSI (s) (FC:C0) [16:38:30:939]: Destroying RemoteAPI object. MSI (s) (FC:54) [16:38:30:939]: Custom Action Manager thread ending. MSI (c) (E0:54) [16:38:30:954]: Back from server. Return value: 1603 MSI (c) (E0:54) [16:38:30:954]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1 MSI (c) (E0:54) [16:38:30:954]: PROPERTY CHANGE: Deleting SECONDSEQUENCE property. Its current value is '1'. Action ended 16:38:30: ExecuteAction. Return value 3. MSI (c) (E0:54) [16:38:30:954]: Doing action: FatalError Action 16:38:30: FatalError. Action start 16:38:30: FatalError. Action 16:38:30: FatalError. Dialog created Action ended 16:38:32: FatalError. Return value 2. Action ended 16:38:32: INSTALL. Return value 3. MSI (c) (E0:54) [16:38:32:375]: Destroying RemoteAPI object. MSI (c) (E0:2C) [16:38:32:375]: Custom Action Manager thread ending. Property(C): X = C:\Python26\Tools\pynche\X\ Property(C): UpgradeCode = {65E6DE48-A358-434D-AA4F-4AF72DB4718F} Property(C): ProductName = Python 2.6a1 Property(C): ProductCode = {0BA82E1B-52FD-4E03-8610-A6C76238E8A8} Property(C): ProductVersion = 2.6.101 Property(C): Manufacturer = Python Software Foundation ---------- components: Installation files: debuglog.txt.zip messages: 63371 nosy: jkleckner severity: normal status: open title: Install failure of 2.6a1 on Windows XP without VS8 installed type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9634/debuglog.txt.zip __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 00:40:49 2008 From: report at bugs.python.org (Facundo Batista) Date: Fri, 07 Mar 2008 23:40:49 -0000 Subject: [issue2255] Change Mandrake by Mandriva for platform.dist() In-Reply-To: <1204928063.97.0.960198270628.issue2255@psf.upfronthosting.co.za> Message-ID: <1204933249.76.0.0866356269636.issue2255@psf.upfronthosting.co.za> Facundo Batista added the comment: Assigning as the platform.py file says. The patch is straightforward, I'm only concerned with backward compatibility... ---------- assignee: -> lemburg nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 01:08:03 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Sat, 08 Mar 2008 00:08:03 -0000 Subject: [issue2179] with should be as fast as try/finally In-Reply-To: <1203894641.18.0.492382147443.issue2179@psf.upfronthosting.co.za> Message-ID: <1204934883.35.0.694664261298.issue2179@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n: ---------- nosy: +jcea __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 01:30:41 2008 From: report at bugs.python.org (Jean Brouwers) Date: Sat, 08 Mar 2008 00:30:41 -0000 Subject: [issue2218] Enhanced hotshot profiler with high-resolution timer In-Reply-To: <1204501511.28.0.993763550383.issue2218@psf.upfronthosting.co.za> Message-ID: <1204936241.37.0.610415592312.issue2218@psf.upfronthosting.co.za> Jean Brouwers added the comment: Here is another version of the profiler files with 7 minor changes in the _hotshot.c file. Use this hires_version3 set, if any. Added file: http://bugs.python.org/file9635/hires_hotshot3.tgz __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 01:40:09 2008 From: report at bugs.python.org (k-e-n) Date: Sat, 08 Mar 2008 00:40:09 -0000 Subject: [issue2257] typo in tutorial section 4.4 - final break statement is missing In-Reply-To: <1204936809.05.0.981645183837.issue2257@psf.upfronthosting.co.za> Message-ID: <1204936809.05.0.981645183837.issue2257@psf.upfronthosting.co.za> New submission from k-e-n: The code from section 4.4 of the tutorial follows. This code does not produce the output shown. Adding a final break statement will fix this. >>> for n in range(2, 10): ... for x in range(2, n): ... if n % x == 0: ... print n, 'equals', x, '*', n/x ... break ... else: ... # loop fell through without finding a factor ... print n, 'is a prime number' ... 2 is a prime number 3 is a prime number 4 equals 2 * 2 5 is a prime number 6 equals 2 * 3 7 is a prime number 8 equals 2 * 4 9 equals 3 * 3 ---------- assignee: georg.brandl components: Documentation messages: 63374 nosy: Kyte999, georg.brandl severity: minor status: open title: typo in tutorial section 4.4 - final break statement is missing versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 01:55:20 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 08 Mar 2008 00:55:20 -0000 Subject: [issue1733184] slice type is unhashable Message-ID: <1204937720.49.0.561962469423.issue1733184@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Patch # 408326 was designed to make assignment to d[:] an error where d is a dictionary. See discussion starting at http://mail.python.org/pipermail/python-list/2001-March/072078.html . I think the only reason slice objects need to be comparable is only to suppress inheritance of the default hash from object. This RFE is ripe to be rejected. Slice objects are really meant to be internal structures and not passed around in the user's code. You can always use tuples instead of slices and convert the to slices with slice(*t) when needed. ---------- nosy: +belopolsky type: -> feature request _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 8 02:25:42 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 08 Mar 2008 01:25:42 -0000 Subject: [issue1617161] Instance methods compare equal when their self's are equal Message-ID: <1204939542.6.0.671728993374.issue1617161@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > the change was meant to unify > the behavior of built-in and > user method objects I don't think it achieved that. Consider: >>> [].index == [].index False but >>> UserList().index == UserList().index True ---------- nosy: +belopolsky _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 8 02:41:11 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 08 Mar 2008 01:41:11 -0000 Subject: [issue1741218] string formatter %x problem with indirectly given long Message-ID: <1204940471.85.0.0076426264043.issue1741218@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This issue has been resolved in issue1742669 . $ ./python.exe Python 2.6a1+ (trunk:61230M, Mar 4 2008, 10:56:31) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class X: ... def __int__(self): return 0x80000000 ... >>> "%08x" % X() '80000000' ---------- nosy: +belopolsky, facundobatista title: string formatter %x problem with indirectly given long -> string formatter %x problem with indirectly given long _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 8 02:42:26 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 08 Mar 2008 01:42:26 -0000 Subject: [issue2257] typo in tutorial section 4.4 - final break statement is missing In-Reply-To: <1204936809.05.0.981645183837.issue2257@psf.upfronthosting.co.za> Message-ID: <1204940546.71.0.891411177708.issue2257@psf.upfronthosting.co.za> Changes by Raymond Hettinger: ---------- assignee: georg.brandl -> rhettinger nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 02:52:08 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 08 Mar 2008 01:52:08 -0000 Subject: [issue1741218] string formatter %x problem with indirectly given long Message-ID: <1204941128.01.0.0893608169411.issue1741218@psf.upfronthosting.co.za> Facundo Batista added the comment: Already fixed. Thanks Kenji for the report, Gabriel for the patch in the other issue, and Alexander for noticing this "duplicateness". ---------- resolution: -> duplicate status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 8 04:02:51 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 08 Mar 2008 03:02:51 -0000 Subject: [issue1733184] slice type is unhashable Message-ID: <1204945371.81.0.287230515887.issue1733184@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Guido, any thoughts? I'm +0 on making slices hashable -- no real harm from doing it -- not much benefit either. ---------- assignee: -> gvanrossum nosy: +gvanrossum _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 8 04:10:42 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 08 Mar 2008 03:10:42 -0000 Subject: [issue1733184] slice type is unhashable Message-ID: <1204945842.41.0.171298235728.issue1733184@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: In case I did not make my position clear in my previous post, I am -1 on this RFE. x[:] should mean slicing, not getitem. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 8 04:15:41 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Sat, 08 Mar 2008 03:15:41 -0000 Subject: [issue1733184] slice type is unhashable Message-ID: <1204946141.74.0.817295938227.issue1733184@psf.upfronthosting.co.za> Jean-Paul Calderone added the comment: > Slice objects are really meant to be internal structures and not passed around in the user's code. I don't know what they're "meant" to be, but they're certainly not internal. If you implement __getitem__, __setitem__, or __delitem__, then chances are Python is going to be passing slices to your code. That doesn't sound internal to me. Having hashable slices is nice. The repr() workaround has a major drawback in that it makes it difficult to use the extremely useful "indices" method of the slice type. ---------- nosy: +exarkun _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 8 05:32:07 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 08 Mar 2008 04:32:07 -0000 Subject: [issue2249] To document "assertTrue" in unittest In-Reply-To: <1204879165.33.0.589242853874.issue2249@psf.upfronthosting.co.za> Message-ID: <1204950727.22.0.542365779689.issue2249@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I prefer that this remain undocumented. The published API is already too fat. This would make it fatter without adding functionality. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 05:54:33 2008 From: report at bugs.python.org (Michael Urman) Date: Sat, 08 Mar 2008 04:54:33 -0000 Subject: [issue2256] Install failure of 2.6a1 on Windows XP without VS8 installed In-Reply-To: <1204932826.89.0.672189283054.issue2256@psf.upfronthosting.co.za> Message-ID: <1204952073.91.0.338141533905.issue2256@psf.upfronthosting.co.za> Michael Urman added the comment: The failure is signaled by the return code from the call to compileall.py: MSI (s) (FC:D0) [16:38:27:394]: Note: 1: 1722 2: CompilePyc 3: C:\Python26\python.exe 4: -Wi "C:\Python26\Lib\compileall.py" -f -x bad_coding|badsyntax|site-packages "C:\Python26\Lib" The install succeeds anyway because this is after InstallFinalize. That makes this a wart that will likely fail similarly on Vista under UAC (if not already handled by being conditioned out). This should probably be a scheduled between InstallFiles and InstallFinalize with inscript+noimpersonate. ---------- nosy: +michaelurman __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 06:29:59 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 08 Mar 2008 05:29:59 -0000 Subject: [issue1733184] slice type is unhashable Message-ID: <1204954199.29.0.560174419676.issue1733184@psf.upfronthosting.co.za> Guido van Rossum added the comment: Alexander nailed my motivation. Have the proponents for this change really thought through that making slices hashable means that henceforth this code will work? d = {} d[:] = [1, 2, 3] # surprise here print d # prints {slice(None, None, None): [1, 2, 3]} _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 8 10:38:41 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 08 Mar 2008 09:38:41 -0000 Subject: [issue2249] To document "assertTrue" in unittest In-Reply-To: <1204879165.33.0.589242853874.issue2249@psf.upfronthosting.co.za> Message-ID: <1204969121.53.0.439672317003.issue2249@psf.upfronthosting.co.za> Georg Brandl added the comment: I agree with Raymond. Having three names for a function is even more un-Zen than two. Also, I can't see wha'ts clearer in assertTrue in comparison with assert_. ---------- resolution: -> wont fix status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 10:47:22 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 08 Mar 2008 09:47:22 -0000 Subject: [issue2257] typo in tutorial section 4.4 - final break statement is missing In-Reply-To: <1204936809.05.0.981645183837.issue2257@psf.upfronthosting.co.za> Message-ID: <1204969642.8.0.0249858576318.issue2257@psf.upfronthosting.co.za> Georg Brandl added the comment: Sorry, but I don't see a mismatch between code and output. ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 10:54:18 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sat, 08 Mar 2008 09:54:18 -0000 Subject: [issue2255] Change Mandrake by Mandriva for platform.dist() In-Reply-To: <1204928063.97.0.960198270628.issue2255@psf.upfronthosting.co.za> Message-ID: <1204970058.36.0.59582059464.issue2255@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I think it's better to add the new name rather than replace the existing one. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 10:54:26 2008 From: report at bugs.python.org (Steve Purcell) Date: Sat, 08 Mar 2008 09:54:26 -0000 Subject: [issue2249] To document "assertTrue" in unittest In-Reply-To: <1204879165.33.0.589242853874.issue2249@psf.upfronthosting.co.za> Message-ID: <1204970066.07.0.0945007941335.issue2249@psf.upfronthosting.co.za> Steve Purcell added the comment: I could be convinced either way here, and Georg & Raymond always have excellent judgement. My personal inclination would probably be to add the documentation for assertTrue() and also assertFalse(), since their naming is symmetrical with that of assertEqual() etc. I think plenty of people are using those functions anyway, judging by emails I receive, and I'm not sure that leaving the function undocumented addresses the issue of the (admittedly) sprawling API. (I think Fred Drake put together the documentation originally; I don't recall any particular discussion about which aliases to document and which to leave out.) -Steve __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 10:54:37 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 08 Mar 2008 09:54:37 -0000 Subject: [issue2253] "continue" documentation internally inconsistent In-Reply-To: <1204913549.67.0.904198445457.issue2253@psf.upfronthosting.co.za> Message-ID: <1204970077.29.0.777356448017.issue2253@psf.upfronthosting.co.za> Georg Brandl added the comment: You're right, the footnote has to be removed. Fixed in r61303. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 10:56:43 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 08 Mar 2008 09:56:43 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204970202.93.0.568539325377.issue2240@psf.upfronthosting.co.za> Georg Brandl added the comment: Could you please put all changes in one complete patch? It's much easier to review that way. ---------- assignee: -> loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 10:57:33 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 08 Mar 2008 09:57:33 -0000 Subject: [issue1095784] exclude CVS conflict files in sdist command Message-ID: <1204970253.92.0.103812635715.issue1095784@psf.upfronthosting.co.za> Georg Brandl added the comment: Closing this as "won't fix" as per discussion in #1725737. (Quote: "It's the job of the packager to clean the directory before packaging.") ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 8 11:00:00 2008 From: report at bugs.python.org (=?utf-8?q?Nicolas_L=C3=A9cureuil?=) Date: Sat, 08 Mar 2008 10:00:00 -0000 Subject: [issue2255] Change Mandrake by Mandriva for platform.dist() In-Reply-To: <1204928063.97.0.960198270628.issue2255@psf.upfronthosting.co.za> Message-ID: <1204970400.66.0.511922263803.issue2255@psf.upfronthosting.co.za> Nicolas L?cureuil added the comment: is there a fix applied on mandriva python : --- (empty file) +++ cooker/python/current/SOURCES/python-2.5.1-detect-mandriva.patch Sat Mar 8 03:22:50 2008 @@ -0,0 +1,10 @@ +--- Lib/platform.py.old 2007-10-05 20:17:15.000000000 +0800 ++++ Lib/platform.py 2007-10-05 20:18:00.000000000 +0800 +@@ -225,7 +225,7 @@ + + def dist(distname='',version='',id='', + +- supported_dists=('SuSE', 'debian', 'fedora', 'redhat', 'mandrake')): ++ supported_dists=('SuSE', 'debian', 'fedora', 'mandriva', 'redhat', 'mandrake')): + + """ Tries to determine the name of the Linux OS distribution name. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 11:03:15 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sat, 08 Mar 2008 10:03:15 -0000 Subject: [issue2255] Change Mandrake by Mandriva for platform.dist() In-Reply-To: <1204928063.97.0.960198270628.issue2255@psf.upfronthosting.co.za> Message-ID: <1204970595.17.0.290072091519.issue2255@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Fixed in r61304. Backport candidate. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 11:03:21 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sat, 08 Mar 2008 10:03:21 -0000 Subject: [issue2255] Change Mandrake by Mandriva for platform.dist() In-Reply-To: <1204928063.97.0.960198270628.issue2255@psf.upfronthosting.co.za> Message-ID: <1204970601.29.0.676116819732.issue2255@psf.upfronthosting.co.za> Changes by Marc-Andre Lemburg: ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 11:05:33 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 08 Mar 2008 10:05:33 -0000 Subject: [issue1533486] long -> Py_ssize_t (C/API 1.2.1) Message-ID: <1204970733.69.0.857358200942.issue1533486@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r61305. ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 8 11:43:45 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 08 Mar 2008 10:43:45 -0000 Subject: [issue1995] localeconv() does not encode returned strings In-Reply-To: <1201889628.47.0.925128224389.issue1995@psf.upfronthosting.co.za> Message-ID: <1204973025.91.0.420004437711.issue1995@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I found now a way to fix this, by relying on wchar_t functions. It's fixed in r61306 ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 11:55:20 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 08 Mar 2008 10:55:20 -0000 Subject: [issue1618] locale.strxfrm can't handle non-ascii strings In-Reply-To: <1197582108.61.0.124909155583.issue1618@psf.upfronthosting.co.za> Message-ID: <1204973720.91.0.1881290409.issue1618@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I found a way to fix this, using wchar_t functions. Fixed in r61307. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 11:56:10 2008 From: report at bugs.python.org (Guilherme Polo) Date: Sat, 08 Mar 2008 10:56:10 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204973770.85.0.999894011331.issue2240@psf.upfronthosting.co.za> Guilherme Polo added the comment: Complete patch attached Added file: http://bugs.python.org/file9636/setitimer_getitimer.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 14:08:17 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Sat, 08 Mar 2008 13:08:17 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204981697.58.0.151932609259.issue2240@psf.upfronthosting.co.za> Ralf Schmitt added the comment: I'd like to also see this in 2.6. Should I update the patch (if it doesn't apply) and test? (I guess the signal module hasn't changed that much). __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 14:10:50 2008 From: report at bugs.python.org (Guilherme Polo) Date: Sat, 08 Mar 2008 13:10:50 -0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1204981850.23.0.358823496444.issue2240@psf.upfronthosting.co.za> Guilherme Polo added the comment: If you are going to backport it to 2.6, then the C wrapper should be adapted to match Python 2.x C coding style. If the other parts don't apply correctly, then you should update it aswell. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 14:57:57 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Sat, 08 Mar 2008 13:57:57 -0000 Subject: [issue1733184] slice type is unhashable Message-ID: <1204984677.51.0.0999557451416.issue1733184@psf.upfronthosting.co.za> Jean-Paul Calderone added the comment: I don't see the ability to use a slice as a dict key as particularly more surprising than the ability to use ints as dict keys. Someone who doesn't understand how dicts work can use either of these features to write broken programs. I have thought about that example and it's precisely the kind of thing I would like to work. The behavior is consistent with that of using any other immutable value as a key. I don't have a use case right now (and by admitting so may be dooming this change - but L. Peter Deutsch has one, I think) but there's no way I would ever benefit from the current behavior, whereas I _might_ be able to do something useful with the proposed behavior. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 8 15:12:11 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 08 Mar 2008 14:12:11 -0000 Subject: [issue1733184] slice type is unhashable Message-ID: <1204985531.9.0.190916833347.issue1733184@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Note that L[:] and L[:] = [] are well-known idioms for making a copy of a list and emptying the list respectively. (For dictionaries we have D.copy() and D.clear().) Someone looking at x[:] or x[:] = [] should immediately recognize a list copy or clear operation. Having to think of whether x may be a dictionary would make such code very confusing. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 8 15:02:13 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 08 Mar 2008 14:02:13 -0000 Subject: [issue1533486] long -> Py_ssize_t (C/API 1.2.1) Message-ID: <1204984932.94.0.40327469548.issue1533486@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Georg, did you miss the s/assuming/because/ part of my proposal? Python guarantees that sizeof(Py_ssize_t) == sizeof(size_t) == sizeof(void*). (See PEP 353.) "Assuming" is therefore misleading because it suggests that it may not be always true. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 8 16:21:54 2008 From: report at bugs.python.org (Brian White) Date: Sat, 08 Mar 2008 15:21:54 -0000 Subject: [issue2241] Additional Flag For Unit-Test Module: There Can Be Only One (Error) In-Reply-To: <1204734272.92.0.489101809074.issue2241@psf.upfronthosting.co.za> Message-ID: <1204989714.4.0.234411674776.issue2241@psf.upfronthosting.co.za> Brian White added the comment: I am somewhat new to mock objects. I'm coding up my first one now (in D) to simulate a "stream" for other objects I want to write. Even within a single module, I typically have many tests for the methods within that module. And since a module's methods make use of each other, there is again a case for the tests of the lower-level functions to be executed first. Anyway, this is something that works for me, but I understand that not everybody operates this way. All the best from this Canadian in Switzerland. :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 17:51:11 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 08 Mar 2008 16:51:11 -0000 Subject: [issue1106316] slightly easier way to debug from the exception handler Message-ID: <1204995071.19.0.972775418256.issue1106316@psf.upfronthosting.co.za> Facundo Batista added the comment: Added this functionality in r61312. ---------- resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 8 19:13:56 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 08 Mar 2008 18:13:56 -0000 Subject: [issue705836] struct.pack of floats in non-native endian order Message-ID: <1205000036.32.0.439353750597.issue705836@psf.upfronthosting.co.za> Mark Dickinson added the comment: Coming back to this, I think that it actually *is* clear what struct(">f", large_float) should do: it should raise OverflowError. This fits in well with the general philosophy that Python (at least tries to) follow for floating-point exceptions. The attached patch (705836_v2.patch) fixes this. All tests pass with this patch applied. I'll leave this around for a few days in case anyone wants to comment on it; then I plan to apply it to the trunk. ---------- keywords: +patch Added file: http://bugs.python.org/file9637/705836_v2.patch ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Mar 8 19:24:29 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 08 Mar 2008 18:24:29 -0000 Subject: [issue1733184] slice type is unhashable Message-ID: <1205000669.19.0.842363507702.issue1733184@psf.upfronthosting.co.za> Changes by Raymond Hettinger: ---------- resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 8 19:42:22 2008 From: report at bugs.python.org (Jim Kleckner) Date: Sat, 08 Mar 2008 18:42:22 -0000 Subject: [issue2256] Install failure of 2.6a1 on Windows XP without VS8 installed In-Reply-To: <1204932826.89.0.672189283054.issue2256@psf.upfronthosting.co.za> Message-ID: <1205001742.52.0.732968439434.issue2256@psf.upfronthosting.co.za> Jim Kleckner added the comment: I uninstalled and re-ran the install without the "compile all" selected. The install didn't report errors. running: python -c "import test.testall" results in a traceback with the message: import _socket ImportError: DLL load failed: The system could not find the file specified. What sorts of things should I probe into? __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 8 22:05:32 2008 From: report at bugs.python.org (Jean Brouwers) Date: Sat, 08 Mar 2008 21:05:32 -0000 Subject: [issue2218] Enhanced hotshot profiler with high-resolution timer In-Reply-To: <1204501511.28.0.993763550383.issue2218@psf.upfronthosting.co.za> Message-ID: <1205010332.17.0.439675218391.issue2218@psf.upfronthosting.co.za> Jean Brouwers added the comment: There are 7 other, potentially serious issues in the original _hotshot.c file. All those are being fixed for the next version of the enhanced hotshot files. The 7 issues are: 1) functions flush_data and do_stop may create an infinite recursion on line 567. 2) The pack_string and pack_add_info functions do not check for string lengths exceeding BUFFERSIZE and may corrupt memory in that case. 3) In line 1182, linetimings should be frametimngs: {"frametimings", T_LONG, offsetof(ProfilerObject, linetimings), READONLY}, 4) Coverage members frametimings, linetimings and lineevents are set on line 1562 ff. after different values may have been written into the log file header by function write_header on lines 1440 ff. 5) The coverage__doc__ on line 1546 is incomplete. 6) At several places, errors are detected but not reported and not sets. 7) An int value is passed where a long is specified or expected. T_LONG should be T_INT on lines 1182-1184 and there are several calls to PyInt_FromLong with an int argument on line 487 ff. and other places. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 9 00:19:19 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 08 Mar 2008 23:19:19 -0000 Subject: [issue812750] OSA support for properties broken Message-ID: <1205018359.53.0.706977482217.issue812750@psf.upfronthosting.co.za> Mark Dickinson added the comment: The docs say that development for the MacPython OSA modules has stopped, and that a replacement is expected for Python 2.5. Can this issue now be closed, or at least have its priority downgraded? ---------- nosy: +marketdickinson ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Mar 9 06:01:27 2008 From: report at bugs.python.org (Paul Molodowitch) Date: Sun, 09 Mar 2008 05:01:27 -0000 Subject: [issue1504333] sgmllib should allow angle brackets in quoted values Message-ID: <1205038886.94.0.906934243592.issue1504333@psf.upfronthosting.co.za> Paul Molodowitch added the comment: Patch for sgmllib.py (and test_sgmllib.py) Correctly parses quoted attribute - allowing for brackets, newlines, etc within attributes - implemented by altering the loop which finds attributes within parse_starttag so it checks for open-ended quotes, and makes sure any closing brackets it finds are not within quotes In test_sgmllib, added the test case from the original patch, as well as re-enabling two other test cases, which both work now ---------- keywords: +patch nosy: +barnabas79 Added file: http://bugs.python.org/file9638/sgmllib_2008-03-08.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 9 09:37:01 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 09 Mar 2008 08:37:01 +0000 Subject: [issue2119] Empty test In-Reply-To: <1205051821.68.0.217165084121.issue2119@psf.upfronthosting.co.za> Message-ID: <1205051821.68.0.217165084121.issue2119@psf.upfronthosting.co.za> New submission from Martin v. L?wis : Follow-up __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 9 11:10:16 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Sun, 09 Mar 2008 10:10:16 +0000 Subject: [issue2249] To document "assertTrue" in unittest In-Reply-To: <1204879165.33.0.589242853874.issue2249@psf.upfronthosting.co.za> Message-ID: <1205057416.04.0.871296770131.issue2249@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I noted the issue while working in bsddb3 module. If failed in python2.3 because some tests were using "assertTrue". I had to dig where that method came from (time lost!) and found that a) it was added in python 2.4 and b) it is not documented. Since "assertTrue" use is "in the wild", being undocumented is a inconvenience. Moreover, I think "assertTrue" is far more intuitive and cleaner than "assert_" or "failUnless". A personal impression, of course. Symmetric with "assertEqual" and so, would be nice. I won't insist, in any case :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 9 11:55:18 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 09 Mar 2008 10:55:18 +0000 Subject: [issue2258] Update command line docs for issue 1739468 In-Reply-To: <1205060118.8.0.321135862814.issue2258@psf.upfronthosting.co.za> Message-ID: <1205060118.8.0.321135862814.issue2258@psf.upfronthosting.co.za> New submission from Nick Coghlan : The ability to execute zip files and directories containing a __main__.py file needs to be covered in the documentation of the command line options. ---------- assignee: ncoghlan components: Documentation keywords: easy messages: 63412 nosy: ncoghlan priority: normal severity: normal status: open title: Update command line docs for issue 1739468 versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 9 13:15:06 2008 From: report at bugs.python.org (Armin Rigo) Date: Sun, 09 Mar 2008 12:15:06 +0000 Subject: [issue1617161] Instance methods compare equal when their self's are equal Message-ID: <1205064906.5.0.843722393593.issue1617161@psf.upfronthosting.co.za> Armin Rigo added the comment: My mistake, you are right. I forgot about one of the many types that CPython uses internally for built-in methods. Indeed: >>> [].index == [].index False >>> [].__add__ == [].__add__ True I can fix this so that the answer is True in all cases; alternatively, considering Frank Niessink's original issue, we could bring this discussion to python-dev and decide what the correct behavior should be and implement it consistently for all method types. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 9 14:13:50 2008 From: report at bugs.python.org (Frank Niessink) Date: Sun, 09 Mar 2008 13:13:50 +0000 Subject: [issue1617161] Instance methods compare equal when their self's are equal Message-ID: <1205068430.15.0.143842617276.issue1617161@psf.upfronthosting.co.za> Frank Niessink added the comment: Just to reiterate the original bug report: the issue (for me) is that currently (python 2.5): >>> [].__add__ == [].__add__ True >>> [].__add__ == [1].__add__ False Or, using a non-builtin class: >>> class C(object): ... def __eq__(self, other): ... return False ... def foo(self): ... pass ... >>> C().foo == C().foo False >>> class C(object): ... def __eq__(self, other): ... return True ... def foo(self): ... pass ... >>> C().foo == C().foo True I think it makes little sense that the equality test for the instance methods takes the equality of the instances into account. Imho, this behaviour is inconsistent with the principle of no surprises. The correct behaviour (again imho of course) is that instance methods only compare equal to the same instance method of the same instance, where 'same instance' is based on 'is' not on '=='. Cheers, Frank _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 9 14:14:31 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 09 Mar 2008 13:14:31 +0000 Subject: [issue1617161] Instance methods compare equal when their self's are equal Message-ID: <1205068471.13.0.0678668325029.issue1617161@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Armin, I think this should be discussed on python-dev. I don't understand your motivation for comparing methods of distinct but equal objects as equal. The callback argument on the other hand, is compelling. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 9 14:45:55 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 09 Mar 2008 13:45:55 +0000 Subject: [issue2249] To document "assertTrue" in unittest In-Reply-To: <1204879165.33.0.589242853874.issue2249@psf.upfronthosting.co.za> Message-ID: <1205070355.55.0.560032153411.issue2249@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: FWIW, grepping through Lib/test reveals the following statistics: assertFalse: 83 assertTrue: 97 failUnless: 684 assert_: 1977 Not having assertTrue/assertFalse methods in the Library Reference does not discourage people from using them given that they show up without any warning in help(). (Moreover, assertTrue shows up before assert_.) I would say it should be documented. After all it would only take a two line patch (see attached). (I agree with OP that assertTrue is clearer than assert_ . Although I know that '_' is only there to avoid a conflict with the assert keyword, assert_ always stand out as different from the other TestCase methods.) ---------- keywords: +patch nosy: +belopolsky Added file: http://bugs.python.org/file9639/doc-unittest.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 9 15:07:11 2008 From: report at bugs.python.org (Steve Purcell) Date: Sun, 09 Mar 2008 14:07:11 +0000 Subject: [issue2249] To document "assertTrue" in unittest In-Reply-To: <1204879165.33.0.589242853874.issue2249@psf.upfronthosting.co.za> Message-ID: <1205071631.23.0.960651387952.issue2249@psf.upfronthosting.co.za> Steve Purcell added the comment: +1 for applying Alexander's patch, then; I'll leave the decision to a current committer. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 9 15:26:34 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 09 Mar 2008 14:26:34 +0000 Subject: [issue2249] To document "assertTrue" in unittest In-Reply-To: <1204879165.33.0.589242853874.issue2249@psf.upfronthosting.co.za> Message-ID: <1205072794.96.0.0331073648535.issue2249@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Just to make the story complete, it should be mentioned that assertFalse/True were added because these are the names used by JUnit: ------------------------------------------------------------------------ r34209 | purcell | 2003-09-22 07:08:12 -0400 (Mon, 22 Sep 2003) | 11 lines .. - New assertTrue and assertFalse aliases for comfort of JUnit users __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 9 16:06:51 2008 From: report at bugs.python.org (Oki Mikito) Date: Sun, 09 Mar 2008 15:06:51 +0000 Subject: [issue2259] Poor support other than 44.1khz, 16bit audio files? In-Reply-To: <1205075207.56.0.203597492215.issue2259@psf.upfronthosting.co.za> Message-ID: <1205075207.56.0.203597492215.issue2259@psf.upfronthosting.co.za> New submission from Oki Mikito : It appears that aifc, as well as wave, does not support audio files other than 44100 hz 16-bit format. -- >>> f = aifc.open('Track 06') Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/aifc.py", line 928, in open return Aifc_read(f) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/aifc.py", line 341, in __init__ self.initfp(f) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/aifc.py", line 321, in initfp chunk.skip() File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/chunk.py", line 158, in skip self.file.seek(n, 1) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/chunk.py", line 111, in seek raise RuntimeError RuntimeError -- Could it be that the 'Chunk' class in chunk module may be returning improper values...? In any case, aifc refuses to open a 24bit 44100hz audio file. Does anyone have insights on this? ---------- components: Library (Lib) messages: 63419 nosy: loki_dePlume severity: major status: open title: Poor support other than 44.1khz, 16bit audio files? type: feature request versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 9 16:11:53 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 09 Mar 2008 15:11:53 +0000 Subject: [issue2249] To document "assertTrue" in unittest In-Reply-To: <1204879165.33.0.589242853874.issue2249@psf.upfronthosting.co.za> Message-ID: <1205075513.92.0.348861911077.issue2249@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, I give in :) Committed as r61329. ---------- resolution: wont fix -> fixed status: pending -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 9 16:20:47 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Sun, 09 Mar 2008 15:20:47 +0000 Subject: [issue1617161] Instance methods compare equal when their self's are equal Message-ID: <1205076047.83.0.317008008832.issue1617161@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: Since I'm not on python-dev, I'll mention here that the new behavior makes no sense to me at all. Which is best highlighted by Frank in msg63414. ---------- nosy: +_doublep _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 9 16:36:00 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Sun, 09 Mar 2008 15:36:00 +0000 Subject: [issue2260] conditional jump to a POP_TOP optimization In-Reply-To: <1205076960.06.0.224700727301.issue2260@psf.upfronthosting.co.za> Message-ID: <1205076960.06.0.224700727301.issue2260@psf.upfronthosting.co.za> New submission from Paul Pogonyshev : This optimization targets a common case of functions like this: def foo(a, b): if a: if b: return 'true' Before the optimization: 6 0 LOAD_FAST 0 (a) 3 JUMP_IF_FALSE 16 (to 22) 6 POP_TOP 7 7 LOAD_FAST 1 (b) 10 JUMP_IF_FALSE 5 (to 18) 13 POP_TOP 8 14 LOAD_CONST 1 ('true') 17 RETURN_VALUE >> 18 POP_TOP 19 JUMP_FORWARD 1 (to 23) >> 22 POP_TOP >> 23 LOAD_CONST 0 (None) 26 RETURN_VALUE After: 6 0 LOAD_FAST 0 (a) 3 JUMP_IF_FALSE 16 (to 22) 6 POP_TOP 7 7 LOAD_FAST 1 (b) 10 JUMP_IF_FALSE 9 (to 22) 13 POP_TOP 8 14 LOAD_CONST 1 ('true') 17 RETURN_VALUE 18 POP_TOP 19 JUMP_FORWARD 1 (to 23) >> 22 POP_TOP >> 23 LOAD_CONST 0 (None) 26 RETURN_VALUE Note that size of bytecode doesn't become smaller, however one execution branch (jump from offset 10) becomes shorter by one JUMP_FORWARD. Additionally, two commands at offset 18 become unreachable. However, they will not be removed by the patch in issue1394 currently, because there is a basic-block change at 18, where JUMP_IF_FALSE previously had its target. If we want unreachable code be removed in such cases, we need to make peepholer make two passes with recomputing blocks[] in between. This would enable more optimizations. ---------- components: Interpreter Core files: jump-to-pop-optimization.diff keywords: patch messages: 63422 nosy: _doublep severity: minor status: open title: conditional jump to a POP_TOP optimization Added file: http://bugs.python.org/file9640/jump-to-pop-optimization.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 9 16:36:40 2008 From: report at bugs.python.org (Paul Molodowitch) Date: Sun, 09 Mar 2008 15:36:40 +0000 Subject: [issue2261] Warning: could not send message for past 4 hours In-Reply-To: <200803091056.m29AshJ3018916@gourmet.spamgourmet.com> Message-ID: <200803091056.m29AshJ3018916@gourmet.spamgourmet.com> New submission from Paul Molodowitch : ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Sun, 9 Mar 2008 05:01:30 GMT from jqh1 at localhost ----- Transcript of session follows ----- 451 spamgourmet.com: Name server timeout 451 spamgourmet.com: Name server timeout 451 gmail.com: Name server timeout Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old 451 spamgourmet.com: Name server timeout ---------- files: unnamed, unnamed messages: 63423 nosy: barnabas79 severity: normal status: open title: Warning: could not send message for past 4 hours Added file: http://bugs.python.org/file9641/unnamed Added file: http://bugs.python.org/file9642/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded message was scrubbed... From: unknown sender Subject: no subject Date: no date Size: 3013 Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080309/71519144/attachment.eml From report at bugs.python.org Sun Mar 9 16:39:37 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Sun, 09 Mar 2008 15:39:37 +0000 Subject: [issue2260] conditional jump to a POP_TOP optimization In-Reply-To: <1205076960.06.0.224700727301.issue2260@psf.upfronthosting.co.za> Message-ID: <1205077177.88.0.021930517142.issue2260@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: Also, this is the reason for while() in the patch. Consider this function: def bar(a, b, c): if a: if b: if c: return 'true' Before the patch: 11 0 LOAD_FAST 0 (a) 3 JUMP_IF_FALSE 27 (to 33) 6 POP_TOP 12 7 LOAD_FAST 1 (b) 10 JUMP_IF_FALSE 16 (to 29) 13 POP_TOP 13 14 LOAD_FAST 2 (c) 17 JUMP_IF_FALSE 5 (to 25) 20 POP_TOP 14 21 LOAD_CONST 1 ('true') 24 RETURN_VALUE >> 25 POP_TOP 26 JUMP_ABSOLUTE 34 >> 29 POP_TOP 30 JUMP_FORWARD 1 (to 34) >> 33 POP_TOP >> 34 LOAD_CONST 0 (None) 37 RETURN_VALUE After: 11 0 LOAD_FAST 0 (a) 3 JUMP_IF_FALSE 27 (to 33) 6 POP_TOP 12 7 LOAD_FAST 1 (b) 10 JUMP_IF_FALSE 20 (to 33) 13 POP_TOP 13 14 LOAD_FAST 2 (c) 17 JUMP_IF_FALSE 13 (to 33) 20 POP_TOP 14 21 LOAD_CONST 1 ('true') 24 RETURN_VALUE 25 POP_TOP 26 JUMP_ABSOLUTE 34 29 POP_TOP 30 JUMP_FORWARD 1 (to 34) >> 33 POP_TOP >> 34 LOAD_CONST 0 (None) 37 RETURN_VALUE Without the while(), target for jump at offset 17 wouldn't be optimized, because "jump to unconditional jump" optimization hasn't been done yet: it is farther in the code. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 9 18:03:41 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sun, 09 Mar 2008 17:03:41 +0000 Subject: [issue2179] with should be as fast as try/finally In-Reply-To: <1203894641.18.0.492382147443.issue2179@psf.upfronthosting.co.za> Message-ID: <1205082221.37.0.755501851736.issue2179@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Thanks Nick and Amaury! Amaury, what times are you seeing? It could be a just-gcc speedup, but I wouldn't have thought so since the patch eliminates 2 times around the eval loop. It could be that the overhead of WITH_CLEANUP is high enough to drown out those iterations. You had mentioned optimizing the PyObject_CallFunctionObjArgs() call before. If you're still seeing with significantly slower than try, that's probably the right place to look. Here are my current timings. To avoid the lock issues, I wrote simple_cm.py containing: class CM(object): def __enter__(self): pass def __exit__(self, *args): pass $ ./python.exe -m timeit -s 'import simple_cm; cm = simple_cm.CM()' 'with cm: pass' 1000000 loops, best of 3: 0.885 usec per loop $ ./python.exe -m timeit -s 'import simple_cm; cm = simple_cm.CM()' 'cm.__enter__()' 'try: pass' 'finally: cm.__exit__()' 1000000 loops, best of 3: 0.858 usec per loop If __exit__ doesn't contain *args (making it not a context manager), the try/finally time goes down to: $ ./python.exe -m timeit -s 'import simple_cm; cm = simple_cm.CM()' 'cm.__enter__()' 'try: pass' 'finally: cm.__exit__()' 1000000 loops, best of 3: 0.619 usec per loop I think in theory, with could be slightly faster than finally with the same argument list, but it's pretty close now. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 9 18:38:52 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sun, 09 Mar 2008 17:38:52 +0000 Subject: [issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za> Message-ID: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za> New submission from Jeffrey Yasskin : I'm using Apple's gcc-4.0.1 on a 2.33GHz Intel Core 2 Duo to test this. Measurements from other compilers or other chips would be cool. Specifically, this patch: 1) Moves the declarations of most of the local variables inside the for(;;) loop. That shortens their lifetimes so that the compiler can skip spilling them to memory in some cases. Pushing them further down into the individual case statements didn't change the generated assembly in most cases, although there are probably a few opcodes where it would. 2) Eliminates the initialization of w, and fixes the "possibly used uninitialized" warning by changing how the PRINT opcodes initialize it from stream. That lets my compiler avoid using its stack entry most of the time. 3) In two hot opcodes, LOAD_FAST and LOAD_CONST, changes the 'x' to a 'w'. 'x' is always written to memory because it's used for error detection, while 'w' can stay on the stack. 4) Changes --_Py_Ticker in the periodic things check to _Py_Ticker--. Because _Py_Ticker is volatile, predecrement (at least on my compiler) needs 3 memory accesses, while postdecrement gets away with 2. Together, these changes are worth about 3% on pybench on my machine. ---------- components: Interpreter Core files: elim_mem_refs.patch keywords: patch, patch messages: 63426 nosy: jyasskin severity: normal status: open title: Helping the compiler avoid memory references in PyEval_EvalFrameEx type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9643/elim_mem_refs.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 9 19:45:43 2008 From: report at bugs.python.org (Neal Norwitz) Date: Sun, 09 Mar 2008 18:45:43 +0000 Subject: [issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za> Message-ID: <1205088343.92.0.318128689699.issue2262@psf.upfronthosting.co.za> Neal Norwitz added the comment: I bet with just a little more work, you could get rid of t and stream. t is only used for a single set of opcodes (STORE_SLICE+n). stream is only used for the PRINT opcodes. The code in print could be moved to a function which might allow the compiler to do a better job. I'll benchmark this later on amd64 and amd x86 linux boxes. Maybe mac ppc g4 if I'm adventurous. :-) ---------- nosy: +nnorwitz __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 9 19:47:41 2008 From: report at bugs.python.org (Neal Norwitz) Date: Sun, 09 Mar 2008 18:47:41 +0000 Subject: [issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za> Message-ID: <1205088461.5.0.93098643829.issue2262@psf.upfronthosting.co.za> Neal Norwitz added the comment: Can't next_instr and stack_pointer move inside the for loop too? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 9 19:51:45 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 09 Mar 2008 18:51:45 +0000 Subject: [issue2261] Warning: could not send message for past 4 hours In-Reply-To: <200803091056.m29AshJ3018916@gourmet.spamgourmet.com> Message-ID: <1205088705.42.0.84433787248.issue2261@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 9 23:45:22 2008 From: report at bugs.python.org (Jean Brouwers) Date: Sun, 09 Mar 2008 22:45:22 +0000 Subject: [issue2218] Enhanced hotshot profiler with high-resolution timer In-Reply-To: <1204501511.28.0.993763550383.issue2218@psf.upfronthosting.co.za> Message-ID: <1205102722.58.0.982702624927.issue2218@psf.upfronthosting.co.za> Jean Brouwers added the comment: Attached is the latest, hopefully final version of the enhanced and improved hotshot profiler files. In addition to fixes for the 7 issues mentioned previously, type Py_ssize_t is used instead of size_t. Use this verion 4 and discard all previous ones. Please review this code in file _hotshot.c and let me know of any rule or guideline violations. I am more than happy to correct any mistakes. Added file: http://bugs.python.org/file9644/hires_hotshot4.tgz __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 01:17:12 2008 From: report at bugs.python.org (Eric Smith) Date: Mon, 10 Mar 2008 00:17:12 +0000 Subject: [issue1600] str.format() produces different output on different platforms (Py30a2) In-Reply-To: <1197450243.14.0.729685827203.issue1600@psf.upfronthosting.co.za> Message-ID: <1205108232.2.0.992038056437.issue1600@psf.upfronthosting.co.za> Eric Smith added the comment: Issue closed with commit r60909. Fixed as suggested by Mark Dickinson: "The exponent always contains at least two digits, and only as many more digits as necessary to represent the exponent." ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 02:23:31 2008 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 10 Mar 2008 01:23:31 +0000 Subject: [issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za> Message-ID: <1205112211.2.0.710100891526.issue2262@psf.upfronthosting.co.za> Skip Montanaro added the comment: I've yet to run pybench, but I came get these warnings from the compiler after applying the patch: ../Python/ceval.c: In function 'PyEval_EvalFrameEx': ../Python/ceval.c:772: warning: 'x' may be used uninitialized in this function ../Python/ceval.c:770: warning: 'err' may be used uninitialized in this function Platform is Mac OS X 10.5.2 MacBook Pro, gcc version 4.0.1 (Apple Inc. build 5465) ---------- nosy: +skip.montanaro __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 02:43:51 2008 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 10 Mar 2008 01:43:51 +0000 Subject: [issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za> Message-ID: <1205113431.0.0.088606110281.issue2262@psf.upfronthosting.co.za> Skip Montanaro added the comment: Pybench doesn't show much difference for me, about 0.1% better on minimum times. A few tests are quite a bit worse (> 10%) with the patch (Recursion, SimpleFloatArithmetic, StringPredicates, TryFinally). A few are quite a bit better (CompareFloatsIntegers, CompareIntegers, DictWithFloatKeys). __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 03:18:59 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 10 Mar 2008 02:18:59 +0000 Subject: [issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString. In-Reply-To: <1201473895.18.0.771876708371.issue1950@psf.upfronthosting.co.za> Message-ID: <1205115539.28.0.731341554426.issue1950@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Thanks for the review! > Your description of the patch is a bit misleading. As far as I can > tell only the first chunk (Python/import.c changes) addresses a > potential buffer overflow. Yes, you are right. It seems only the bug in import.c could easily be exploited. > 1. It will really help if you produce a test case that crashes the > interpretor. I am sure that will get noticed. % cat pkg/__init__.py __package__ = "\U000c9c9c9" * 900 from . import f % ./python Python 3.0a3+ (py3k:61164, Mar 1 2008, 19:55:42) >>> import pkg *** stack smashing detected ***: ./python terminated [1] 9503 abort (core dumped) ./python > 2. If any of buffer overflows apply to the current production > versions (2.4 or 2.5) or even the alpha release (2.6a1), it would > make sense to backport it to the trunk. I don't think the trunk is affected in any way by the issues mentioned here. > The existing __doc__ processing code is correct. Proposed code may be > marginally faster, but will allow docstrings with embedded null > characters, which may or may not be desirable (and may break other code > that uses tp_doc) Good call! I will check out if null-characters may pose a problem for tp_doc and update the patch consequently. > I don't think a repr of a python object can contain embedded null > characters, but even if that were the case, the patched code would not > support it because the resulting buffer is returned with > PyUnicode_FromString(buf). Oh, that is true. I will remove that part from the patch, then. > Modules/datetimemodule.c > > Existing code compensates for an error in initial estimate of totalnew > when it checks for overflow, but the proposed change will make code more > efficient. Right again. > Modules/zipimport.c [...] > Modules/timemodule.c [...] > Modules/parsermodule.c [...] I need to check again the code for these three modules, before commenting. I will clean up the patch with your recommendation and post it again. Thanks for taking the time to review my patch. It's greatly appreciated. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 06:51:46 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 10 Mar 2008 05:51:46 +0000 Subject: [issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za> Message-ID: <1205128306.29.0.141018852356.issue2262@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Neal, t and stream aren't likely to have much effect since they're used so little. next_instr and stack_pointer are used to communicate between loops, so they can't move inside. I eagerly await your benchmark runs. :) Skip, I managed to reproduce the warnings with gcc-4.2.1, and while they're wrong, I see why they're happening. The if (throwflag) block skips to on_error, which misses the initializations of x and err. The right way to fix it is either to eliminate the error-reporting behavior of x and err or to extract on_error into a function, but for this patch I would probably just keep x and err out of the loop. Your numbers made me look closer at my results for individual tests, and I'm now confused about how reliable pybench is. My gcc-4.0 was build #5367 on OS X 10.4.11, and MacPorts' gcc-4.2.1 (with a necessary configure.in tweak) still shows a 1-2% gain overall. But contrary to your numbers, it gives me a 10% speedup in Recursion and a 1% slowdown in CompareFloatsIntegers. My big losers are SimpleListManipulation with an 18% loss on 4.2 and CompareInternedStrings with a 20% loss on 4.0, but those are both small winners (~5%) on the opposite compiler! I wouldn't be surprised if the overall numbers were different between even slightly different machines and compilers, but I'm really surprised to see the same tests affected in opposite directions. Is that common with pybench and compiler changes? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 08:39:24 2008 From: report at bugs.python.org (Just van Rossum) Date: Mon, 10 Mar 2008 07:39:24 +0000 Subject: [issue2263] struct.pack() + numpy int raises SystemError In-Reply-To: <1205134764.8.0.415620235375.issue2263@psf.upfronthosting.co.za> Message-ID: <1205134764.8.0.415620235375.issue2263@psf.upfronthosting.co.za> New submission from Just van Rossum : struct.pack() raises SystemError when fed a numpy integer in some cases. The following was run on MacOSX 10.4, little endian (I can only reproduce the error if I specify big endian for the struct format). Not sure if this could be a numpy bug. Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import struct >>> import numpy >>> i = numpy.int16(1) >>> struct.pack(">B", i) __main__:1: DeprecationWarning: struct integer overflow masking is deprecated Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/struct. py", line 63, in pack return o.pack(*args) SystemError: /Users/ronald/r252/Objects/longobject.c:322: bad argument to internal function >>> struct.pack(">H", i) Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/struct. py", line 63, in pack return o.pack(*args) SystemError: /Users/ronald/r252/Objects/longobject.c:322: bad argument to internal function >>> struct.pack(">h", i) '\x00\x01' >>> struct.pack(">b", i) '\x01' >>> struct.pack("B", i) '\x01' >>> struct.pack("h", i) '\x01\x00' >>> numpy.__version__ '1.0.4' >>> ---------- components: Library (Lib) messages: 63435 nosy: jvr severity: normal status: open title: struct.pack() + numpy int raises SystemError type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 09:19:24 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 10 Mar 2008 08:19:24 +0000 Subject: [issue2122] mmap.flush does not check for errors on windows In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za> Message-ID: <1205137164.78.0.083981716581.issue2122@psf.upfronthosting.co.za> Ralf Schmitt added the comment: attached is a patch. I hope it is ok to change the semantics a bit. They were very strange: - on unix it raises an exception on errors. otherwise it always returns 0. - on windows it returns non-zero on success, and returns zero on errors. Now, flush returns None or raises an Exception. Added file: http://bugs.python.org/file9645/mmap-flush.txt __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 10:00:55 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 10 Mar 2008 09:00:55 +0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1205139655.86.0.165450071545.issue2240@psf.upfronthosting.co.za> Ralf Schmitt added the comment: Okay, the patch applies just fine (besides configure, which must be regenerated). Running the tests however consumes 3 gb of memory. The range functions must be changed to xrange on trunk. I've also changed the docs a bit ("new in 2.6"). I didn't change anything related to coding standards (is this an issue with tabs vs spaces?). all tests in test_signal work with a patched revision 61332 of trunk, on a 64 bit linux. Added file: http://bugs.python.org/file9646/trunk-itimer.txt __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 10:02:08 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 10 Mar 2008 09:02:08 +0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1205139728.11.0.571521988445.issue2240@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 12:05:24 2008 From: report at bugs.python.org (Eric Smith) Date: Mon, 10 Mar 2008 11:05:24 +0000 Subject: [issue2264] empty specifier for float.__format__ does not always print at least one decimal digit In-Reply-To: <1205147124.28.0.679572132371.issue2264@psf.upfronthosting.co.za> Message-ID: <1205147124.28.0.679572132371.issue2264@psf.upfronthosting.co.za> New submission from Eric Smith : PEP 3101 specifies that the empty format presentation type for float will always print at least one digit after the decimal point, but it does not do that if the number is output with an exponent: works: >>> format(3.0, '') '3.0' fails: >>> format(3e200, '') '3e+200' As currently implemented, the code just maps the empty format specifier to 'g', and does not add the additional behavior specfied in the PEP. ---------- assignee: eric.smith components: Interpreter Core messages: 63438 nosy: eric.smith priority: normal severity: normal status: open title: empty specifier for float.__format__ does not always print at least one decimal digit versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 13:40:10 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 10 Mar 2008 12:40:10 +0000 Subject: [issue1751245] Popen pipe file descriptor leak on OSError in init Message-ID: <1205152810.17.0.33536728543.issue1751245@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir type: -> resource usage _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 10 13:44:54 2008 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 10 Mar 2008 12:44:54 +0000 Subject: [issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx In-Reply-To: <1205128306.29.0.141018852356.issue2262@psf.upfronthosting.co.za> Message-ID: <18389.10154.552229.847406@montanaro-dyndns-org.local> Skip Montanaro added the comment: Jeffrey> ... but I'm really surprised to see the same tests affected in Jeffrey> opposite directions. Is that common with pybench and compiler Jeffrey> changes? I've no idea. Marc-Andr? Lemburg would be the person with the most insight into pybench behavior I think. Skip __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 13:55:24 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Mon, 10 Mar 2008 12:55:24 +0000 Subject: [issue1475] test_popen fails when the directory contains a space In-Reply-To: <1195544172.34.0.734753003895.issue1475@psf.upfronthosting.co.za> Message-ID: <1205153723.94.0.182671895152.issue1475@psf.upfronthosting.co.za> Joseph Armbruster added the comment: Should this issue be linked to 1559298? It appears to be the same issue but was opened up earlier and is referencing a different version. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 14:00:50 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Mon, 10 Mar 2008 13:00:50 +0000 Subject: [issue1451466] reading very large files Message-ID: <1205154050.68.0.144644065701.issue1451466@psf.upfronthosting.co.za> Joseph Armbruster added the comment: Note: If this issue is related to 1672853, I ran through the test code provided in the issue recently and it appeared to pass for both the trunk and 2.5 maint. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 10 14:55:37 2008 From: report at bugs.python.org (Kazuyoshi Furutaka) Date: Mon, 10 Mar 2008 13:55:37 +0000 Subject: [issue2265] A line in the second example of "7.3.5 Examples" in "Python Library Reference" seems to be incorrect. In-Reply-To: <1205157337.33.0.156583580671.issue2265@psf.upfronthosting.co.za> Message-ID: <1205157337.33.0.156583580671.issue2265@psf.upfronthosting.co.za> New submission from Kazuyoshi Furutaka : The line destination.add(MHMessage(message)) should read destination.add(mailbox.MHMessage(message)) ---------- assignee: georg.brandl components: Documentation messages: 63442 nosy: furutaka, georg.brandl severity: minor status: open title: A line in the second example of "7.3.5 Examples" in "Python Library Reference" seems to be incorrect. versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 15:40:51 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 10 Mar 2008 14:40:51 +0000 Subject: [issue2128] sys.argv is wrong for unicode strings In-Reply-To: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za> Message-ID: <1205160051.67.0.925199534265.issue2128@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Here is a patch that redoes the entire argv handling, in terms of wchar_t. As a side effect, it also changes the sys.path handling to use wchar_t. ---------- keywords: +patch Added file: http://bugs.python.org/file9647/wchar.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 16:46:15 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 10 Mar 2008 15:46:15 +0000 Subject: [issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za> Message-ID: <1205163975.6.0.581702860205.issue2262@psf.upfronthosting.co.za> Changes by Jeffrey Yasskin : Added file: http://bugs.python.org/file9648/elim_mem_refs.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 16:49:47 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 10 Mar 2008 15:49:47 +0000 Subject: [issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za> Message-ID: <1205164187.46.0.14137665096.issue2262@psf.upfronthosting.co.za> Changes by Jeffrey Yasskin : Removed file: http://bugs.python.org/file9648/elim_mem_refs.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 16:49:32 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 10 Mar 2008 15:49:32 +0000 Subject: [issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za> Message-ID: <1205164172.42.0.862118928178.issue2262@psf.upfronthosting.co.za> Changes by Jeffrey Yasskin : Added file: http://bugs.python.org/file9649/elim_mem_refs.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 17:35:58 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Mon, 10 Mar 2008 16:35:58 +0000 Subject: [issue1275] bsddb closing a DB object before all DBCursors using it are closed crashes In-Reply-To: <1192216802.58.0.956972286502.issue1275@psf.upfronthosting.co.za> Message-ID: <1205166958.46.0.286525670245.issue1275@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: This issue is solved in pybsddb 4.6.1, available in pypi. Python bsddb3 module must be updated and this issue closed as "fixed". ---------- nosy: +jcea __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 17:45:05 2008 From: report at bugs.python.org (Yinon Ehrlich) Date: Mon, 10 Mar 2008 16:45:05 +0000 Subject: [issue2266] Missing documentation about old/new-style classes In-Reply-To: <1205167505.81.0.00833692461216.issue2266@psf.upfronthosting.co.za> Message-ID: <1205167505.81.0.00833692461216.issue2266@psf.upfronthosting.co.za> New submission from Yinon Ehrlich : http://docs.python.org/tut/node11.html talks about old/new style classes. But there is no any explanation what it is. The same for http://docs.python.org/ref/node33.html My suggestion: refer to http://wiki.python.org/moin/NewClassVsClassicClass ---------- assignee: georg.brandl components: Documentation messages: 63445 nosy: Yinon, georg.brandl severity: minor status: open title: Missing documentation about old/new-style classes versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 17:45:45 2008 From: report at bugs.python.org (Yinon Ehrlich) Date: Mon, 10 Mar 2008 16:45:45 +0000 Subject: [issue2266] Missing documentation about old/new-style classes In-Reply-To: <1205167505.81.0.00833692461216.issue2266@psf.upfronthosting.co.za> Message-ID: <1205167545.94.0.929442128864.issue2266@psf.upfronthosting.co.za> Changes by Yinon Ehrlich : __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 18:25:27 2008 From: report at bugs.python.org (jan matejek) Date: Mon, 10 Mar 2008 17:25:27 +0000 Subject: [issue1621] Do not assume signed integer overflow behavior In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za> Message-ID: <1205169927.24.0.739258607005.issue1621@psf.upfronthosting.co.za> Changes by jan matejek : ---------- nosy: +matejcik __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 19:28:40 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Mon, 10 Mar 2008 18:28:40 +0000 Subject: [issue834461] simple bsddb interface potential for deadlock with threads Message-ID: <1205173720.23.0.839965498382.issue834461@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 10 19:28:48 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Mon, 10 Mar 2008 18:28:48 +0000 Subject: [issue1215023] bsddb dbobj.DB.associate doesn't accept dbobj.DB param Message-ID: <1205173728.35.0.189299136232.issue1215023@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 10 19:29:13 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Mon, 10 Mar 2008 18:29:13 +0000 Subject: [issue1010645] bsddb3 testsuite failure when running more than one time Message-ID: <1205173753.06.0.0828599177952.issue1010645@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 10 19:29:50 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Mon, 10 Mar 2008 18:29:50 +0000 Subject: [issue1149447] bssdb wrapper does not export some low-level functions Message-ID: <1205173790.38.0.609270244024.issue1149447@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 10 20:09:55 2008 From: report at bugs.python.org (Paul Komkoff) Date: Mon, 10 Mar 2008 19:09:55 +0000 Subject: [issue2267] datetime.datetime operator methods are not subclass-friendly In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za> Message-ID: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za> New submission from Paul Komkoff : The datetime.datetime class overrides some arithmetic operations for it to be able to add or subtract timedeltas. However, the result of A + B operation, where A is instance of a subclass of datetime and B is timedelta instance will be always the instance of base datetime. This is extremely annoying and requires to override arithmetic operators and writing a lots of rubbish to replace the datetime base object with type(self) ---------- components: Library (Lib) messages: 63446 nosy: stingray severity: normal status: open title: datetime.datetime operator methods are not subclass-friendly type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 20:12:37 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 10 Mar 2008 19:12:37 +0000 Subject: [issue2268] Fold slice constants In-Reply-To: <1205176357.46.0.777488164944.issue2268@psf.upfronthosting.co.za> Message-ID: <1205176357.46.0.777488164944.issue2268@psf.upfronthosting.co.za> New submission from Alexander Belopolsky : I am attaching a proof-of-concept patch which would optimize bytecode generated from constant slices as follows: Before patch: >>> dis(lambda:x[1:2:3]) 1 0 LOAD_GLOBAL 0 (x) 3 LOAD_CONST 0 (1) 6 LOAD_CONST 1 (2) 9 LOAD_CONST 2 (3) 12 BUILD_SLICE 3 15 BINARY_SUBSCR 16 RETURN_VALUE After the patch: >>> dis(lambda:x[1:2:3]) 1 0 LOAD_GLOBAL 0 (x) 3 LOAD_CONST 3 (slice(1, 2, 3)) 6 BINARY_SUBSCR 7 RETURN_VALUE While the peephole optimizer changes are straightforward, the optimization does not work unless slice objects gain hash and marshal support. While I don't see any problem with adding slice marshaling, the idea of making slices hashable has recently been rejected (see issue1733184) and I was supporting the rejection myself. With this patch, however, I would like to reopen the discussion of hash(slice(..)) issue. Allowing constant folding for slices may tip the balance towards allowing hash(slice(..)) assuming that {}[:] can still be prohibited. One possible approach to this problem would be to emit a new bytecode instead of BINARY_SUBSCR from slice syntax and have it reject mapping objects. This should be easy for objects implemented in C, but for user defined classes with custom __(get|set)item__ it may not be easy to distinguish between a mapping and a sequence. However, I don't much of a problem for always allowing x[:] for such types (user code can reject slices if necessary). If extra bytecode approach is taken, it is likely that d[slice(a,b)] will end up being supported even if d[a:b] is not. Some may think it would be a good feature, though. A possible advantage of that approach would be a better error message from an attempt to slice a dictionary. The current "unhashable type" diagnostic is somewhat cryptic. "Cannot slice a dictionary" would be much friendlier. It is possible to work around unhashability of slices and still implement folding, but the ideas that come to mind such as placing a hashable subclass of slice into constants seem too artificial. I am copying the "nosy" list from issue1733184 to start the discussion. ---------- components: Interpreter Core files: const-slice-folding.diff keywords: patch messages: 63447 nosy: belopolsky, exarkun, gvanrossum, lpd, rhettinger severity: normal status: open title: Fold slice constants type: feature request versions: Python 3.0 Added file: http://bugs.python.org/file9650/const-slice-folding.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 20:18:18 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Mon, 10 Mar 2008 19:18:18 +0000 Subject: [issue2268] Fold slice constants In-Reply-To: <1205176357.46.0.777488164944.issue2268@psf.upfronthosting.co.za> Message-ID: <1205176698.47.0.794966845074.issue2268@psf.upfronthosting.co.za> Changes by Jean-Paul Calderone : ---------- nosy: -exarkun __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 21:29:39 2008 From: report at bugs.python.org (Isaac Morland) Date: Mon, 10 Mar 2008 20:29:39 +0000 Subject: [issue2269] Problem reporting non-keyword arg after keyword arg syntax error In-Reply-To: <1205180979.73.0.892316132999.issue2269@psf.upfronthosting.co.za> Message-ID: <1205180979.73.0.892316132999.issue2269@psf.upfronthosting.co.za> New submission from Isaac Morland : $ cat bug_fine.py if True: max (a='a', 'b') #elif True: # pass else: pass $ python bug_fine.py File "bug_fine.py", line 2 max (a='a', 'b') SyntaxError: non-keyword arg after keyword arg $ cat bug_show.py if True: max (a='a', 'b') elif True: pass else: pass $ python bug_show.py Exception exceptions.SyntaxError: ('non-keyword arg after keyword arg', 2) in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Abort trap $ ---------- components: Interpreter Core messages: 63448 nosy: ijmorlan severity: normal status: open title: Problem reporting non-keyword arg after keyword arg syntax error type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 21:51:33 2008 From: report at bugs.python.org (T.G.M.) Date: Mon, 10 Mar 2008 20:51:33 +0000 Subject: [issue2270] Typo on 8.6.2.5 Document Objects page In-Reply-To: <1205182293.42.0.895316772426.issue2270@psf.upfronthosting.co.za> Message-ID: <1205182293.42.0.895316772426.issue2270@psf.upfronthosting.co.za> New submission from T.G.M. : The Python 2.5.2 online docs, "http://docs.python.org/lib/dom-document-objects.html" (http://docs.python.org/lib/dom-document-objects.html) has the following 2nd sentence: Remeber that it inherits properties from Node. Remeber should be Remember. ---------- assignee: georg.brandl components: Documentation messages: 63450 nosy: georg.brandl, throw6617 severity: normal status: open title: Typo on 8.6.2.5 Document Objects page type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 21:33:46 2008 From: report at bugs.python.org (Isaac Morland) Date: Mon, 10 Mar 2008 20:33:46 +0000 Subject: [issue2269] Problem reporting non-keyword arg after keyword arg syntax error In-Reply-To: <1205180979.73.0.892316132999.issue2269@psf.upfronthosting.co.za> Message-ID: <1205181226.02.0.242554068311.issue2269@psf.upfronthosting.co.za> Isaac Morland added the comment: I should add that the full version information is: Python 2.5 (r25:51908, Aug 15 2007, 11:38:03) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Also, in my actual code (a much larger file, in a project using ll.xist and other libraries), the error manifests differently: I get "TypeError: 'int' object is not iterable" on startup the first time it loads, then it appears to run subsequent times, but behaves bizarrely. Specifically, *none* of the branches of the if statement run (verified by putting a nonsense symbol after the if statement, and at the beginning and end of each branch of the if statement; the "no such symbol" error concerns the one *after* the if statement). On neither run is the "non-keyword arg after keyword arg" reported. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 22:32:14 2008 From: report at bugs.python.org (Facundo Batista) Date: Mon, 10 Mar 2008 21:32:14 +0000 Subject: [issue2269] Problem reporting non-keyword arg after keyword arg syntax error In-Reply-To: <1205180979.73.0.892316132999.issue2269@psf.upfronthosting.co.za> Message-ID: <1205184734.18.0.302456190868.issue2269@psf.upfronthosting.co.za> Facundo Batista added the comment: Already fixed in the trunk. Thanks for the report! ---------- nosy: +facundobatista resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 23:05:24 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 10 Mar 2008 22:05:24 +0000 Subject: [issue2267] datetime.datetime operator methods are not subclass-friendly In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za> Message-ID: <1205186724.17.0.316427290798.issue2267@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This is trivial to implement (see attached) and IMHO is a good idea. The next question, however is whether similar changes should be made to timedelta arithmetics. Timedelta case is not so clearcut because of the usual dilemma of what the type of a+b should be when a and b are instances of two different subclasses of timedelta. ---------- keywords: +patch nosy: +belopolsky Added file: http://bugs.python.org/file9651/datetime.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 10 23:21:59 2008 From: report at bugs.python.org (Paul Komkoff) Date: Mon, 10 Mar 2008 22:21:59 +0000 Subject: [issue2267] datetime.datetime operator methods are not subclass-friendly In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za> Message-ID: <1205187719.15.0.862916784312.issue2267@psf.upfronthosting.co.za> Paul Komkoff added the comment: I just checked the astimezone method - it also does this. As with timedelta... well, it's not critical for me now but it worth thinking about :) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 11 00:05:50 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 10 Mar 2008 23:05:50 +0000 Subject: [issue2267] datetime.datetime operator methods are not subclass-friendly In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za> Message-ID: <1205190350.93.0.956147374391.issue2267@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Recently, the similar issue1562 "Decimal can't be subclassed useful" was rejected. In the discussion I found a reference to a former post, which precisely deals with datetime and timedelta: http://mail.python.org/pipermail/python-list/2005-January/300791.html The main argument is that the """base class has no idea what requirements may exist for invoking a subclass's constructor""" All python types behave this way: int, float, lists. ---------- nosy: +amaury.forgeotdarc resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 11 00:33:51 2008 From: report at bugs.python.org (Ross) Date: Mon, 10 Mar 2008 23:33:51 +0000 Subject: [issue2271] msi installs to the incorrect location (C drive) In-Reply-To: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za> Message-ID: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za> New submission from Ross : When installing Python using any of the following stand-alone installers: python-2.5.2.amd64.msi python-2.5.1.amd64.msi python-2.5.2.msi all the files and folders are installed in C:\ instead of C:\Python25\ as specified in the installer. Creating C:\Python25\ before installation, changing the folder name, and rebooting the machine did not solve the problem. The installation is being performed on Windows Vista Enterprise 64 bit with an Intel Q6600 processor machine. ---------- components: Installation, Windows messages: 63455 nosy: rossmclendon severity: normal status: open title: msi installs to the incorrect location (C drive) type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 11 01:29:25 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 11 Mar 2008 00:29:25 +0000 Subject: [issue2267] datetime.datetime operator methods are not subclass-friendly In-Reply-To: <1205176194.96.0.747568659994.issue2267@psf.upfronthosting.co.za> Message-ID: <1205195365.11.0.523330652181.issue2267@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Invoking a subclass's constructor is only an issue when subclass adds data members. In this case, arithmetic methods need to be overridden. Note that my patch does not make __add__ and friends invoke subclass' constructor, only subclass' tp_alloc. Existing code already does this in some cases. For example, >>> class d(datetime): pass ... >>> d.strptime('20080310', '%Y%m%d') d(2008, 3, 10, 0, 0) >>> d.now() d(2008, 3, 10, 20, 27, 6, 303147) I think date/datetime present a particularly compelling case for departing from the general rule. These classes are minimal by design and need to be extended in many applications. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 11 01:50:50 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Tue, 11 Mar 2008 00:50:50 +0000 Subject: [issue1858] Make .pypirc handle multiple servers In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za> Message-ID: <1205196650.76.0.791361536995.issue1858@psf.upfronthosting.co.za> Tarek Ziad? added the comment: patch with more tests and explanations... for the -r option, the standard call without the change would be: $ python setup.py register -r pypi sdist upload -r pypi which is very redundant. That's why config.py looks into args. To avoid collisions, the right thing to do imho would be to have a "shared_options" dict in the command classes to allow a given command to get some options from another. For instance, in the register command, in pseudo-code: class register: shared_options = {'upload': ['repository']} and in the upload one: class upload: shared_options = {'register': ['repository']} If register and upload are both present in the command line, then the option is made available to both commands. For instance, this two lines would provide the repository to the two commands: $ python setup.py register -r pypi sdist upload $ python setup.py register sdist upload -r pypi (preferred way) But this will be a patch proposition on its own. Added file: http://bugs.python.org/file9652/distutils.2008.03.11.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 11 06:20:08 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 11 Mar 2008 05:20:08 +0000 Subject: [issue2271] msi installs to the incorrect location (C drive) In-Reply-To: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za> Message-ID: <1205212808.31.0.111168309926.issue2271@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Please run msiexec /i /l*v python.log Compress the log, and attach it to this report. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 11 12:21:02 2008 From: report at bugs.python.org (David Harel) Date: Tue, 11 Mar 2008 11:21:02 +0000 Subject: [issue2272] Segment Violation when using smtp with tls In-Reply-To: <1205234462.3.0.712730558489.issue2272@psf.upfronthosting.co.za> Message-ID: <1205234462.3.0.712730558489.issue2272@psf.upfronthosting.co.za> New submission from David Harel : Using Linux (Gentoo), when closing the socket of an smtp connection using tls (you can use the example at: http://snippets.dzone.com/posts/show/757). Attached code example with my e-mail data. (I don't mind). Also tested on Debian with Python 2.3.5 where everything seems OK. ---------- components: Library (Lib) files: t2.py messages: 63460 nosy: hareldvd severity: normal status: open title: Segment Violation when using smtp with tls type: crash versions: Python 2.4 Added file: http://bugs.python.org/file9654/t2.py __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 11 16:51:11 2008 From: report at bugs.python.org (Ross) Date: Tue, 11 Mar 2008 15:51:11 +0000 Subject: [issue2271] msi installs to the incorrect location (C drive) In-Reply-To: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za> Message-ID: <1205250671.78.0.610988427044.issue2271@psf.upfronthosting.co.za> Ross added the comment: log now attached Added file: http://bugs.python.org/file9655/python.zip __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 11 17:46:15 2008 From: report at bugs.python.org (Jared Grubb) Date: Tue, 11 Mar 2008 16:46:15 +0000 Subject: [issue2273] test_decimal: possible thread lockup in test case In-Reply-To: <1205253975.75.0.189662720786.issue2273@psf.upfronthosting.co.za> Message-ID: <1205253975.75.0.189662720786.issue2273@psf.upfronthosting.co.za> New submission from Jared Grubb : In Lib\test\test_decimal.py, attached is a bugfix for two bugs: 1) If the thfunc2 actually fails, then its thread will throw an exception and never set the Events that thfunc1 is waiting for; thus, thfunc1 never returns, causing the whole unittest to hang. 2) DecimalUseOfContextTest.test_threading should wait on both finish1 and finish2 (instead of waiting on finish1 twice). ---------- components: Library (Lib) files: test_decimal.patch keywords: patch messages: 63463 nosy: jaredgrubb severity: normal status: open title: test_decimal: possible thread lockup in test case type: crash versions: Python 2.5 Added file: http://bugs.python.org/file9656/test_decimal.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 11 17:47:22 2008 From: report at bugs.python.org (Facundo Batista) Date: Tue, 11 Mar 2008 16:47:22 +0000 Subject: [issue2273] test_decimal: possible thread lockup in test case In-Reply-To: <1205253975.75.0.189662720786.issue2273@psf.upfronthosting.co.za> Message-ID: <1205254042.81.0.603928478212.issue2273@psf.upfronthosting.co.za> Changes by Facundo Batista : ---------- assignee: -> facundobatista nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 11 20:36:11 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 11 Mar 2008 19:36:11 +0000 Subject: [issue2273] test_decimal: possible thread lockup in test case In-Reply-To: <1205253975.75.0.189662720786.issue2273@psf.upfronthosting.co.za> Message-ID: <1205264171.88.0.624752464723.issue2273@psf.upfronthosting.co.za> Mark Dickinson added the comment: This is a minor annoyance that's tripped me up before as well. Only minor, since it only happens when there's something wrong with decimal.py. The patch looks sound; I've attached a regenerated version of it against the trunk. (Note that the finish1 -> finish2 bug was already fixed in the trunk.) I think it should be applied, and probably backported to 2.5 as well. Jared, thanks for the report and the patch! I'm curious to know how you encountered this; if test_decimal is failing for a good reason, then there may be a Decimal bug to be fixed. ---------- nosy: +marketdickinson versions: +Python 2.6 Added file: http://bugs.python.org/file9657/test_decimal_thread.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 11 22:00:34 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 11 Mar 2008 21:00:34 +0000 Subject: [issue2274] heapq API In-Reply-To: <1205269233.64.0.52511417166.issue2274@psf.upfronthosting.co.za> Message-ID: <1205269233.64.0.52511417166.issue2274@psf.upfronthosting.co.za> New submission from Raymond Hettinger : The heapreplace() function has an irritating API. Since the replacement is unconditional, it usually obligates the caller to examine the top of the heap to see if it is smaller or larger than the candidate replacement item. Typical calls look like this: if item > heap[0]: item = heapreplace(heap, item) Instead of the current design "x=heappop(h); heappush(h, item); return x", it would be better to have a function equivalent to "heappush(h,item); return heappop(h)". The above fragment then simplifies to: item = heappushpop(heap, item) I propose to add heappushpop() to Py2.6 and to remove heapreplace() from Py3.0: def heappushpop(heap, item): """Fast version of a heappush followed by a heappop.""" if item > heap[0]: item, heap[0] = heap[0], item _siftup(heap, 0) return item ---------- components: Library (Lib) messages: 63465 nosy: rhettinger severity: normal status: open title: heapq API type: feature request versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 11 22:01:38 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 11 Mar 2008 21:01:38 +0000 Subject: [issue2274] heapq API In-Reply-To: <1205269233.64.0.52511417166.issue2274@psf.upfronthosting.co.za> Message-ID: <1205269298.45.0.334492842699.issue2274@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- versions: +Python 3.0 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 11 22:22:20 2008 From: report at bugs.python.org (Hans-Peter Jansen) Date: Tue, 11 Mar 2008 21:22:20 +0000 Subject: [issue2275] urllib2 header capitalization In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za> Message-ID: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za> New submission from Hans-Peter Jansen : The urllib2 behavior related to headers is - hmm - improvable. It simply capitalize() the key, which leads to funny results like: Accept-charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 while this is seemingly conforming to the specs, it's simply different to every other implementation of such things.. And we can do better. How about: --- /usr/lib/python/urllib2.py 2008-01-10 19:03:55.000000000 +0100 +++ urllib2.py 2008-03-11 21:25:33.523890670 +0100 @@ -261,13 +261,16 @@ class Request: def is_unverifiable(self): return self.unverifiable + def _cap_header_key(self, key): + return '-'.join((ck.capitalize() for ck in key.split('-'))) + def add_header(self, key, val): # useful for something like authentication - self.headers[key.capitalize()] = val + self.headers[self._cap_header_key(key)] = val def add_unredirected_header(self, key, val): # will not be added to a redirected request - self.unredirected_hdrs[key.capitalize()] = val + self.unredirected_hdrs[self._cap_header_key(key)] = val def has_header(self, header_name): return (header_name in self.headers or I'm not happy with the _cap_header_key name, but you get the idea. The patch is optimized to operate with maximum locality. It's also attached. I would be very grateful, if something similar could be applied. Opinions? ---------- components: Library (Lib) files: urllib2-cap-headers.diff keywords: patch messages: 63466 nosy: frispete severity: minor status: open title: urllib2 header capitalization type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9658/urllib2-cap-headers.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 00:51:15 2008 From: report at bugs.python.org (Gabriel Wicke) Date: Tue, 11 Mar 2008 23:51:15 +0000 Subject: [issue1450] make modulator more general In-Reply-To: <1195140931.63.0.827333708733.issue1450@psf.upfronthosting.co.za> Message-ID: <1205279475.19.0.654178540291.issue1450@psf.upfronthosting.co.za> Gabriel Wicke added the comment: Slightly adjusted and from top dir. ---------- nosy: +gwicke Added file: http://bugs.python.org/file9659/modulator-top.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 02:52:21 2008 From: report at bugs.python.org (Jared Grubb) Date: Wed, 12 Mar 2008 01:52:21 +0000 Subject: [issue2273] test_decimal: possible thread lockup in test case In-Reply-To: <1205253975.75.0.189662720786.issue2273@psf.upfronthosting.co.za> Message-ID: <1205286741.9.0.954334614963.issue2273@psf.upfronthosting.co.za> Jared Grubb added the comment: I ran into this bug because I created a context manager in one of my own projects, and the regression tests in test_decimal looked like a good start for my own regression tests... when some recent changes broke MY code, I found the test bug too and realized that the test_decimal file had the same problem. So, I figured I'd share the wealth :) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 03:50:04 2008 From: report at bugs.python.org (Bill Janssen) Date: Wed, 12 Mar 2008 02:50:04 +0000 Subject: [issue2276] distutils out-of-date for runtime_library_dirs flag on OS X In-Reply-To: <1205290203.53.0.517851484238.issue2276@psf.upfronthosting.co.za> Message-ID: <1205290203.53.0.517851484238.issue2276@psf.upfronthosting.co.za> New submission from Bill Janssen : The OS X linker now understands -R, but distutils continues to pass the wrong flags back in distutils.unixccompiler.runtime_library_dir_option(). I'm checking with the Apple folks as to exactly what the right flag is. ---------- assignee: janssen components: Distutils keywords: easy messages: 63469 nosy: janssen priority: normal severity: normal status: open title: distutils out-of-date for runtime_library_dirs flag on OS X type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 09:35:56 2008 From: report at bugs.python.org (thekorn) Date: Wed, 12 Mar 2008 08:35:56 +0000 Subject: [issue2277] MozillaCookieJar does not support Firefox3 cookie files In-Reply-To: <1205310956.06.0.761612370729.issue2277@psf.upfronthosting.co.za> Message-ID: <1205310956.06.0.761612370729.issue2277@psf.upfronthosting.co.za> New submission from thekorn : In Firefox 3 the cookies are stored in a sqlite database instead of a txt-file. It would be nice if cookielib.MozillaCookieJar().load() could support this. Markus ---------- messages: 63470 nosy: thekorn severity: normal status: open title: MozillaCookieJar does not support Firefox3 cookie files __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 12:04:03 2008 From: report at bugs.python.org (Mark Summerfield) Date: Wed, 12 Mar 2008 11:04:03 +0000 Subject: [issue2278] [Py30a3] xml.parsers.expat recognizes encoding="utf-8" but not encoding="utf8" In-Reply-To: <1205319843.23.0.2378782834.issue2278@psf.upfronthosting.co.za> Message-ID: <1205319843.23.0.2378782834.issue2278@psf.upfronthosting.co.za> New submission from Mark Summerfield : Here is how to reproduce the bug: from xml.etree.ElementTree import parse import io xml1 = """ text""" xml2 = """ text""" f1 = io.StringIO(xml1) f2 = io.StringIO(xml2) tree2 = parse(f2) # this uses "utf-8" and works fine tree1 = parse(f1) Traceback (most recent call last): File "", line 1, in tree1 = parse(f1) File "/home/mark/opt/python30a3/lib/python3.0/xml/etree/ElementTree.py", line 823, in parse tree.parse(source, parser) File "/home/mark/opt/python30a3/lib/python3.0/xml/etree/ElementTree.py", line 561, in parse parser.feed(data) File "/home/mark/opt/python30a3/lib/python3.0/xml/etree/ElementTree.py", line 1201, in feed self._parser.Parse(data, 0) xml.parsers.expat.ExpatError: unknown encoding: line 1, column 30 ---------- messages: 63471 nosy: mark severity: normal status: open title: [Py30a3] xml.parsers.expat recognizes encoding="utf-8" but not encoding="utf8" versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 13:37:31 2008 From: report at bugs.python.org (David Harel) Date: Wed, 12 Mar 2008 12:37:31 +0000 Subject: [issue2272] Segment Violation when using smtp with tls In-Reply-To: <1205234462.3.0.712730558489.issue2272@psf.upfronthosting.co.za> Message-ID: <1205325451.33.0.0227671958428.issue2272@psf.upfronthosting.co.za> David Harel added the comment: Found a problem in my python installation where SSL was unintentionally disabled. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 13:41:00 2008 From: report at bugs.python.org (Facundo Batista) Date: Wed, 12 Mar 2008 12:41:00 +0000 Subject: [issue2272] Segment Violation when using smtp with tls In-Reply-To: <1205234462.3.0.712730558489.issue2272@psf.upfronthosting.co.za> Message-ID: <1205325660.41.0.489503968536.issue2272@psf.upfronthosting.co.za> Facundo Batista added the comment: Should we close this? ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 13:56:05 2008 From: report at bugs.python.org (David Harel) Date: Wed, 12 Mar 2008 12:56:05 +0000 Subject: [issue2272] Segment Violation when using smtp with tls In-Reply-To: <1205234462.3.0.712730558489.issue2272@psf.upfronthosting.co.za> Message-ID: <1205326565.55.0.560282991863.issue2272@psf.upfronthosting.co.za> David Harel added the comment: Yep. Close it. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 13:57:22 2008 From: report at bugs.python.org (Facundo Batista) Date: Wed, 12 Mar 2008 12:57:22 +0000 Subject: [issue2272] Segment Violation when using smtp with tls In-Reply-To: <1205234462.3.0.712730558489.issue2272@psf.upfronthosting.co.za> Message-ID: <1205326642.85.0.303510690859.issue2272@psf.upfronthosting.co.za> Changes by Facundo Batista : ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 15:53:32 2008 From: report at bugs.python.org (David Ripton) Date: Wed, 12 Mar 2008 14:53:32 +0000 Subject: [issue2279] distutils sdist add_defaults does not add data_files In-Reply-To: <1205333612.66.0.693918609529.issue2279@psf.upfronthosting.co.za> Message-ID: <1205333612.66.0.693918609529.issue2279@psf.upfronthosting.co.za> New submission from David Ripton : distutils.sdist.add_defaults adds the Python modules and scripts and C extensions found in setup.py to the MANIFEST. It does *not* add data_files mentioned in setup.py to the MANIFEST. This is non-orthogonal and confusing, because it means that a MANIFEST.in is required if you have data_files, optional if you do not. If you have data_files and do not have MANIFEST.in, you get a broken package but no error. ---------- components: Distutils messages: 63475 nosy: dripton severity: normal status: open title: distutils sdist add_defaults does not add data_files type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 18:04:05 2008 From: report at bugs.python.org (HiroakiKawai) Date: Wed, 12 Mar 2008 17:04:05 +0000 Subject: [issue2259] Poor support other than 44.1khz, 16bit audio files? In-Reply-To: <1205075207.56.0.203597492215.issue2259@psf.upfronthosting.co.za> Message-ID: <1205341445.24.0.161703698045.issue2259@psf.upfronthosting.co.za> HiroakiKawai added the comment: I looked into the problem, and found that current aifc impelementation assumes that SSND chunk is aligned (in Audio-IFF). But it is not always true. SSND chunk might not be aligned. Here I'd like to submit a set of patches for this issue. I'd like to donate these patches to python. ---------- nosy: +kawai severity: major -> normal type: feature request -> crash __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 18:06:12 2008 From: report at bugs.python.org (HiroakiKawai) Date: Wed, 12 Mar 2008 17:06:12 +0000 Subject: [issue2259] Poor support other than 44.1khz, 16bit audio files? In-Reply-To: <1205075207.56.0.203597492215.issue2259@psf.upfronthosting.co.za> Message-ID: <1205341572.75.0.349021524436.issue2259@psf.upfronthosting.co.za> HiroakiKawai added the comment: Patch for chunk.py that skip() method may get an optional arguments, that it will skip in aligned or not. ---------- keywords: +patch Added file: http://bugs.python.org/file9660/chunk.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 18:07:27 2008 From: report at bugs.python.org (HiroakiKawai) Date: Wed, 12 Mar 2008 17:07:27 +0000 Subject: [issue2259] Poor support other than 44.1khz, 16bit audio files? In-Reply-To: <1205075207.56.0.203597492215.issue2259@psf.upfronthosting.co.za> Message-ID: <1205341647.44.0.499798438388.issue2259@psf.upfronthosting.co.za> HiroakiKawai added the comment: Patch for aifc.py that will use chunk.skip(True) in SSND chunk. Added file: http://bugs.python.org/file9661/aifc.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 18:09:17 2008 From: report at bugs.python.org (HiroakiKawai) Date: Wed, 12 Mar 2008 17:09:17 +0000 Subject: [issue2259] Poor support other than 44.1khz, 16bit audio files? In-Reply-To: <1205075207.56.0.203597492215.issue2259@psf.upfronthosting.co.za> Message-ID: <1205341757.11.0.622631887668.issue2259@psf.upfronthosting.co.za> HiroakiKawai added the comment: Can I ask someone to review the patch files, and to merge into the code base if those patches are ok? __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 18:11:40 2008 From: report at bugs.python.org (HiroakiKawai) Date: Wed, 12 Mar 2008 17:11:40 +0000 Subject: [issue2245] aifc cannot handle unrecognised chunk type "CHAN" In-Reply-To: <1204822344.2.0.466596380411.issue2245@psf.upfronthosting.co.za> Message-ID: <1205341900.91.0.284741870102.issue2245@psf.upfronthosting.co.za> HiroakiKawai added the comment: Issue2259 patches will also fix this issue. :-) ---------- nosy: +kawai __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 18:30:14 2008 From: report at bugs.python.org (Oki Mikito) Date: Wed, 12 Mar 2008 17:30:14 +0000 Subject: [issue2259] Poor support other than 44.1khz, 16bit audio files? In-Reply-To: <1205341757.11.0.622631887668.issue2259@psf.upfronthosting.co.za> Message-ID: <20080313023004748421.23fe5928@u01.gate01.com> Oki Mikito added the comment: Hello Kawai, I see you are attemping to kill two bugs in one stone (or ... whack!) by eliminating the _skiplist ... Beautiful :-) As we discussed in the Mixi Python thread, I was going to give those patches a set of runs, but I'm completely swamped until Saturday morning, JST... On Wed, 12 Mar 2008 17:09:17 +0000, HiroakiKawai wrote: > > HiroakiKawai added the comment: > > Can I ask someone to review the patch files, and to merge into the code > base if those patches are ok? > > __________________________________ > Tracker > > __________________________________ > _______________________________________________ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/moki%40u01.gate01.com > > __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 19:33:05 2008 From: report at bugs.python.org (David Binger) Date: Wed, 12 Mar 2008 18:33:05 +0000 Subject: [issue2280] parser module chokes on unusual characters In-Reply-To: <1205346785.26.0.563823122087.issue2280@psf.upfronthosting.co.za> Message-ID: <1205346785.26.0.563823122087.issue2280@psf.upfronthosting.co.za> New submission from David Binger : This is with the current revision of py3k: 61353. parser.suite('"\u1234"') fails with a TypeError. Changing the argument format from "s" to "s#" works around this problem. I added a unit test for this. After fixing the "s#", another bug is exposed by the same test: a string literal containing \u1234 is mangled by sequence2st(). The last section of the patch seems to correct the second bug. (I think getarg.c's handling of "s" has a problem handling a unicode string containing a character whose encoding is not 1 byte. It has a test for null bytes at the end that does not work correctly.) ---------- components: Library (Lib) files: parsermodule.patch keywords: patch messages: 63482 nosy: dbinger severity: normal status: open title: parser module chokes on unusual characters type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file9662/parsermodule.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 21:02:01 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Wed, 12 Mar 2008 20:02:01 +0000 Subject: [issue1858] Make .pypirc handle multiple servers In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za> Message-ID: <1205352121.08.0.367077700397.issue1858@psf.upfronthosting.co.za> Changes by Tarek Ziad? : Added file: http://bugs.python.org/file9663/distutils.2008.03.12.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 21:13:46 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 12 Mar 2008 20:13:46 +0000 Subject: [issue2186] map and filter shouldn't support None as first argument (in Py3k only) In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za> Message-ID: <1205352826.24.0.611278359106.issue2186@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Do you guys see any merit in changing the argument order for ifilter so that the predicate function can just be an optional argument: ifilter(data[, pred]) Alex Martelli successfully lobbied for groupby() to have that same argument order. Originally, the signature was groupby(key, iterable) but it worked-out much better to have groupby(iterable[, key]). Also, I like swapped arguments because it more closely parallels the order used in an equivalent list comprehension: [e for e in iterable if pred(e)] __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 22:31:56 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 12 Mar 2008 21:31:56 +0000 Subject: [issue2186] map and filter shouldn't support None as first argument (in Py3k only) In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za> Message-ID: <1205357516.47.0.863495304787.issue2186@psf.upfronthosting.co.za> Guido van Rossum added the comment: It would break the symmetry with map(). __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 22:46:50 2008 From: report at bugs.python.org (Jean Brouwers) Date: Wed, 12 Mar 2008 21:46:50 +0000 Subject: [issue2218] Enhanced hotshot profiler with high-resolution timer In-Reply-To: <1204501511.28.0.993763550383.issue2218@psf.upfronthosting.co.za> Message-ID: <1205358410.88.0.581072845027.issue2218@psf.upfronthosting.co.za> Jean Brouwers added the comment: Attached is yet another, final update of the enhancements to the hotshot profiler. It includes modifications of all 3 files, Modules/_hotshot.c, Lib/hotshot/log.py and Lib/hotshot/stats.py. Added file: http://bugs.python.org/file9664/hires_hotshot5.tgz __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 22:56:48 2008 From: report at bugs.python.org (Jean Brouwers) Date: Wed, 12 Mar 2008 21:56:48 +0000 Subject: [issue2281] Enhanced cPython profiler with high-resolution timer In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za> Message-ID: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za> New submission from Jean Brouwers : Attached is a modified version of the cPython profiler file Modules/_lsprof.c using a high-resolution timer where available. The enhancement has been tested on 32- and 64-bit Linux (x86 and x86_64) and on 32-bit MacOS X Tiger (Intel) and Panther (PPC). No other platforms have been tested but as before the profiler will fallback to using gettimeofday() on non-Windows version, except the 64- bit PPC build will issue a compile-time warning. ---------- files: hires_lsprof.tgz messages: 63486 nosy: MrJean1 severity: normal status: open title: Enhanced cPython profiler with high-resolution timer Added file: http://bugs.python.org/file9665/hires_lsprof.tgz __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 22:58:19 2008 From: report at bugs.python.org (Jean Brouwers) Date: Wed, 12 Mar 2008 21:58:19 +0000 Subject: [issue2281] Enhanced cPython profiler with high-resolution timer In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za> Message-ID: <1205359099.27.0.223835593904.issue2281@psf.upfronthosting.co.za> Jean Brouwers added the comment: This enhancement applies to Python 2.5.2 only. ---------- components: +None versions: +Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 23:24:42 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 12 Mar 2008 22:24:42 +0000 Subject: [issue2186] map and filter shouldn't support None as first argument (in Py3k only) In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za> Message-ID: <1205360682.04.0.262708329457.issue2186@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Okay, thanks. Though, I should have also mentioned symmetries with sorted(), min(), and max() which all take the iterable first and follow with an optional key function. Closing this one. The map(None, *args) feature was removed for 3.0. Have decided to leave None in ifilter() and ifilterfalse() since None is the preferred way to spell a default argument and having to pass "bool" feels awkward and clunky. Switching the argument order was shot down, so will just leave it as-is. Marked resolution as "accepted" since the map(None) suggestion went in. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 12 23:40:56 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 12 Mar 2008 22:40:56 +0000 Subject: [issue1619060] bisect on presorted list Message-ID: <1205361656.51.0.10236538993.issue1619060@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Guido, what do you think about this one? It is easy to do and has been requested several times in various forums. The seeming reasonable basis for the request is that sort and bisect should fit together like a nut and bolt -- it is somewhat odd to be able to sort a list by a key function but not be able to search or insert according to the same key. My main reservation is that the existence of the API would tend to encourage bad design. Elsewhere, the intent of the key function is to be cheaper than a cmp function (such as with sort() which calls the key function once per element instead of many times for cmp). But with successive bisect/insort calls, a key function could be called multiple times for the same value. The same issue also applies to heapq: http://bugs.python.org/issue1158313 and http://bugs.python.org/issue1162363 . ---------- assignee: rhettinger -> gvanrossum nosy: +gvanrossum _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Mar 12 23:41:51 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 12 Mar 2008 22:41:51 +0000 Subject: [issue2186] map and filter shouldn't support None as first argument (in Py3k only) In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za> Message-ID: <1205361711.47.0.637180849565.issue2186@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: It may be too late to express my opinion, but why symmetry with map is so important? There are several reasons why sequence, predicate order is natural for filter and function, sequence is a natural order for map. 1. In list comprehensions predicate comes last: compare [f(x) for x in seq] and [x for x in seq if pred(x)]. 2. In English, map(f, sec) = "Map f over seq" while filter(pred, seq) = filter seq through pred. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 00:14:52 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 12 Mar 2008 23:14:52 +0000 Subject: [issue1619060] bisect on presorted list Message-ID: <1205363692.68.0.650224420862.issue1619060@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sorry, I will claim ignorance on this one. I don't recall the last time I've used a bisection, but it was probably around the time bisect.py was first added to the standard library. I do recall using heap sort as a way to compute the top N items. I've always done that by explicitly mapping the raw data to a list of (key, value) tuples. The arguments worrying about bad design make some sense to me; consistency isn't always the panacea that people want it to be... ---------- assignee: gvanrossum -> rhettinger _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 13 01:19:48 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 13 Mar 2008 00:19:48 +0000 Subject: [issue2187] map and filter objects shouldn't call themselves itertools.imap and itertools.ifilter objects In-Reply-To: <1203912393.93.0.542034145093.issue2187@psf.upfronthosting.co.za> Message-ID: <1205367588.52.0.353914621489.issue2187@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Moved filter to builtins in r61536. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 02:26:57 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 13 Mar 2008 01:26:57 +0000 Subject: [issue2187] map and filter objects shouldn't call themselves itertools.imap and itertools.ifilter objects In-Reply-To: <1203912393.93.0.542034145093.issue2187@psf.upfronthosting.co.za> Message-ID: <1205371617.57.0.404618862864.issue2187@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Moved map to builtins in r61357. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 05:32:31 2008 From: report at bugs.python.org (zhen) Date: Thu, 13 Mar 2008 04:32:31 +0000 Subject: [issue2282] TextIOWrapper.seekable() always returns False In-Reply-To: <1205382751.6.0.0963204550732.issue2282@psf.upfronthosting.co.za> Message-ID: <1205382751.6.0.0963204550732.issue2282@psf.upfronthosting.co.za> New submission from zhen : The seekable() method of TextIOWrapper always returns False, for it does't override the seekable method of IOBase class in which just returns False. But, there is a method named _seekable(self) in TextIOWrapper(in io.py line 1211): def _seekable(self): return self._seekable which should be seekable(self), and _seekable method is overwrited by line 1190 in the __init__ method as a bool object: self._seekable = self._telling = self.buffer.seekable() ---------- components: Library (Lib) messages: 63494 nosy: netzhen severity: normal status: open title: TextIOWrapper.seekable() always returns False type: feature request versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 08:16:12 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 13 Mar 2008 07:16:12 +0000 Subject: [issue2265] A line in the second example of "7.3.5 Examples" in "Python Library Reference" seems to be incorrect. In-Reply-To: <1205157337.33.0.156583580671.issue2265@psf.upfronthosting.co.za> Message-ID: <1205392572.25.0.949082039328.issue2265@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r61363. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 08:17:26 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 13 Mar 2008 07:17:26 +0000 Subject: [issue2270] Typo on 8.6.2.5 Document Objects page In-Reply-To: <1205182293.42.0.895316772426.issue2270@psf.upfronthosting.co.za> Message-ID: <1205392646.11.0.436797222114.issue2270@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r61364. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 08:19:15 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 13 Mar 2008 07:19:15 +0000 Subject: [issue1533486] long -> Py_ssize_t (C/API 1.2.1) Message-ID: <1205392755.13.0.567043147371.issue1533486@psf.upfronthosting.co.za> Georg Brandl added the comment: PEP 353 says: "Py_intptr_t needs to be the same size as void*, and Py_ssize_t the same size as size_t. These could differ, e.g. on machines where pointers have segment and offset." _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 13 08:22:44 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 13 Mar 2008 07:22:44 +0000 Subject: [issue1720705] thread + import => crashes? Message-ID: <1205392964.02.0.860886681632.issue1720705@psf.upfronthosting.co.za> Georg Brandl added the comment: Added your remarks to threading docs in r61365. ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 13 09:14:47 2008 From: report at bugs.python.org (Mark Summerfield) Date: Thu, 13 Mar 2008 08:14:47 +0000 Subject: [issue2283] lambda *a, **k: a, k # does not work In-Reply-To: <1205396087.42.0.232121283205.issue2283@psf.upfronthosting.co.za> Message-ID: <1205396087.42.0.232121283205.issue2283@psf.upfronthosting.co.za> New submission from Mark Summerfield : According to the docs lambda can handle the same parameter list as can def. But this does not appear to be the case as the following (both 2.5.1 and 30a3) shows: >>> def f(*a, **kw): return a, kw >>> f(1,2,a=3,b=4) ((1, 2), {'a': 3, 'b': 4}) >>> A = lambda *a: a >>> A(1,2) (1, 2) >>> K = lambda **k: k >>> K(a=1,b=2) {'a': 1, 'b': 2} >>> X = lambda *a, **k: a, k Traceback (most recent call last): File "", line 1, in X = lambda *a, **k: a, k NameError: name 'k' is not defined So either this is an interpreter bug, or a doc bug. ---------- components: Interpreter Core messages: 63499 nosy: mark severity: normal status: open title: lambda *a, **k: a, k # does not work versions: Python 2.5, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 09:14:59 2008 From: report at bugs.python.org (Mark Summerfield) Date: Thu, 13 Mar 2008 08:14:59 +0000 Subject: [issue2283] lambda *a, **k: a, k # does not work In-Reply-To: <1205396087.42.0.232121283205.issue2283@psf.upfronthosting.co.za> Message-ID: <1205396099.6.0.683888263372.issue2283@psf.upfronthosting.co.za> Changes by Mark Summerfield : ---------- type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 09:16:17 2008 From: report at bugs.python.org (Mark Summerfield) Date: Thu, 13 Mar 2008 08:16:17 +0000 Subject: [issue2278] [Py30a3] xml.parsers.expat recognizes encoding="utf-8" but not encoding="utf8" In-Reply-To: <1205319843.23.0.2378782834.issue2278@psf.upfronthosting.co.za> Message-ID: <1205396177.32.0.714685064569.issue2278@psf.upfronthosting.co.za> Changes by Mark Summerfield : ---------- components: +Library (Lib), XML type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 10:21:05 2008 From: report at bugs.python.org (Armin Rigo) Date: Thu, 13 Mar 2008 09:21:05 +0000 Subject: [issue1617161] Instance methods compare equal when their self's are equal Message-ID: <1205400065.3.0.122353949029.issue1617161@psf.upfronthosting.co.za> Armin Rigo added the comment: Attached patch for python trunk with tests. It makes all three method types use the identity of their 'self'. ---------- keywords: +patch Added file: http://bugs.python.org/file9666/method_compare.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 13 12:18:37 2008 From: report at bugs.python.org (Imri Goldberg) Date: Thu, 13 Mar 2008 11:18:37 +0000 Subject: [issue2283] lambda *a, **k: a, k # does not work In-Reply-To: <1205396087.42.0.232121283205.issue2283@psf.upfronthosting.co.za> Message-ID: <1205407116.95.0.310925247069.issue2283@psf.upfronthosting.co.za> Imri Goldberg added the comment: This is not a bug, just missing parenthesis. >>> lambda x: x,x Traceback (most recent call last): File "", line 1, in NameError: name 'x' is not defined >>> lambda x: (x,x) at 0x8293e2c> ---------- nosy: +lorg __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 12:47:49 2008 From: report at bugs.python.org (Mark Summerfield) Date: Thu, 13 Mar 2008 11:47:49 +0000 Subject: [issue2283] lambda *a, **k: a, k # does not work In-Reply-To: <1205407116.95.0.310925247069.issue2283@psf.upfronthosting.co.za> Message-ID: <200803131142.54306.mark@qtrac.eu> Mark Summerfield added the comment: On 2008-03-13, Imri Goldberg wrote: > Imri Goldberg added the comment: > > This is not a bug, just missing parenthesis. > > >>> lambda x: x,x > > Traceback (most recent call last): > File "", line 1, in > NameError: name 'x' is not defined > > >>> lambda x: (x,x) > > at 0x8293e2c> Yes, sorry. (But I don't seem to have the ability to make the bug resolved or deleted.) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 13:36:25 2008 From: report at bugs.python.org (Jeffrey C. Jacobs) Date: Thu, 13 Mar 2008 12:36:25 +0000 Subject: [issue1619060] bisect on presorted list Message-ID: <1205411785.77.0.785708243016.issue1619060@psf.upfronthosting.co.za> Jeffrey C. Jacobs added the comment: Thanks Raymond for checking on the status of this issue and Guido for thinking about it too. I still support the basic concept for the reasons I specified in the original description, namely maintaining a sorted list (or random-access iterable). Thus, although in some ways it seems like syntactic sugar to make bisect and heap match the parameter list of sort, there is good reason to do so. That having been said, the re-computation of the /key/ function for typically the same values at each invocation of an insort_* method can potentially add a lot of otherwise unnecessary calls. So, having thought about this further, it seems to me that, somehow, the bisect/insort routines functions need to cache the results of each evaluation of key in the same way that sort can maintain that information in a local variable. Ideally, IMHO, the keys computed in sort could be cached and stored with the list upon which it was operated, but this is cumbersome, would not work for generic types and would be invalid if for some reason the sort key was different from the bisect key. Typically the later case would not occur but since it might lead to unexpected behavior it should definitely be avoided. Instead, I am now thinking that the only way we can safely maintain caching information is to implement a persistent object to contain it that can be shared between each invocation of bisect/insort so as to not force re-evaluation of the same key argument. This clearly could be done with a class. So I would propose that a bisect class be created that would hold the list, the current key function and the cached key values. Of course, special care would need to be taken to take into account mutable sequences that could be changed between bisect calls. The class could be implements in a number of ways. For instance, it could create a callable instance that accepts a list and other parameters. It will then look at its state, including a check of /is/ with the input and the last list operated upon, and if that test fails, the 'key cache' is invalidated. Next, if a key method is provided, it is checked against the last key function used (/is/) and if it is not, the 'key cache' is invalidated. Then, to prevent mutability problems, the 'key cache' would actually be implemented as a dictionary mapping item to key-value and each time a key needed to be computed, the input would first be checked against the cache and only if it was not there would the key function be called. This should allow for preventing undefined behavior when handling invalid cases. Of course, if the client wishes to use bisect on 2 different lists or 2 different keys, sie could always just create 2 different bisect objects. There are of course other ways to accomplish this, such as binding the bisect object to a list and key at construction that cannot be reset (at least, should not be) once invoked. I am also wary of implementing the 'key cache' as a dictionary as it adds a hash-table lookup which is already potentially expensive. Ideally, if the bisect object could force its associated list to be immutable for the life of the bisect, this would get around the problem of external inserts and deletes that would invalidate the 'key cache'. Obviously, there may be another way to define such a class but I think the only way you can safely make sure the bisect functions don't unnecessarily compute key without modifying the list is to allow for the caching of values between invocations, and the only way you can do that safely is by putting the cache in some helper class. Of course, a class is only needed for when key is used. comp and reverse, AFAIK, are not cached when sorting. So the existing, generic bisect algorithms would still be useful and in fact, you'd want the bisect class to be optional, IMHO. Of course, Guido's suggestion of just mapping your list into a list of (key, value) tuples is a good workaround for just the key case (assuming key, comp and reverse flags are not all used at the same time for sorting). It probably should be a cookbook item that could be documented with the bisect (and heap) libraries. It can't completely solve the problem, but it will solve some conditions in the short term. Long term, I still think we should consider bisect, potentially with a class definition. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 13 14:44:28 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Thu, 13 Mar 2008 13:44:28 +0000 Subject: [issue2283] lambda *a, **k: a, k # does not work In-Reply-To: <1205396087.42.0.232121283205.issue2283@psf.upfronthosting.co.za> Message-ID: <1205415868.9.0.446192785695.issue2283@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: I am closing it as invalid. ---------- nosy: +draghuram resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 15:53:27 2008 From: report at bugs.python.org (Paul Molodowitch) Date: Thu, 13 Mar 2008 14:53:27 +0000 Subject: [issue745002] <> in attrs in sgmllib not handled Message-ID: <1205420007.68.0.952248305203.issue745002@psf.upfronthosting.co.za> Paul Molodowitch added the comment: errr... why was my last message classified as spam? =( Is there some policy here I'm violating that I'm unaware of? I would think consolidating of similar issues would be a good thing... ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Mar 13 16:51:05 2008 From: report at bugs.python.org (Tim Mooney) Date: Thu, 13 Mar 2008 15:51:05 +0000 Subject: [issue1471934] Python libcrypt build problem on Solaris 8 Message-ID: <1205423465.56.0.758910806532.issue1471934@psf.upfronthosting.co.za> Tim Mooney added the comment: Paul, your comment in your patch, about this being fixed post Solaris 9, doesn't appear to be correct. I have x86_64-sun-solaris2.10 with all patches applied and the problem exists there too. I'm using Workshop 12. ---------- nosy: +enchanter _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 13 17:00:33 2008 From: report at bugs.python.org (Tim Mooney) Date: Thu, 13 Mar 2008 16:00:33 +0000 Subject: [issue1306248] Add 64-bit Solaris 9 build instructions to README Message-ID: <1205424033.73.0.44976846655.issue1306248@psf.upfronthosting.co.za> Tim Mooney added the comment: I agree with Terry's comment -- Python's build machinery for multi-abi systems is suboptimal, but documenting some methods that work for some people would at least help. ---------- nosy: +enchanter _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 13 20:04:42 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 13 Mar 2008 19:04:42 +0000 Subject: [issue2274] heapq API In-Reply-To: <1205269233.64.0.52511417166.issue2274@psf.upfronthosting.co.za> Message-ID: <1205435082.43.0.359045823453.issue2274@psf.upfronthosting.co.za> Raymond Hettinger added the comment: See r61369. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 21:07:43 2008 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Mar 2008 20:07:43 +0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1205438863.27.0.576318913009.issue1631171@psf.upfronthosting.co.za> Brett Cannon added the comment: Add tests for the 'line' argument to formatwarning() and showwarning(). Added file: http://bugs.python.org/file9667/c_warnings.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 13 21:23:52 2008 From: report at bugs.python.org (Jean Brouwers) Date: Thu, 13 Mar 2008 20:23:52 +0000 Subject: [issue2281] Enhanced cPython profiler with high-resolution timer In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za> Message-ID: <1205439832.71.0.898266245514.issue2281@psf.upfronthosting.co.za> Jean Brouwers added the comment: Attached are 2 Modules/_lsprof.c files, one for Python 2.5.2 and 2.6a1 and the other for Python 3.0a3. Discard the previously posted one. Both contain the same enhancements to use the high-resolution timer where available. These versions catch wrap around of the timer and clock and adjust accordingly. In the hpTimerUnit function only and not for profile times. Lastly, instead of malloc and free functions PyObject_MALLOC and PyObject_FREE are called making profiler memory usage the same as for other objects created. Added file: http://bugs.python.org/file9668/hires_lsprof2.tgz __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 21:28:12 2008 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Mar 2008 20:28:12 +0000 Subject: [issue1163] Patch to make py3k/Lib/test/test_thread.py use unittest In-Reply-To: <1189716284.14.0.731587467816.issue1163@psf.upfronthosting.co.za> Message-ID: <1205440092.31.0.617088598102.issue1163@psf.upfronthosting.co.za> Brett Cannon added the comment: Closing as out of date as a GHOP attempt at this got farther and committed. ---------- nosy: +brett.cannon resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 21:50:00 2008 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Mar 2008 20:50:00 +0000 Subject: [issue1952] test_select.py converted to unittest In-Reply-To: <1201483280.65.0.166319108689.issue1952@psf.upfronthosting.co.za> Message-ID: <1205441400.3.0.475330538713.issue1952@psf.upfronthosting.co.za> Brett Cannon added the comment: Went with another test_select conversion from GHOP that added more tests. Closing as rejected. ---------- resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 21:54:12 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 13 Mar 2008 20:54:12 +0000 Subject: [issue745002] <> in attrs in sgmllib not handled Message-ID: <1205441652.53.0.28246071185.issue745002@psf.upfronthosting.co.za> Benjamin Peterson added the comment: >errr... why was my last message classified as spam? =( It's not your fault. The spam filter was just confused. Somebody with more powerful than me can, I believe, reeducate the spam filter and allow us to read it. ---------- nosy: +benjamin.peterson ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Mar 13 22:03:09 2008 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Mar 2008 21:03:09 +0000 Subject: [issue1960] test_gdbm.py converted to unittest In-Reply-To: <1201563061.25.0.859270038102.issue1960@psf.upfronthosting.co.za> Message-ID: <1205442189.56.0.44679842007.issue1960@psf.upfronthosting.co.za> Brett Cannon added the comment: Committed in revision 61374 (w/ changes so that the key stuff is not order-dependent). Thanks, Giampaolo! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 22:08:33 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 13 Mar 2008 21:08:33 +0000 Subject: [issue2278] [Py30a3] xml.parsers.expat recognizes encoding="utf-8" but not encoding="utf8" In-Reply-To: <1205319843.23.0.2378782834.issue2278@psf.upfronthosting.co.za> Message-ID: <1205442513.53.0.40843176929.issue2278@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Should the parser recognize "utf8"? I looked at the XML standard [1] and it referred me to the IANA's charts [2]. It appears the the only correct way to denote UTF-8 is "UTF-8". [1] http://www.w3.org/TR/2006/REC-xml11-20060816/#NT-EncodingDecl [2] http://www.iana.org/assignments/character-sets ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 22:10:27 2008 From: report at bugs.python.org (Brett Cannon) Date: Thu, 13 Mar 2008 21:10:27 +0000 Subject: [issue2055] test_fcntl.py converted to unittest In-Reply-To: <1202574695.1.0.144086248803.issue2055@psf.upfronthosting.co.za> Message-ID: <1205442627.49.0.265393221895.issue2055@psf.upfronthosting.co.za> Brett Cannon added the comment: Committed in revision 61375. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 13 22:36:05 2008 From: report at bugs.python.org (thekorn) Date: Thu, 13 Mar 2008 21:36:05 +0000 Subject: [issue2277] MozillaCookieJar does not support Firefox3 cookie files In-Reply-To: <1205310956.06.0.761612370729.issue2277@psf.upfronthosting.co.za> Message-ID: <1205444165.71.0.437939817789.issue2277@psf.upfronthosting.co.za> thekorn added the comment: I had some time this evening and tried to create a patch. I don't know if such a solution makes sense nor do I know if this fits in the process of fixing bugs in python. Markus ---------- keywords: +patch Added file: http://bugs.python.org/file9669/2277_handling_FF3_cookies.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 14 02:36:04 2008 From: report at bugs.python.org (Brett Cannon) Date: Fri, 14 Mar 2008 01:36:04 +0000 Subject: [issue1659] Tests needing network flag? In-Reply-To: <18281.12938.264352.782990@montanaro.dyndns.org> Message-ID: <1205458564.19.0.280039290249.issue1659@psf.upfronthosting.co.za> Brett Cannon added the comment: I think, for the cases that are not special-cased by regrtest, test.test_support.requires() should be used. ---------- assignee: brett.cannon -> skip.montanaro __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 14 04:45:58 2008 From: report at bugs.python.org (Trent Nelson) Date: Fri, 14 Mar 2008 03:45:58 +0000 Subject: [issue2284] [PATCH] -x64 option added to pcbuild/rt.bat to facilitate testing of amd64\python[_d].exe. In-Reply-To: <1205466358.32.0.414062205186.issue2284@psf.upfronthosting.co.za> Message-ID: <1205466358.32.0.414062205186.issue2284@psf.upfronthosting.co.za> New submission from Trent Nelson : Looks like there's been a recent change to trunk such that x64 Windows builds now get placed in pcbuild\amd64 instead of just pcbuild (thanks to whoever added it). The attached patch against rt.bat allows it to be called with an -x64 arg, which invokes the 64-bit Python build, instead of the 32-bit one. (tools/buildbot/test-amd64.bat should eventually be created to call this as well, once we've ironed out all the Windows x64 issues.) ---------- components: Build files: rt.bat.patch keywords: patch messages: 63520 nosy: Trent.Nelson severity: normal status: open title: [PATCH] -x64 option added to pcbuild/rt.bat to facilitate testing of amd64\python[_d].exe. type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file9670/rt.bat.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 14 12:11:59 2008 From: report at bugs.python.org (David Binger) Date: Fri, 14 Mar 2008 11:11:59 +0000 Subject: [issue2285] list.sort.__doc__ says "cmp" is a keyword, but it isn't. In-Reply-To: <1205493118.81.0.272184135771.issue2285@psf.upfronthosting.co.za> Message-ID: <1205493118.81.0.272184135771.issue2285@psf.upfronthosting.co.za> New submission from David Binger : (at revision 61376) It looks like this docstring needs to be updated. ---------- assignee: georg.brandl components: Documentation messages: 63521 nosy: dbinger, georg.brandl severity: minor status: open title: list.sort.__doc__ says "cmp" is a keyword, but it isn't. versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 14 13:41:25 2008 From: report at bugs.python.org (Bruno Gola) Date: Fri, 14 Mar 2008 12:41:25 +0000 Subject: [issue2285] list.sort.__doc__ says "cmp" is a keyword, but it isn't. In-Reply-To: <1205493118.81.0.272184135771.issue2285@psf.upfronthosting.co.za> Message-ID: <1205498485.44.0.728707545785.issue2285@psf.upfronthosting.co.za> Bruno Gola added the comment: i'm using the lastest version from subversion (trunk) and cmp still is a keyord for list.sort. ---------- nosy: +brunogola __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 14 13:57:55 2008 From: report at bugs.python.org (Trent Nelson) Date: Fri, 14 Mar 2008 12:57:55 +0000 Subject: [issue2286] Stack overflow exception caused by test_marshal on Windows x64 In-Reply-To: <1205499475.78.0.0465561571315.issue2286@psf.upfronthosting.co.za> Message-ID: <1205499475.78.0.0465561571315.issue2286@psf.upfronthosting.co.za> New submission from Trent Nelson : S:\src\svn\svn.python.org\projects\python\trunk.x64\PCbuild>amd64\python_d ..\lib\test\test_marshal.py test_bool (__main__.IntTestCase) ... ok test_int64 (__main__.IntTestCase) ... ok test_ints (__main__.IntTestCase) ... ok test_floats (__main__.FloatTestCase) ... ok test_buffer (__main__.StringTestCase) ... ok test_string (__main__.StringTestCase) ... ok test_unicode (__main__.StringTestCase) ... ok test_code (__main__.CodeTestCase) ... ok test_dict (__main__.ContainerTestCase) ... ok test_list (__main__.ContainerTestCase) ... ok test_sets (__main__.ContainerTestCase) ... ok test_tuple (__main__.ContainerTestCase) ... ok test_exceptions (__main__.ExceptionTestCase) ... ok test_bug_5888452 (__main__.BugsTestCase) ... ok test_exact_type_match (__main__.BugsTestCase) ... ok test_fuzz (__main__.BugsTestCase) ... ok test_loads_recursion (__main__.BugsTestCase) ... ^^^ python_d.exe crashes at this point with a stack overflow. Just capturing the issue for now. Will investigate shortly and hopefully provide a patch. ---------- components: Tests messages: 63523 nosy: Trent.Nelson severity: normal status: open title: Stack overflow exception caused by test_marshal on Windows x64 type: crash versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 14 14:25:11 2008 From: report at bugs.python.org (David Binger) Date: Fri, 14 Mar 2008 13:25:11 +0000 Subject: [issue2285] list.sort.__doc__ says "cmp" is a keyword, but it isn't. In-Reply-To: <1205498485.44.0.728707545785.issue2285@psf.upfronthosting.co.za> Message-ID: David Binger added the comment: Hi Bruno, Are you testing py3k? This is what I see: Python 3.0a3+ (py3k:61352M, Mar 12 2008, 13:11:35) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> [].sort(cmp=lambda x, y: 1) Traceback (most recent call last): File "", line 1, in TypeError: 'cmp' is an invalid keyword argument for this function >>> In listobject.c, in listsort(), at line 1863, we have the following, which appears to be where "key" and "reverse" keyword args are supported, but not "cmp". static char *kwlist[] = {"key", "reverse", 0}; assert(self != NULL); assert (PyList_Check(self)); if (args != NULL) { if (!PyArg_ParseTupleAndKeywords(args, kwds, "|Oi:sort", On Mar 14, 2008, at 8:41 AM, Bruno Gola wrote: > > Bruno Gola added the comment: > > i'm using the lastest version from subversion (trunk) and cmp still > is a > keyord for list.sort. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 14 14:29:10 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 14 Mar 2008 13:29:10 +0000 Subject: [issue2285] list.sort.__doc__ says "cmp" is a keyword, but it isn't. In-Reply-To: <1205493118.81.0.272184135771.issue2285@psf.upfronthosting.co.za> Message-ID: <1205501350.13.0.276745353596.issue2285@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r61377. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 14 14:56:25 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 14 Mar 2008 13:56:25 +0000 Subject: [issue2284] [PATCH] -x64 option added to pcbuild/rt.bat to facilitate testing of amd64\python[_d].exe. In-Reply-To: <1205466358.32.0.414062205186.issue2284@psf.upfronthosting.co.za> Message-ID: <1205502985.13.0.53867870097.issue2284@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch. Committed as r61378 ---------- nosy: +loewis resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 14 14:57:07 2008 From: report at bugs.python.org (panhudie) Date: Fri, 14 Mar 2008 13:57:07 +0000 Subject: [issue2287] Problems using logging module with logging.basicConfig(level=logging.NOTSET) In-Reply-To: <1205503027.6.0.969200887551.issue2287@psf.upfronthosting.co.za> Message-ID: <1205503027.6.0.969200887551.issue2287@psf.upfronthosting.co.za> New submission from panhudie : The problem is in the logging.basicConfig(**kwargs): <...> level = kwargs.get("level") if level: root.setLevel(level) So you can not set the level like this, this logger will log WARNING(and above) instead of all the level: logging.basicConfig(level=logging.NOTSET) #logging.NOTSET == 0, root default level is WARNING I have seen this problem was fixed in the trunk, but not in python25 branch: level = kwargs.get("level") if level is not None: root.setLevel(level) ---------- components: Library (Lib) messages: 63527 nosy: panhudie severity: minor status: open title: Problems using logging module with logging.basicConfig(level=logging.NOTSET) type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 14 15:24:52 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 14 Mar 2008 14:24:52 +0000 Subject: [issue705836] struct.pack of floats in non-native endian order Message-ID: <1205504692.23.0.533427501479.issue705836@psf.upfronthosting.co.za> Mark Dickinson added the comment: Fixed in r61383. ---------- status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 14 16:47:47 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 14 Mar 2008 15:47:47 +0000 Subject: [issue2288] Confusing documentation for urllip.urlopen In-Reply-To: <1205509667.67.0.822182010256.issue2288@psf.upfronthosting.co.za> Message-ID: <1205509667.67.0.822182010256.issue2288@psf.upfronthosting.co.za> New submission from Mark Dickinson : Grant Edwards pointed out in a comp.lang.python posting that the documentation for urlopen in the urllib module appears to be self- contradictory: at http://docs.python.org/dev/library/urllib.html in the third-to-last paragraph for the urllib function, it says: "Alternatively, the optional proxies argument may be used to explicitly specify proxies..." and goes on to give examples. Then the second-to-last paragraph seems to directly contradict this: "The urlopen() function does not support explicit proxy specification. If you need to override environmental proxy settings, use URLopener, or a subclass such as FancyURLopener." I suspect that this second paragraph should just be deleted in its entirety. ---------- assignee: georg.brandl components: Documentation messages: 63529 nosy: georg.brandl, marketdickinson severity: normal status: open title: Confusing documentation for urllip.urlopen versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 14 17:10:52 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 14 Mar 2008 16:10:52 +0000 Subject: [issue2288] Confusing documentation for urllib.urlopen In-Reply-To: <1205509667.67.0.822182010256.issue2288@psf.upfronthosting.co.za> Message-ID: <1205511052.69.0.364247224588.issue2288@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- title: Confusing documentation for urllip.urlopen -> Confusing documentation for urllib.urlopen __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 14 17:30:03 2008 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Fri, 14 Mar 2008 16:30:03 +0000 Subject: [issue803422] sgmllib doesn't support hex or Unicode character references Message-ID: <1205512203.87.0.359612435125.issue803422@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: SGML TC 2 can be found here: http://www1.y12.doe.gov/capabilities/sgml/wg8/document/1955.htm See the section K.4.1 for hexidecimal character references. Since this is really an update to the SGML standard, and not part of the original, any support for this should be an optional feature. It's really only interesting on the web, where standards compliance is... a little on the lax side. It would be reasonable to enable this by default from htmllib (if not already supported in htmllib; I don't remember). I'm fairly sure hex character references are already supported in HTMLParser. ---------- nosy: +fdrake ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 14 18:21:36 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 14 Mar 2008 17:21:36 +0000 Subject: [issue871747] sys.exec_prefix does not work Message-ID: <1205515296.42.0.95200784505.issue871747@psf.upfronthosting.co.za> Ralf Schmitt added the comment: this works now: $ ./configure --prefix ~/soft/ --exec-prefix ~/soft/deb3 ... ~/release25-maint/ ~/soft/deb3/bin/python ralf at red ok Python 2.5.3a0 (release25-maint, Mar 14 2008, 18:19:57) [GCC 4.2.3 (Debian 4.2.3-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.prefix '/home/ralf/soft' >>> sys.exec_prefix '/home/ralf/soft/deb3' please close this issue. ---------- nosy: +schmir ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 14 18:42:36 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 14 Mar 2008 17:42:36 +0000 Subject: [issue998998] pickle bug - recursively memoizing class? Message-ID: <1205516556.76.0.722090608007.issue998998@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 14 18:45:46 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 14 Mar 2008 17:45:46 +0000 Subject: [issue1261390] import dynamic library bug? Message-ID: <1205516745.96.0.279074173233.issue1261390@psf.upfronthosting.co.za> Ralf Schmitt added the comment: maybe running ldconfig, or changing /etc/ld.so.conf would have helped. I'd say close this bug report. ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 14 18:59:00 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 14 Mar 2008 17:59:00 +0000 Subject: [issue1474680] pickling files works with protocol=2. Message-ID: <1205517540.58.0.473261988178.issue1474680@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir versions: +Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 14 19:16:54 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 14 Mar 2008 18:16:54 +0000 Subject: [issue1509798] replace dist/src/Tools/scripts/which.py with tmick's which Message-ID: <1205518614.46.0.855323235949.issue1509798@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 14 19:43:45 2008 From: report at bugs.python.org (John Love-Jensen) Date: Fri, 14 Mar 2008 18:43:45 +0000 Subject: [issue2289] os.path.normpath over-normalizes In-Reply-To: <1205520225.21.0.16693669718.issue2289@psf.upfronthosting.co.za> Message-ID: <1205520225.21.0.16693669718.issue2289@psf.upfronthosting.co.za> New submission from John Love-Jensen : I found a bug (or at least a shortcoming) in Python's os.path.normpath routine. It overly normalizes, at least for Unix and Unix-like systems (including Mac), and Windows. Example: x = os.path.join(".", "dog", "..", "cupcake.txt") print x x = os.path.normpath(x) print x If say "dog" is a symlink (any flavor of Unix (including OS X), or Win), there is a difference between ./dog/../cupcake.txt and ./cupcake.txt. In the OS, if dog is a symlink to fire/fly, the .. resolves relative to fire/fly. It should be safe to normalize this: ././././././././cupcake.txt --> ./cupcake.txt It should be safe to normalize this: .////////////////cupcake.txt --> ./cupcake.txt But this is not safe to normalize: ./x/../x/../x/../cupcake.txt --> ./cupcake.txt For example, if the directories look like this: ./cupcake.txt ./over/yonder/back/cupcake.txt ./x --> over/there ./over/there ./over/x --> yonder/aways ./over/yonder/aways ./over/yonder/x --> back/again ./over/yonder/back/again ./cupcake.txt refers to first cupcake. ./x/../x/../x/../cupcake.txt refers to the second cupcake. The os.path.realpath does the resolve, but sometimes the path-in-hand is for some arbitrary path, and not necessarily one on the local system, or if on the local files system may be relative based off from a different cwd. ---------- messages: 63533 nosy: eljay451 severity: minor status: open title: os.path.normpath over-normalizes type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 14 19:46:13 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 14 Mar 2008 18:46:13 +0000 Subject: [issue1644987] ./configure --prefix=/ breaks, won't build C modules Message-ID: <1205520373.9.0.163371014603.issue1644987@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- type: -> compile error versions: +Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 14 19:51:27 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 14 Mar 2008 18:51:27 +0000 Subject: [issue1653457] Python misbehaves when installed in / (patch attached) Message-ID: <1205520687.47.0.682858830149.issue1653457@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 14 20:10:23 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 14 Mar 2008 19:10:23 +0000 Subject: [issue1737127] re.findall hangs python completely Message-ID: <1205521823.91.0.354662210242.issue1737127@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 14 20:10:57 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 14 Mar 2008 19:10:57 +0000 Subject: [issue1737127] re.findall hangs python completely Message-ID: <1205521857.91.0.786478251647.issue1737127@psf.upfronthosting.co.za> Ralf Schmitt added the comment: ctrl-c should now work with python 2.5. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 14 20:19:13 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 14 Mar 2008 19:19:13 +0000 Subject: [issue1450807] Python build fails for gcc 4.x from Gnu Message-ID: <1205522353.79.0.15010614278.issue1450807@psf.upfronthosting.co.za> Ralf Schmitt added the comment: This should be closed: from http://python.org/download/releases/2.4.5/: "Since the release candidate, we received various reports that the this release may fail to build on current operating systems, in particular on OS X. We have made no attempt to fix these problems..." ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 14 20:21:57 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 14 Mar 2008 19:21:57 +0000 Subject: [issue1773632] Remove references to _xmlrpclib from xmlrpclib.py Message-ID: <1205522517.55.0.482298226022.issue1773632@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 14 20:29:50 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 14 Mar 2008 19:29:50 +0000 Subject: [issue1745722] please add wsgi to SimpleXMLRPCServer Message-ID: <1205522990.11.0.0373197497162.issue1745722@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 14 20:37:09 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 14 Mar 2008 19:37:09 +0000 Subject: [issue1702551] distutils sdist does not exclude SVN/CVS files on Windows Message-ID: <1205523429.44.0.327760801129.issue1702551@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 14 20:52:37 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Fri, 14 Mar 2008 19:52:37 +0000 Subject: [issue1540386] SocketServer.ForkingMixIn.collect_children() waits on pid 0 Message-ID: <1205524357.07.0.621835302413.issue1540386@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 14 21:36:10 2008 From: report at bugs.python.org (Trent Nelson) Date: Fri, 14 Mar 2008 20:36:10 +0000 Subject: [issue2286] Stack overflow exception caused by test_marshal on Windows x64 In-Reply-To: <1205499475.78.0.0465561571315.issue2286@psf.upfronthosting.co.za> Message-ID: <1205526970.38.0.839089193568.issue2286@psf.upfronthosting.co.za> Trent Nelson added the comment: Traced the problem down to the following minimal code snippet: import marshal s = 'c' + ('X' * 4*4) + '{' * 2**20 marshal.loads(s) When Python/marshal.c:18 MAX_MARSHAL_STACK_DEPTH is 2000 (which is what it is currently), marshal.loads() eventually overflows the stack in r_object(). There is a check in r_object() to avoid this though: if (p->depth > MAX_MARSHAL_STACK_DEPTH) { p->depth--; PyErr_SetString(PyExc_ValueError, "recursion limit exceeded"); return NULL; } On Windows x64, a value of 1964 raises the recursion limit exception above (which is what test_marshal is expecting). With a value of 1965, a C stack overflow exception is raised. So, MAX_MARSHAL_STACK_DEPTH needs to be <= 1964 in order to prevent this particular code from overflowing the stack on Win64 before we can raise a Python recursion limit exception. Was there any science behind choosing 2000 as the current value? Should a new value (e.g. 1500) be provided for only Win64, leaving everyone else at 2000? Interesting that Linux/BSD etc on AMD64 don't run into this. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 14 23:12:27 2008 From: report at bugs.python.org (Trent Nelson) Date: Fri, 14 Mar 2008 22:12:27 +0000 Subject: [issue2290] [PATCH] Update Lib/distutils/sysconfig.py to handle x64 Windows builds living in pcbuild/amd64. In-Reply-To: <1205532747.41.0.216781617297.issue2290@psf.upfronthosting.co.za> Message-ID: <1205532747.41.0.216781617297.issue2290@psf.upfronthosting.co.za> New submission from Trent Nelson : This patch is required in order to support x64 Windows builds that live in pcbuild/amd64. Without it, sysutils._python_build() returns the wrong directory, which causes the test_get_config_h_filename method in Lib/distutils/tests/test_sysconfig.py to fail. ---------- components: Library (Lib) files: sysconfig.py.patch keywords: patch messages: 63537 nosy: Trent.Nelson severity: normal status: open title: [PATCH] Update Lib/distutils/sysconfig.py to handle x64 Windows builds living in pcbuild/amd64. type: behavior versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9671/sysconfig.py.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 14 23:19:15 2008 From: report at bugs.python.org (Igor) Date: Fri, 14 Mar 2008 22:19:15 +0000 Subject: [issue2291] Catching all exceptions with 'object' In-Reply-To: <1205533155.39.0.576388305845.issue2291@psf.upfronthosting.co.za> Message-ID: <1205533155.39.0.576388305845.issue2291@psf.upfronthosting.co.za> New submission from Igor : I have discovered the following behaviour in 2.5, which I cannot explain: >>> try: ... raise ValueError("foo") ... except object: ... print "aiee!" ... Traceback (most recent call last): File "", line 2, in ValueError: foo >>> sys.version '2.5.1 (r251:54863, Jan 23 2008, 16:53:41) \n[GCC 4.2.2 (Gentoo 4.2.2 p1.0)]' >>> isinstance(ValueError("foo"), object) True At first I thought I misunderstood something about exceptions, but the wording of the try-statement leads me to believe that this should work. ValueError is a subclass of object and thus, I think, should be a match, thus catching the exception. I realize that all exceptions should inherit from Exception (BaseException?), but for the sake of consistence, shouldn't "except object" catch *anything* in python 2.5? I.e. be the equivalent of "except:". Is this a bug? If so, should this be fixed? ---------- components: None messages: 63538 nosy: zotbar1234 severity: normal status: open title: Catching all exceptions with 'object' type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 14 23:38:30 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Fri, 14 Mar 2008 22:38:30 +0000 Subject: [issue1450807] Python build fails for gcc 4.x from Gnu Message-ID: <1205534310.12.0.497184957529.issue1450807@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: I think this is still a problem at head, so it's not covered by the comment about the bugfix releases. But there is another issue covering the same thing... Since that one also has a patch and is a little newer, I'll point this one over there. ---------- resolution: -> duplicate status: open -> closed superseder: -> Make python build with gcc-4.2 on OS X 10.4.9 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 14 23:49:08 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 14 Mar 2008 22:49:08 +0000 Subject: [issue2286] Stack overflow exception caused by test_marshal on Windows x64 In-Reply-To: <1205499475.78.0.0465561571315.issue2286@psf.upfronthosting.co.za> Message-ID: <1205534948.68.0.805906554051.issue2286@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The situation was the same on win32 with the VC2005 debug build, some months ago. I think this is because of the extra stack checks added with "recent" versions of Visual Studio, together with the fact that local variables are not shared when optimizations are disabled. Can you try to raise the stack size on x64 builds? If 2Mb is enough for 32bit, 4Mb should be good in your case. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 00:10:54 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 14 Mar 2008 23:10:54 +0000 Subject: [issue2288] Confusing documentation for urllib.urlopen In-Reply-To: <1205509667.67.0.822182010256.issue2288@psf.upfronthosting.co.za> Message-ID: <1205536254.71.0.347090187674.issue2288@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r61392. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 00:12:46 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 14 Mar 2008 23:12:46 +0000 Subject: [issue871747] sys.exec_prefix does not work Message-ID: <1205536366.18.0.204462455105.issue871747@psf.upfronthosting.co.za> Georg Brandl added the comment: Done. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Mar 15 03:59:02 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 15 Mar 2008 02:59:02 +0000 Subject: [issue2291] Catching all exceptions with 'object' In-Reply-To: <1205533155.39.0.576388305845.issue2291@psf.upfronthosting.co.za> Message-ID: <1205549942.42.0.0545682986115.issue2291@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Py3k behavior seems to be better: Python 3.0a2+ (py3k:61137M, Feb 29 2008, 15:17:29) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin >>> try: ... raise ValueError("foo") ... except object: ... pass ... Traceback (most recent call last): File "", line 3, in TypeError: catching classes that do not inherit from BaseException is not allowed Something needs to be done for 2.6: at the minimum a warning should be issued under -3 option. ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 04:42:13 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 15 Mar 2008 03:42:13 +0000 Subject: [issue2290] [PATCH] Update Lib/distutils/sysconfig.py to handle x64 Windows builds living in pcbuild/amd64. In-Reply-To: <1205532747.41.0.216781617297.issue2290@psf.upfronthosting.co.za> Message-ID: <1205552533.51.0.229629298553.issue2290@psf.upfronthosting.co.za> Martin v. L?wis added the comment: That shouldn't apply to 2.5, right? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 12:01:05 2008 From: report at bugs.python.org (Thomas Lee) Date: Sat, 15 Mar 2008 11:01:05 +0000 Subject: [issue1810] AST compile() patch In-Reply-To: <1200095922.65.0.677669960272.issue1810@psf.upfronthosting.co.za> Message-ID: <1205578865.16.0.472421380484.issue1810@psf.upfronthosting.co.za> Thomas Lee added the comment: Updating the patch to apply cleanly against HEAD. Added file: http://bugs.python.org/file9672/ast-r03.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 15:01:47 2008 From: report at bugs.python.org (Trent Nelson) Date: Sat, 15 Mar 2008 14:01:47 +0000 Subject: [issue2290] [PATCH] Update Lib/distutils/sysconfig.py to handle x64 Windows builds living in pcbuild/amd64. In-Reply-To: <1205532747.41.0.216781617297.issue2290@psf.upfronthosting.co.za> Message-ID: <1205589707.12.0.309285907795.issue2290@psf.upfronthosting.co.za> Trent Nelson added the comment: Ah, I suspect not. (Unless the 64-bit python*.exe builds end up in pcbuild/amd64.) ---------- versions: -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 16:41:20 2008 From: report at bugs.python.org (Thomas Wouters) Date: Sat, 15 Mar 2008 15:41:20 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> New submission from Thomas Wouters : The attached patch adds the missing *-unpacking generalizations. Specifically: >>> a, b, *c = range(5) >>> *a, b, c = a, b, *c >>> a, b, c ([0, 1, 2], 3, 4) >>> [ *a, b, c ] [0, 1, 2, 3, 4] >>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ] >>> [ *item for item in L ] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] Also, yielding everything from an iterator: >>> def flatten(iterables): ... for it in iterables: ... yield *it ... >>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ] >>> flatten(L) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] ---------- assignee: gvanrossum components: Interpreter Core files: morestar.diff keywords: patch, patch messages: 63548 nosy: gvanrossum, twouters severity: normal status: open title: Missing *-unpacking generalizations versions: Python 3.0 Added file: http://bugs.python.org/file9673/morestar.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 17:05:24 2008 From: report at bugs.python.org (Skip Montanaro) Date: Sat, 15 Mar 2008 16:05:24 +0000 Subject: [issue1158] %f format for datetime objects In-Reply-To: <1189650403.5.0.731044089134.issue1158@psf.upfronthosting.co.za> Message-ID: <1205597124.04.0.304630385497.issue1158@psf.upfronthosting.co.za> Skip Montanaro added the comment: Checking this in. All tests pass. Have for quite awhile. rev 61402. ---------- assignee: -> skip.montanaro __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 17:09:27 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 15 Mar 2008 16:09:27 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1205597367.68.0.756247281833.issue2292@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This was discussed years ago and never got enough support: http://mail.python.org/pipermail/python-dev/2005-October/057177.html ---------- nosy: +belopolsky type: -> feature request __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 17:12:14 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 15 Mar 2008 16:12:14 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1205597534.13.0.0917258826527.issue2292@psf.upfronthosting.co.za> Guido van Rossum added the comment: Didn't you say it does sets too? Does this work? a = [1, 2, 3] {1, *a, 0, 4} # {0, 1, 2, 3, 4} How about dicts? kwds = {'z': 0, 'w': 12} {'x': 1, 'y': 2, **kwds} # {'x': 1, 'y': 2, 'z': 0, 'w': 12} Also, now that we support [*a, b, c] shouldn't we also support foo(*a, b, c) ? __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 17:14:25 2008 From: report at bugs.python.org (Thomas Wouters) Date: Sat, 15 Mar 2008 16:14:25 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205597534.13.0.0917258826527.issue2292@psf.upfronthosting.co.za> Message-ID: <9e804ac0803150914s4057e405v89ee099d1f1493e9@mail.gmail.com> Thomas Wouters added the comment: On Sat, Mar 15, 2008 at 9:12 AM, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > Didn't you say it does sets too? Does this work? > a = [1, 2, 3] > {1, *a, 0, 4} # {0, 1, 2, 3, 4} Yes. > > > How about dicts? > kwds = {'z': 0, 'w': 12} > {'x': 1, 'y': 2, **kwds} # {'x': 1, 'y': 2, 'z': 0, 'w': 12} Not yet. > > > Also, now that we support > > [*a, b, c] > > shouldn't we also support > > foo(*a, b, c) > Sure. (And also 'foo(*a, *b, *c)'?) But have you taken a look lately at the function definition grammar? I need some time to sort it out :) Added file: http://bugs.python.org/file9674/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080315/a199ac0e/attachment.txt From report at bugs.python.org Sat Mar 15 17:18:09 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 15 Mar 2008 16:18:09 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1205597889.59.0.591051962702.issue2292@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looking at the flatten() example I'm curious -- how come the output of >>> flatten(L) is displayed as a list rather than as ? Also, do I understand correctly that yield *(1, 2, 3) is equivalent to yield 1 yield 2 yield 3 ? (That's really cool.) __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 17:22:38 2008 From: report at bugs.python.org (Thomas Wouters) Date: Sat, 15 Mar 2008 16:22:38 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205597889.59.0.591051962702.issue2292@psf.upfronthosting.co.za> Message-ID: <9e804ac0803150922s4f63f223h6962828899614d23@mail.gmail.com> Thomas Wouters added the comment: On Sat, Mar 15, 2008 at 9:18 AM, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > Looking at the flatten() example I'm curious -- how come the output of > > >>> flatten(L) > > is displayed as a list rather than as ? > It's a typo. It should've been list(flatten(L)) :-) (see the tests included in the patch.) Added file: http://bugs.python.org/file9675/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080315/bc5a815c/attachment-0001.txt From report at bugs.python.org Sat Mar 15 17:25:51 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 15 Mar 2008 16:25:51 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1205598351.14.0.260388814254.issue2292@psf.upfronthosting.co.za> Changes by Guido van Rossum : Removed file: http://bugs.python.org/file9674/unnamed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 17:25:56 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 15 Mar 2008 16:25:56 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1205598356.02.0.0196891064369.issue2292@psf.upfronthosting.co.za> Changes by Guido van Rossum : Removed file: http://bugs.python.org/file9675/unnamed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 17:41:09 2008 From: report at bugs.python.org (BODIN) Date: Sat, 15 Mar 2008 16:41:09 +0000 Subject: [issue2293] Missing case / switch / evaluate In-Reply-To: <1205599269.05.0.609261957531.issue2293@psf.upfronthosting.co.za> Message-ID: <1205599269.05.0.609261957531.issue2293@psf.upfronthosting.co.za> New submission from BODIN : I am not the code : if toto == 1: ... elsif toto == 2: ... elsif In ADA for example : case C is -- 4 Start a case statement when Red => Result := 1; when Blue =>Result := 2; when Black .. Brown => Result := 3; when Orange | Indigo => Result := 4; when others => Result := 5;required for unspecified cases. end case; Is it not better? ---------- components: Interpreter Core messages: 63555 nosy: dbodin severity: normal status: open title: Missing case / switch / evaluate versions: 3rd party __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 17:43:47 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 15 Mar 2008 16:43:47 +0000 Subject: [issue2293] Missing case / switch / evaluate In-Reply-To: <1205599269.05.0.609261957531.issue2293@psf.upfronthosting.co.za> Message-ID: <1205599427.19.0.589457608852.issue2293@psf.upfronthosting.co.za> Christian Heimes added the comment: This is a bug tracker and not a help forum. Please use the Python general mailinglist to get help. Your problem can be solved with a pattern called "dispatcher dict". ---------- nosy: +tiran resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 17:55:10 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 15 Mar 2008 16:55:10 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1205600110.43.0.159173072742.issue2292@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: It looks like I completely missed PEP 3132. Sorry for a misleading comment above. At least I am not alone: "A little new feature in Python 3 that many overviews don't tell you about: extended unpacking." http://pyside.blogspot.com/2007/10/new-in-python-3-extended- unpacking.html __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 18:52:04 2008 From: report at bugs.python.org (Mark Summerfield) Date: Sat, 15 Mar 2008 17:52:04 +0000 Subject: [issue2278] [Py30a3] xml.parsers.expat recognizes encoding="utf-8" but not encoding="utf8" In-Reply-To: <1205319843.23.0.2378782834.issue2278@psf.upfronthosting.co.za> Message-ID: <1205603524.76.0.262645294875.issue2278@psf.upfronthosting.co.za> Mark Summerfield added the comment: You're right that the parser should not recognise "utf8" since it isn't correct XML (as per the references you gave). I made the mistake because I used the etree module and wrote an XML file with encoding "utf8" which etree accepted. I've now switched to using "UTF-8". __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 19:58:35 2008 From: report at bugs.python.org (Greg Kochanski) Date: Sat, 15 Mar 2008 18:58:35 +0000 Subject: [issue2294] Bug in Pickle protocol involving __setstate__ In-Reply-To: <1205607515.59.0.862171292483.issue2294@psf.upfronthosting.co.za> Message-ID: <1205607515.59.0.862171292483.issue2294@psf.upfronthosting.co.za> New submission from Greg Kochanski : If we have a hierarchy of classes, and we use __getstate__/__setstate__, the wrong class' __setstate__ gets called. Possibly, this is a documentation problem, but here goes: Take two classes, A and B, where B is the child of A. Construct a B. Pickle it. Unpickle it, and you find that the __setstate__ function for A is called with the result produced by B.__getstate__(). This is wrong. An example follows: import pickle as P class A(object): def __init__(self, a): print 'A.__init__' self.a = a def __getstate__(self): print 'A.__getstate' return self.a def __setstate__(self, upstate): print 'A.__setstate', upstate self.a = upstate class B(A): def __init__(self, a, b): print 'B.__init__' A.__init__(self, a) self.b = b def __getstate__(self): print 'B.__getstate' return (A.__getstate__(self), self.b) def __setstate(self, upstate): # This never gets called! print 'B.__setstate', upstate A.__setstate__(self, upstate[0]) self.b = upstate[1] def __repr__(self): return '' % (self.a, self.b) q = B(1,2) print '---' r = P.loads(P.dumps(q, 0)) print 'q=', q print 'r=', r Now, run it: $ python foo.py B.__init__ A.__init__ --- B.__getstate A.__getstate A.__setstate (1, 2) q= r= Traceback (most recent call last): File "foo.py", line 44, in print 'r=', r File "foo.py", line 37, in __repr__ return '' % (self.a, self.b) AttributeError: 'B' object has no attribute 'b' $ Note that this problem doesn't get noticed in the common case where you simply pass __dict__ around from __getstate__ to __setstate__. However, it exists in many other use cases. ---------- components: Library (Lib) messages: 63559 nosy: gpk severity: normal status: open title: Bug in Pickle protocol involving __setstate__ type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 20:18:46 2008 From: report at bugs.python.org (Greg Kochanski) Date: Sat, 15 Mar 2008 19:18:46 +0000 Subject: [issue2295] cPickle corner case - docs or bug? In-Reply-To: <1205608726.73.0.310899298914.issue2295@psf.upfronthosting.co.za> Message-ID: <1205608726.73.0.310899298914.issue2295@psf.upfronthosting.co.za> New submission from Greg Kochanski : If you attempt to cPickle a class, cPickle checks that it can get the identical class by importing it. If that check fails, it reports: Traceback (most recent call last): ... "/usr/local/lib/python2.5/site-packages/newstem2-0.12.3-py2.5-linux-i686.egg/newstem2/stepperclient.py", line 41, in send s = cPickle.dumps( args, cPickle.HIGHEST_PROTOCOL) cPickle.PicklingError: Can't pickle : it's not the same object as test_simple2.aModel $ Normally, this is probably a good thing. However, if you do an import using the "imp" module, via imp.load_module(name, fd, pn, desc), you get the "same" module containing the "same" classes, but everything is duplicated at different addresses. In other words, you get distinct class objects from what cPickle will find. Consequently, the when cPickle makes the "is" comparison between what you gave it and what it can find, it will fail and cause an error. In this case, the error is wrong. I know that the aModel classes come from the same file and are member-for-member the same. This may well be a documentation error: it needs to mention this test and note that classes in modules imported via imp are not picklable. Or, imp needs to note that its results are not picklable. Or both. Or, maybe it's something that should be fixed, though I'm not sure if there is a general solution that will always behave well. ---------- assignee: georg.brandl components: Documentation, Library (Lib) messages: 63560 nosy: georg.brandl, gpk severity: normal status: open title: cPickle corner case - docs or bug? type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 20:21:03 2008 From: report at bugs.python.org (Tim Gordon) Date: Sat, 15 Mar 2008 19:21:03 +0000 Subject: [issue2294] Bug in Pickle protocol involving __setstate__ In-Reply-To: <1205607515.59.0.862171292483.issue2294@psf.upfronthosting.co.za> Message-ID: <47DC2122.9060300@aleph17.co.uk> Tim Gordon added the comment: You've missed off the two underscores after the name __setstate__ :p ---------- nosy: +QuantumTim __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 20:56:48 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 15 Mar 2008 19:56:48 +0000 Subject: [issue1810] AST compile() patch In-Reply-To: <1200095922.65.0.677669960272.issue1810@psf.upfronthosting.co.za> Message-ID: <1205611008.7.0.901693558657.issue1810@psf.upfronthosting.co.za> Georg Brandl added the comment: I'll try to handle it this weekend. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 21:15:54 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 15 Mar 2008 20:15:54 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1205612154.0.0.862492058208.issue2292@psf.upfronthosting.co.za> Georg Brandl added the comment: Just a nit: the syntax error message for invalid starred expressions should be changed from "can use starred expression only as assignment target". ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 21:17:00 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 15 Mar 2008 20:17:00 +0000 Subject: [issue2294] Bug in Pickle protocol involving __setstate__ In-Reply-To: <1205607515.59.0.862171292483.issue2294@psf.upfronthosting.co.za> Message-ID: <1205612220.01.0.329675673954.issue2294@psf.upfronthosting.co.za> Georg Brandl added the comment: Closing as invalid. ---------- nosy: +georg.brandl resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 23:30:22 2008 From: report at bugs.python.org (Neal Norwitz) Date: Sat, 15 Mar 2008 22:30:22 +0000 Subject: [issue2291] Catching all exceptions with 'object' In-Reply-To: <1205533155.39.0.576388305845.issue2291@psf.upfronthosting.co.za> Message-ID: <1205620222.39.0.25398481271.issue2291@psf.upfronthosting.co.za> Neal Norwitz added the comment: See PEP 352. Currently this is slated for python 2.8. Perhaps the schedule should be sped up a bit in light the current release schedule. Brett, any comments? We should add all the warnings from PEP 352 with the -3 flag to 2.6. ---------- nosy: +brett.cannon, nnorwitz versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 23:35:33 2008 From: report at bugs.python.org (Trent Nelson) Date: Sat, 15 Mar 2008 22:35:33 +0000 Subject: [issue2296] [PATCH] Tcl/Tk 8.4.16 patches needed to get an x64 Windows build In-Reply-To: <1205620533.13.0.0700129427319.issue2296@psf.upfronthosting.co.za> Message-ID: <1205620533.13.0.0700129427319.issue2296@psf.upfronthosting.co.za> New submission from Trent Nelson : Martin, I've attached two patches required in order to get Tcl/Tk 8.4.16 to successfully compile on Windows x64. I haven't included the patch to external-amd64.bat (and pcbuild/readme.txt with updated build instructions) yet as I wanted to confirm how you apply updates to the external/ branch such that the buildbots can pick it up as well. Note that I also dropped a generic standalone sed.exe into tk-8.4.16/win, which is required for reasons that I couldn't be bothered digging into in makefile.vc. You can grab it from http://svn.onresolve.com/external/tags/tcl-8.4.18.1/win/sed.exe. Also, wanted to query the role of 'COMPILERFLAGS=-DWINVER=0x0500' in your recommended nmake flags; do we still need it? I used the following for x64 debug builds: ..\tcl8.4.16\win>nmake -f makefile.vc DEBUG=1 MACHINE=AMD64 INSTALLDIR=../../tcltk64 clean all install And for tk: ..\tk8.4.16\win>nmake -f makefile.vc DEBUG=1 MACHINE=AMD64 TCLDIR=../../tcl8.4.16 INSTALLDIR=../../tcltk64 clean all install Let me know how you want to deal with the tcl/tk patches and then we can look at fixing external-amd64.bat and updating pcbuild/readme.txt. ---------- components: Tkinter files: tk-8.4.16.patch keywords: patch messages: 63566 nosy: Trent.Nelson, loewis severity: normal status: open title: [PATCH] Tcl/Tk 8.4.16 patches needed to get an x64 Windows build versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9676/tk-8.4.16.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 23:36:41 2008 From: report at bugs.python.org (Trent Nelson) Date: Sat, 15 Mar 2008 22:36:41 +0000 Subject: [issue2296] [PATCH] Tcl/Tk 8.4.16 patches needed to get an x64 Windows build In-Reply-To: <1205620533.13.0.0700129427319.issue2296@psf.upfronthosting.co.za> Message-ID: <1205620601.3.0.987001328084.issue2296@psf.upfronthosting.co.za> Trent Nelson added the comment: And the tcl patch... Added file: http://bugs.python.org/file9677/tcl-8.4.16.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 15 23:47:48 2008 From: report at bugs.python.org (Neal Norwitz) Date: Sat, 15 Mar 2008 22:47:48 +0000 Subject: [issue2185] code objects should conserve memory In-Reply-To: <1203907300.87.0.511382024936.issue2185@psf.upfronthosting.co.za> Message-ID: <1205621268.51.0.786175374518.issue2185@psf.upfronthosting.co.za> Neal Norwitz added the comment: Marshal is the wrong place for this sort of thing (the code object is where it should be done). I botched the analysis. The case is common, but only for the empty tuple which I forgot to ignore. (None,) was a common case when I measured it. We should measure the actual memory savings before anything is implemented. To answer your question, the case were this happens is: def foo(self): return self.self ---------- resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 01:25:29 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 16 Mar 2008 00:25:29 +0000 Subject: [issue2296] [PATCH] Tcl/Tk 8.4.16 patches needed to get an x64 Windows build In-Reply-To: <1205620533.13.0.0700129427319.issue2296@psf.upfronthosting.co.za> Message-ID: <1205627129.44.0.326506504849.issue2296@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: -> loewis components: +Windows keywords: +64bit priority: -> normal type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 04:00:04 2008 From: report at bugs.python.org (Brett Cannon) Date: Sun, 16 Mar 2008 03:00:04 +0000 Subject: [issue2291] Catching all exceptions with 'object' In-Reply-To: <1205620222.39.0.25398481271.issue2291@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: On Sat, Mar 15, 2008 at 5:30 PM, Neal Norwitz wrote: > > Neal Norwitz added the comment: > > See PEP 352. Currently this is slated for python 2.8. Perhaps the > schedule should be sped up a bit in light the current release schedule. > Brett, any comments? We should add all the warnings from PEP 352 with > the -3 flag to 2.6. We could add warnings for everything slated to go in 3.0. As for 2.x, I don't think tossing in warnings for 2.6 is good, but it could be made a PendingDeprecationWarning, with 2.7 being full DeprecationWarning. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 06:24:46 2008 From: report at bugs.python.org (Douglas Greiman) Date: Sun, 16 Mar 2008 05:24:46 +0000 Subject: [issue2297] Patch for fatal stack overflow in Windows caused by -v In-Reply-To: <1205645085.91.0.398085675156.issue2297@psf.upfronthosting.co.za> Message-ID: <1205645085.91.0.398085675156.issue2297@psf.upfronthosting.co.za> New submission from Douglas Greiman : When python is invoked with -v or -vv under Windows, the process of importing the codec for sys.stderr causes a message to be written to stderr, which in turn causes the codec to be recursively imported. Sometimes the stack overflow exception is swallowed, other times it is not. The bug depends on the particular locale settings of the Windows machine. To reproduce: python_d.exe -v and look for many repeated imports of encodings. Patch is attached. ---------- components: Interpreter Core files: py3k-win-codec-recursion-20080315.diff keywords: patch messages: 63570 nosy: dgreiman severity: normal status: open title: Patch for fatal stack overflow in Windows caused by -v type: crash versions: Python 3.0 Added file: http://bugs.python.org/file9678/py3k-win-codec-recursion-20080315.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 07:00:40 2008 From: report at bugs.python.org (Douglas Greiman) Date: Sun, 16 Mar 2008 06:00:40 +0000 Subject: [issue2298] Patch for "string without null bytes" check in getargs.c In-Reply-To: <1205647240.0.0.304059938651.issue2298@psf.upfronthosting.co.za> Message-ID: <1205647240.0.0.304059938651.issue2298@psf.upfronthosting.co.za> New submission from Douglas Greiman : Code in getargs.c:convertsimple incorrectly uses PyUnicode_GetSize instead of PyString_GET_SIZE when checking whether a bytes object (encoded string) contains a null byte. To reproduce: __import__('\u0080') Incorrect behavior: TypeError: __import__() argument 1 must be string without null bytes, not str Correct behavior: ImportError Note the lack of null bytes: >>> '\u0080'.encode('utf-8') b'\xc2\x80' ---------- components: Interpreter Core files: py3k-getargs-null-bytes-20080315.diff keywords: patch messages: 63571 nosy: dgreiman severity: normal status: open title: Patch for "string without null bytes" check in getargs.c type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file9679/py3k-getargs-null-bytes-20080315.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 07:11:08 2008 From: report at bugs.python.org (Douglas Greiman) Date: Sun, 16 Mar 2008 06:11:08 +0000 Subject: [issue2299] Minor typos in newtypes.rst In-Reply-To: <1205647868.72.0.36374739864.issue2299@psf.upfronthosting.co.za> Message-ID: <1205647868.72.0.36374739864.issue2299@psf.upfronthosting.co.za> New submission from Douglas Greiman : Fix three minor typos in Doc/extending/newtypes.rst ---------- assignee: georg.brandl components: Documentation files: Doc-newtypes-typos-20080315.diff keywords: patch messages: 63572 nosy: dgreiman, georg.brandl severity: minor status: open title: Minor typos in newtypes.rst type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9680/Doc-newtypes-typos-20080315.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 09:00:40 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 16 Mar 2008 08:00:40 +0000 Subject: [issue2299] Minor typos in newtypes.rst In-Reply-To: <1205647868.72.0.36374739864.issue2299@psf.upfronthosting.co.za> Message-ID: <1205654440.34.0.0922422899954.issue2299@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks for the patch, committed as r61414. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 13:33:58 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 16 Mar 2008 12:33:58 +0000 Subject: [issue2300] make html fails In-Reply-To: <1205670838.75.0.758086838639.issue2300@psf.upfronthosting.co.za> Message-ID: <1205670838.75.0.758086838639.issue2300@psf.upfronthosting.co.za> New submission from Christian Heimes : File "/home/heimes/dev/python/trunk/Doc/tools/sphinx/builder.py", line 236, in write self.prepare_writing(docnames) File "/home/heimes/dev/python/trunk/Doc/tools/sphinx/builder.py", line 301, in prepare_writing self.load_indexer(docnames) File "/home/heimes/dev/python/trunk/Doc/tools/sphinx/builder.py", line 489, in load_indexer self.indexer.load(f, 'json') File "/home/heimes/dev/python/trunk/Doc/tools/sphinx/search.py", line 70, in load for (k, v) in frozen[2].iteritems()) AttributeError: 'list' object has no attribute 'iteritems' make: *** [build] Fehler 1 ---------- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 63574 nosy: georg.brandl, tiran priority: high severity: normal status: open title: make html fails type: crash versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 13:50:55 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 16 Mar 2008 12:50:55 +0000 Subject: [issue2300] make html fails In-Reply-To: <1205670838.75.0.758086838639.issue2300@psf.upfronthosting.co.za> Message-ID: <1205671855.72.0.805991838596.issue2300@psf.upfronthosting.co.za> Georg Brandl added the comment: This should have been fixed a long time ago. Try running "make clean; make update; make html"? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 14:37:33 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Sun, 16 Mar 2008 13:37:33 +0000 Subject: [issue2301] [Py3k] In-Reply-To: <1205674653.18.0.28557522559.issue2301@psf.upfronthosting.co.za> Message-ID: <1205674653.18.0.28557522559.issue2301@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : Following code # coding: utf-8 print "?" outputs C:\Documents and Settings\WhiteRabbit>py3k b.py File "b.py", line 3 print "?" as expected, but following code # coding: cp932 print "?" outputs C:\Documents and Settings\WhiteRabbit>py3k a.py File "a.py", line 4 [22605 refs] Probably this happens because PyUnicode_DecodeUTF8 at Python/pythonrun.c(1757) assumes err->text to be UTF8, but this is not true when source file is not encoded with UTF8. # Sorry there is no patch. ---------- components: None messages: 63576 nosy: ocean-city severity: normal status: open title: [Py3k] type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 14:38:22 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Sun, 16 Mar 2008 13:38:22 +0000 Subject: [issue2301] [Py3k] No text shown when SyntaxError (when not UTF8) In-Reply-To: <1205674653.18.0.28557522559.issue2301@psf.upfronthosting.co.za> Message-ID: <1205674702.61.0.677427170044.issue2301@psf.upfronthosting.co.za> Changes by Hirokazu Yamamoto : ---------- title: [Py3k] -> [Py3k] No text shown when SyntaxError (when not UTF8) __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 15:04:14 2008 From: report at bugs.python.org (Facundo Batista) Date: Sun, 16 Mar 2008 14:04:14 +0000 Subject: [issue2300] make html fails In-Reply-To: <1205670838.75.0.758086838639.issue2300@psf.upfronthosting.co.za> Message-ID: <1205676254.26.0.0283276901452.issue2300@psf.upfronthosting.co.za> Facundo Batista added the comment: I was suffering of the same error, so: make clean: ok make update: svn update tools/pygments svn: requerimiento REPORT fall? en '/projects/!svn/vcc/default' svn: Target path does not exist make: *** [update] Error 1 Anyway, I went further and made... make html: and it worked ok! ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 15:47:15 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Sun, 16 Mar 2008 14:47:15 +0000 Subject: [issue2301] [Py3k] No text shown when SyntaxError (when not UTF8) In-Reply-To: <1205674653.18.0.28557522559.issue2301@psf.upfronthosting.co.za> Message-ID: <1205678835.33.0.872597033704.issue2301@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Probably same problem exists in PyErr_ProgramText(). __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 16:15:57 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sun, 16 Mar 2008 15:15:57 +0000 Subject: [issue2302] Uses of SocketServer.BaseServer.shutdown have a race In-Reply-To: <1205680557.19.0.19509352533.issue2302@psf.upfronthosting.co.za> Message-ID: <1205680557.19.0.19509352533.issue2302@psf.upfronthosting.co.za> New submission from Jeffrey Yasskin : With the code as it stands, calls to shutdown that happen before serve_forever enters its loop will deadlock, and there's no simple way for the user to avoid this. The attached patch prevents the deadlock and allows multiple serve_forever..shutdown cycles, but it's pretty complicated. I could make it a lot simpler by making shutdown permanent: any later serve_forever calls would return immediately. A third choice would be to add a .serve_in_thread function that returns a token that can be used to shut down exactly that loop, instead of putting .shutdown() on the server. Any opinions? ---------- components: Library (Lib) files: race_free_shutdown.patch keywords: patch, patch messages: 63579 nosy: jyasskin severity: normal status: open title: Uses of SocketServer.BaseServer.shutdown have a race type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9681/race_free_shutdown.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 16:45:43 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sun, 16 Mar 2008 15:45:43 +0000 Subject: [issue2303] isinstance is 4x as slow as in 2.5 because the common case raises In-Reply-To: <1205682342.69.0.872031501346.issue2303@psf.upfronthosting.co.za> Message-ID: <1205682342.69.0.872031501346.issue2303@psf.upfronthosting.co.za> New submission from Jeffrey Yasskin : r58099 added an exception to the common case of PyObject_IsInstance(), when the class has no __instancecheck__ attribute. This makes isinstance(3, int) take 4x as long as in python 2.5. ---------- assignee: gvanrossum components: Interpreter Core messages: 63580 nosy: gvanrossum, jyasskin severity: normal status: open title: isinstance is 4x as slow as in 2.5 because the common case raises type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 16:47:28 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 16 Mar 2008 15:47:28 +0000 Subject: [issue2301] [Py3k] No text shown when SyntaxError (when not UTF8) In-Reply-To: <1205674653.18.0.28557522559.issue2301@psf.upfronthosting.co.za> Message-ID: <1205682448.82.0.278431875116.issue2301@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This will involve quite some work to fix. When fetching the code, the source encoding must be recognized. Contributions are welcome. (I personally consider this issue minor, as I would encourage users to use UTF-8 as the source encoding, anyway). ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 17:10:27 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 16 Mar 2008 16:10:27 +0000 Subject: [issue2298] Patch for "string without null bytes" check in getargs.c In-Reply-To: <1205647240.0.0.304059938651.issue2298@psf.upfronthosting.co.za> Message-ID: <1205683827.6.0.515446295801.issue2298@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Note that this patch will expose a bug fixed in issue1950. (See msg63363.) I suggest that the import.c part of issue1950 and this go together. Alexandre? ---------- nosy: +alexandre.vassalotti, belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 17:32:19 2008 From: report at bugs.python.org (Tim Golden) Date: Sun, 16 Mar 2008 16:32:19 +0000 Subject: [issue2304] subprocess under windows fails to quote properly under Windows when shell=True In-Reply-To: <1205685138.96.0.183811169845.issue2304@psf.upfronthosting.co.za> Message-ID: <1205685138.96.0.183811169845.issue2304@psf.upfronthosting.co.za> New submission from Tim Golden : The subprocess.Popen function reorganises the command line for process creation when shell=True is passed in under Windows. It runs the existing executable & arguments as arguments to %COMSPEC% /c. However this fails when a second parameter (typically a filename) has an embedded space. The patch attached adds extra parameters in this case and adds appropriate unit tests. Frankly I'm new to unittests and I more-or-less cloned an existing one to make this work. Happy to be corrected if there's things done wrong &c. ---------- components: Library (Lib) files: subprocess-r61420.patch keywords: patch messages: 63583 nosy: tim.golden severity: normal status: open title: subprocess under windows fails to quote properly under Windows when shell=True type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9682/subprocess-r61420.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 17:33:50 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 16 Mar 2008 16:33:50 +0000 Subject: [issue2291] Catching all exceptions with 'object' In-Reply-To: <1205533155.39.0.576388305845.issue2291@psf.upfronthosting.co.za> Message-ID: <1205685230.61.0.727774431905.issue2291@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I thought some more about this issue and the current behavior seems wrong and potentially dangerous. Consider the following code: class x: pass class y(x): pass try: raise y except y: print "a" except: print "b" It prints 'b'. Now, suppose in preparation for 3.0 transition someone adds "__metaclass__ = type" to the module with that code. The result: it prints 'a'. Since the difference in behavior is in error handling code, which in my experience is often not thoroughly tested, the bug introduced by a seemingly innocuous move from old to new style classes is likely to trigger in the worst possible moment. (For example a wrong roll-back logic is applied after a failed database commit.) My understanding is that the current logic of bypassing the subclass check in PyErr_GivenExceptionMatches in the case of new style class which is not a subclass of BaseException, is designed to support string exceptions. Maybe a better choice would be to exclude only string subclasses from a subclass check. I will submit a patch if others agree that this approach is worth considering. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 17:36:27 2008 From: report at bugs.python.org (Tim Golden) Date: Sun, 16 Mar 2008 16:36:27 +0000 Subject: [issue2304] subprocess under windows fails to quote properly when shell=True In-Reply-To: <1205685138.96.0.183811169845.issue2304@psf.upfronthosting.co.za> Message-ID: <1205685387.69.0.713484952447.issue2304@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- title: subprocess under windows fails to quote properly under Windows when shell=True -> subprocess under windows fails to quote properly when shell=True __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 17:53:04 2008 From: report at bugs.python.org (Brett Cannon) Date: Sun, 16 Mar 2008 16:53:04 +0000 Subject: [issue2291] Catching all exceptions with 'object' In-Reply-To: <1205533155.39.0.576388305845.issue2291@psf.upfronthosting.co.za> Message-ID: <1205686384.72.0.701962445687.issue2291@psf.upfronthosting.co.za> Brett Cannon added the comment: Actually, if you go back to 2.4, before BaseException even existed, a try/except with a new-style class in the 'except' clause was also possible. Actual enforcement of what can be in an 'except' clause is a new thing added by PEP 352. Suddenly making this any more than a warning will be too aggressive. And the PEP already stated the transition path. As I said, I have no problem speeding up PendingDeprecationWarnings in 2.6 and adding Py3K warnings now, but anything more severe in 2.6 (i.e., a DeprecationWarning flat-out) would require python-dev approval. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 18:00:30 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 16 Mar 2008 17:00:30 +0000 Subject: [issue2289] os.path.normpath over-normalizes In-Reply-To: <1205520225.21.0.16693669718.issue2289@psf.upfronthosting.co.za> Message-ID: <1205686830.52.0.232393785333.issue2289@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This is a documented feature: """ normpath(path) Normalize a pathname. ... It should be understood that this may change the meaning of the path if it contains symbolic links! """ See http://docs.python.org/lib/module-os.path.html . ---------- nosy: +belopolsky type: behavior -> feature request __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 18:20:30 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sun, 16 Mar 2008 17:20:30 +0000 Subject: [issue1193577] add server.shutdown() method to SocketServer Message-ID: <1205688030.85.0.981742423747.issue1193577@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: So this has a race. See issue 2302 to discuss a fix. ---------- resolution: -> fixed status: open -> closed superseder: -> Uses of SocketServer.BaseServer.shutdown have a race _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 16 18:40:41 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 16 Mar 2008 17:40:41 +0000 Subject: [issue1689] Backport PEP 3141 to 2.6 In-Reply-To: <1198375234.59.0.21975095893.issue1689@psf.upfronthosting.co.za> Message-ID: <1205689241.2.0.335140595203.issue1689@psf.upfronthosting.co.za> Guido van Rossum added the comment: Why can't this be closed? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 20:33:51 2008 From: report at bugs.python.org (Trent Nelson) Date: Sun, 16 Mar 2008 19:33:51 +0000 Subject: [issue2296] [PATCH] Tcl/Tk 8.4.16 patches needed to get an x64 Windows build In-Reply-To: <1205620533.13.0.0700129427319.issue2296@psf.upfronthosting.co.za> Message-ID: <1205696031.75.0.396247672446.issue2296@psf.upfronthosting.co.za> Trent Nelson added the comment: Oh, another question, do we use tix for anything anymore? __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 20:47:13 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sun, 16 Mar 2008 19:47:13 +0000 Subject: [issue1689] Backport PEP 3141 to 2.6 In-Reply-To: <1198375234.59.0.21975095893.issue1689@psf.upfronthosting.co.za> Message-ID: <1205696833.49.0.360411488081.issue1689@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: It can. :) ---------- status: pending -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:00:11 2008 From: report at bugs.python.org (Daniel Krech) Date: Sun, 16 Mar 2008 21:00:11 +0000 Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into account In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za> Message-ID: <1205701211.95.0.188184526603.issue2235@psf.upfronthosting.co.za> Changes by Daniel Krech : ---------- nosy: +eikeon __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:05:53 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 16 Mar 2008 21:05:53 +0000 Subject: [issue2303] isinstance is 4x as slow as in 2.5 because the common case raises In-Reply-To: <1205682342.69.0.872031501346.issue2303@psf.upfronthosting.co.za> Message-ID: <1205701553.25.0.975325100778.issue2303@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- type: behavior -> performance __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:06:10 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 16 Mar 2008 21:06:10 +0000 Subject: [issue2305] Update What's new in 2.6 In-Reply-To: <1205701570.77.0.602719062541.issue2305@psf.upfronthosting.co.za> Message-ID: <1205701570.77.0.602719062541.issue2305@psf.upfronthosting.co.za> New submission from Guido van Rossum : Somebody will have to write the "What's new in 2.6" document. I'm doing 3.0 but I'm not doing 2.6 as well. ---------- assignee: georg.brandl components: Documentation messages: 63591 nosy: georg.brandl, gvanrossum severity: normal status: open title: Update What's new in 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:06:13 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 16 Mar 2008 21:06:13 +0000 Subject: [issue1285086] urllib.quote is too slow Message-ID: <1205701573.0.0.105709522435.issue1285086@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- type: feature request -> performance _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 16 22:06:20 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 16 Mar 2008 21:06:20 +0000 Subject: [issue849662] reading shelves is really slow Message-ID: <1205701580.32.0.709302453254.issue849662@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- type: -> performance ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Mar 16 22:06:27 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 16 Mar 2008 21:06:27 +0000 Subject: [issue984219] hotspot.stats.load is very slow Message-ID: <1205701587.71.0.173826928025.issue984219@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- type: -> performance ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Mar 16 22:06:43 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 16 Mar 2008 21:06:43 +0000 Subject: [issue2306] Update What's new in 3.0 In-Reply-To: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za> Message-ID: <1205701603.67.0.309619584416.issue2306@psf.upfronthosting.co.za> New submission from Guido van Rossum : I will be working on this. ---------- assignee: gvanrossum components: Documentation messages: 63592 nosy: gvanrossum priority: high severity: normal status: open title: Update What's new in 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:07:08 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 16 Mar 2008 21:07:08 +0000 Subject: [issue1492860] Integer bit operations performance improvement. Message-ID: <1205701628.35.0.823272331971.issue1492860@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- type: feature request -> performance _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 16 22:07:55 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 16 Mar 2008 21:07:55 +0000 Subject: [issue735110] Mach-O gcc optimisation flag can boost performance up to 10% Message-ID: <1205701675.04.0.332151928787.issue735110@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- type: feature request -> performance ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Mar 16 22:08:02 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 16 Mar 2008 21:08:02 +0000 Subject: [issue1792] o(n*n) marshal.dumps performance for largish objects with patch In-Reply-To: <1200061286.09.0.117532205028.issue1792@psf.upfronthosting.co.za> Message-ID: <1205701682.0.0.242654600586.issue1792@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- type: resource usage -> performance __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:16:03 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 16 Mar 2008 21:16:03 +0000 Subject: [issue2307] Decide what to do with bytes/str when transferring pickles between 2.6 and 3.0 In-Reply-To: <1205702162.93.0.846570819567.issue2307@psf.upfronthosting.co.za> Message-ID: <1205702162.93.0.846570819567.issue2307@psf.upfronthosting.co.za> New submission from Guido van Rossum : A pickled str instance written by 2.6 currently unpickles under 3.0 as a bytes instance. That would be correct if the intended use is binary data, but it's wrong if the intended use is text. My hunch is that there's more pickled text than binary data. (E.g. a dict containing instance variables uses (8-bit) str instances for the keys; these *must* be unpacked as (Unicode) str instances in 3.0.) The inverse issue also exists. We need to DECIDE this before starting to code (coding is probably minimal). I'm assigning the task to DECIDE (after discussion on the list) to myself. ---------- assignee: gvanrossum components: Library (Lib) messages: 63593 nosy: gvanrossum priority: high severity: normal status: open title: Decide what to do with bytes/str when transferring pickles between 2.6 and 3.0 type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:19:31 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 16 Mar 2008 21:19:31 +0000 Subject: [issue2308] Make structseq more like collections.namedtuple In-Reply-To: <1205702371.36.0.516999386883.issue2308@psf.upfronthosting.co.za> Message-ID: <1205702371.36.0.516999386883.issue2308@psf.upfronthosting.co.za> New submission from Guido van Rossum : The built-in type structseq (used by e.g. os.stat() for the stat structure and by the time module for a time tuple) resembles the new namedtuple type added to the collections module in 2.6. It would be nice if these had at least a common ABC if not a shared implementation. At the same time I think that in 3.0 we should remove the feature of "hidden fields" which is used to have structs that behave like fixed-size tuples even though they have a variable number of named fields (the list of names varies per platform). We should deprecate the use of tuple-unpacking for these (except for the first 6 fields of a timetuple, perhaps). ---------- components: Interpreter Core, Library (Lib) messages: 63594 nosy: gvanrossum priority: high severity: normal status: open title: Make structseq more like collections.namedtuple type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:22:45 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 16 Mar 2008 21:22:45 +0000 Subject: [issue2309] Add xturtle to the standard library? In-Reply-To: <1205702565.16.0.164147436209.issue2309@psf.upfronthosting.co.za> Message-ID: <1205702565.16.0.164147436209.issue2309@psf.upfronthosting.co.za> New submission from Guido van Rossum : Georg Lingl has offered his xturtle for the standard library. Barring showstopping problems with dependencies or code qualitiy I think this is a good thing to add to 3.0 as a replacement for turtle, and to add to 2.6 while keeping the old turtle module. ---------- messages: 63595 nosy: gvanrossum severity: normal status: open title: Add xturtle to the standard library? type: feature request versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:23:46 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 16 Mar 2008 21:23:46 +0000 Subject: [issue2309] Add xturtle to the standard library? In-Reply-To: <1205702565.16.0.164147436209.issue2309@psf.upfronthosting.co.za> Message-ID: <1205702626.45.0.949056812153.issue2309@psf.upfronthosting.co.za> Guido van Rossum added the comment: See http://mail.python.org/pipermail/python-dev/2008-March/077621.html __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:25:58 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 16 Mar 2008 21:25:58 +0000 Subject: [issue2310] Reorganize the 3.0 Misc/NEWS file In-Reply-To: <1205702758.46.0.979295500245.issue2310@psf.upfronthosting.co.za> Message-ID: <1205702758.46.0.979295500245.issue2310@psf.upfronthosting.co.za> New submission from Guido van Rossum : The 3.0 Misc/NEWS file is a mess. It is vastly incomplete because it usually gets skipped during merges rather than resolving the conflicts. ---------- assignee: georg.brandl components: Documentation messages: 63597 nosy: georg.brandl, gvanrossum severity: normal status: open title: Reorganize the 3.0 Misc/NEWS file versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:27:01 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 16 Mar 2008 21:27:01 +0000 Subject: [issue2311] Update the ACKS file In-Reply-To: <1205702821.59.0.0634295065395.issue2311@psf.upfronthosting.co.za> Message-ID: <1205702821.59.0.0634295065395.issue2311@psf.upfronthosting.co.za> New submission from Guido van Rossum : We should keep the ACKS files up to date. Have all the GHOP contributors been added? ---------- assignee: georg.brandl components: Documentation messages: 63598 nosy: georg.brandl, gvanrossum priority: normal severity: normal status: open title: Update the ACKS file versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:28:11 2008 From: report at bugs.python.org (Just van Rossum) Date: Sun, 16 Mar 2008 21:28:11 +0000 Subject: [issue735110] Mach-O gcc optimisation flag can boost performance up to 10% Message-ID: <1205702891.97.0.165095373105.issue735110@psf.upfronthosting.co.za> Changes by Just van Rossum : ---------- resolution: -> rejected status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Mar 16 22:28:48 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 16 Mar 2008 21:28:48 +0000 Subject: [issue2305] Update What's new in 2.6 In-Reply-To: <1205701570.77.0.602719062541.issue2305@psf.upfronthosting.co.za> Message-ID: <1205702928.83.0.27020019815.issue2305@psf.upfronthosting.co.za> Benjamin Peterson added the comment: It looks like the author is Kuchling. ---------- nosy: +akuchling, benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:33:11 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 16 Mar 2008 21:33:11 +0000 Subject: [issue2311] Update the ACKS file In-Reply-To: <1205702821.59.0.0634295065395.issue2311@psf.upfronthosting.co.za> Message-ID: <1205703191.46.0.672289771962.issue2311@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:38:57 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 16 Mar 2008 21:38:57 +0000 Subject: [issue2312] Update PEP 3135 (super()) In-Reply-To: <1205703537.32.0.106170069939.issue2312@psf.upfronthosting.co.za> Message-ID: <1205703537.32.0.106170069939.issue2312@psf.upfronthosting.co.za> New submission from Guido van Rossum : The super() PEP currently is completely wrong w.r.t. reality. The implementation is solid and won't change. The PEP just needs to be rewritten to match reality. ---------- assignee: georg.brandl components: Documentation messages: 63600 nosy: georg.brandl, gvanrossum severity: normal status: open title: Update PEP 3135 (super()) versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:39:58 2008 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 16 Mar 2008 21:39:58 +0000 Subject: [issue2216] Problems using logging module with idle In-Reply-To: <1204466149.08.0.371697565628.issue2216@psf.upfronthosting.co.za> Message-ID: <1205703598.13.0.357921167043.issue2216@psf.upfronthosting.co.za> Vinay Sajip added the comment: Documentation updated in trunk. ---------- status: pending -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:41:02 2008 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 16 Mar 2008 21:41:02 +0000 Subject: [issue2287] Problems using logging module with logging.basicConfig(level=logging.NOTSET) In-Reply-To: <1205503027.6.0.969200887551.issue2287@psf.upfronthosting.co.za> Message-ID: <1205703662.24.0.102622247626.issue2287@psf.upfronthosting.co.za> Vinay Sajip added the comment: Updated release25-maint. ---------- assignee: -> vsajip nosy: +vsajip resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:48:25 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 16 Mar 2008 21:48:25 +0000 Subject: [issue2309] Add xturtle to the standard library? In-Reply-To: <1205702565.16.0.164147436209.issue2309@psf.upfronthosting.co.za> Message-ID: <1205704105.79.0.785522570373.issue2309@psf.upfronthosting.co.za> Martin v. L?wis added the comment: See also issue1513695. I don't see a principle problem replacing turtle with xturtle, assuming its compatible. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:49:04 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 16 Mar 2008 21:49:04 +0000 Subject: [issue2309] Add xturtle to the standard library? In-Reply-To: <1205702565.16.0.164147436209.issue2309@psf.upfronthosting.co.za> Message-ID: <1205704144.62.0.811334591184.issue2309@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- nosy: +gregorlingl __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 22:53:14 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 16 Mar 2008 21:53:14 +0000 Subject: [issue1513695] new turtle module Message-ID: <1205704394.26.0.696143056017.issue1513695@psf.upfronthosting.co.za> Guido van Rossum added the comment: (This is no longer the latest version. Gregor, mind uploading a newer one?) ---------- nosy: +gvanrossum _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 16 22:53:20 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 16 Mar 2008 21:53:20 +0000 Subject: [issue2289] os.path.normpath over-normalizes In-Reply-To: <1205520225.21.0.16693669718.issue2289@psf.upfronthosting.co.za> Message-ID: <1205704400.25.0.999697337978.issue2289@psf.upfronthosting.co.za> Georg Brandl added the comment: Closing as "Won't fix". ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 23:13:23 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 16 Mar 2008 22:13:23 +0000 Subject: [issue2296] [PATCH] Tcl/Tk 8.4.16 patches needed to get an x64 Windows build In-Reply-To: <1205620533.13.0.0700129427319.issue2296@psf.upfronthosting.co.za> Message-ID: <1205705603.48.0.866156083373.issue2296@psf.upfronthosting.co.za> Martin v. L?wis added the comment: We still try to ship Tix where possible, not for use within Python itself, but for applications that use it. This goes back to Issue474836. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 16 23:46:56 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sun, 16 Mar 2008 22:46:56 +0000 Subject: [issue2302] Uses of SocketServer.BaseServer.shutdown have a race In-Reply-To: <1205680557.19.0.19509352533.issue2302@psf.upfronthosting.co.za> Message-ID: <1205707616.69.0.281304015892.issue2302@psf.upfronthosting.co.za> Changes by Jeffrey Yasskin : ---------- assignee: -> jyasskin __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 00:18:22 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Sun, 16 Mar 2008 23:18:22 +0000 Subject: [issue2313] correct longobject.c type cast In-Reply-To: <1205709502.77.0.893498330113.issue2313@psf.upfronthosting.co.za> Message-ID: <1205709502.77.0.893498330113.issue2313@psf.upfronthosting.co.za> New submission from Joseph Armbruster : longobject.c has a type cast that should be different to take HAVE_UINTPTR_T into account. ps: noticed this as i'm merging trunk -> PythonCE to get this working on my new cellphone, the Wing! ---------- components: Interpreter Core files: longobject.patch keywords: patch messages: 63607 nosy: JosephArmbruster, jyasskin severity: normal status: open title: correct longobject.c type cast versions: Python 2.6 Added file: http://bugs.python.org/file9683/longobject.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 00:26:43 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Sun, 16 Mar 2008 23:26:43 +0000 Subject: [issue2313] correct int / long object type casts In-Reply-To: <1205709502.77.0.893498330113.issue2313@psf.upfronthosting.co.za> Message-ID: <1205710003.66.0.136830754216.issue2313@psf.upfronthosting.co.za> Joseph Armbruster added the comment: it looks like this may also be the case in intobject ---------- title: correct longobject.c type cast -> correct int / long object type casts Added file: http://bugs.python.org/file9684/intobject.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 00:32:48 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 16 Mar 2008 23:32:48 +0000 Subject: [issue2314] Test issue In-Reply-To: <47DDAE1C.6070704@v.loewis.de> Message-ID: <47DDAE1C.6070704@v.loewis.de> New submission from Martin v. L?wis : Let's see whether email submission works. ---------- assignee: gvanrossum messages: 63609 nosy: gvanrossum, loewis severity: normal status: open title: Test issue __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 01:59:32 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Mon, 17 Mar 2008 00:59:32 +0000 Subject: [issue2304] subprocess under windows fails to quote properly when shell=True In-Reply-To: <1205685138.96.0.183811169845.issue2304@psf.upfronthosting.co.za> Message-ID: <1205715572.75.0.0970173613617.issue2304@psf.upfronthosting.co.za> Gabriel Genellina added the comment: You aren't testing the modified code, the Popen call should say shell=True. I think that a more PEP8-compliant style would be nice (removing the spaces after open and read, and using consistent indentation) ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 02:09:05 2008 From: report at bugs.python.org (Trent Nelson) Date: Mon, 17 Mar 2008 01:09:05 +0000 Subject: [issue2297] Patch for fatal stack overflow in Windows caused by -v In-Reply-To: <1205645085.91.0.398085675156.issue2297@psf.upfronthosting.co.za> Message-ID: <1205716145.48.0.259090596993.issue2297@psf.upfronthosting.co.za> Trent Nelson added the comment: Any chance of getting a test case that demonstrates this? I'll happily test the patch if there's an associated test case I can run to assert before/after behaviour. ---------- nosy: +Trent.Nelson __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 02:55:27 2008 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 17 Mar 2008 01:55:27 +0000 Subject: [issue719888] tokenize module w/ coding cookie Message-ID: <1205718927.83.0.0872559862444.issue719888@psf.upfronthosting.co.za> Mark Dickinson added the comment: This issue is currently causing test_tokenize failures in Python 3.0. There are other ways to fix the test failures, but making tokenize honor the source file encoding seems like the right thing to do to me. Does this still seem like a good idea to everyone? ---------- nosy: +marketdickinson versions: +Python 2.6, Python 3.0 -Python 2.3 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 17 03:34:28 2008 From: report at bugs.python.org (Douglas Greiman) Date: Mon, 17 Mar 2008 02:34:28 +0000 Subject: [issue2297] Patch for fatal stack overflow in Windows caused by -v In-Reply-To: <1205645085.91.0.398085675156.issue2297@psf.upfronthosting.co.za> Message-ID: <1205721268.27.0.960000131655.issue2297@psf.upfronthosting.co.za> Douglas Greiman added the comment: Good call. I've attached an updated patch which includes a testcase in test_cmd_line.py. Added file: http://bugs.python.org/file9685/py3k-win-codec-recursion-20080316.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 04:06:54 2008 From: report at bugs.python.org (Eric Smith) Date: Mon, 17 Mar 2008 03:06:54 +0000 Subject: [issue2264] empty specifier for float.__format__ does not always print at least one decimal digit In-Reply-To: <1205147124.28.0.679572132371.issue2264@psf.upfronthosting.co.za> Message-ID: <1205723214.61.0.782969937957.issue2264@psf.upfronthosting.co.za> Eric Smith added the comment: I think the best way to handle this is to add a new format code to PyOS_ascii_formatd, which implements this behavior. There can be no backward compatibility issues, because PyOS_ascii_formatd currently ensures its format specifier type code is in ['e', 'E', 'f', 'F', 'g', 'G', 'n']. I'm going to use 'Z' (for lack of a better code) to mean "implement the default behavior from PEP 3101". __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 04:14:03 2008 From: report at bugs.python.org (Trent Nelson) Date: Mon, 17 Mar 2008 03:14:03 +0000 Subject: [issue2297] Patch for fatal stack overflow in Windows caused by -v In-Reply-To: <1205645085.91.0.398085675156.issue2297@psf.upfronthosting.co.za> Message-ID: <1205723643.52.0.63524689024.issue2297@psf.upfronthosting.co.za> Trent Nelson added the comment: +1, tested on x86 XP and x64 2k8. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 05:03:19 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 04:03:19 +0000 Subject: [issue2314] Test issue In-Reply-To: <47DDAE1C.6070704@v.loewis.de> Message-ID: <1205726599.02.0.722881238319.issue2314@psf.upfronthosting.co.za> Guido van Rossum added the comment: So what did the email you sent look like? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 05:17:43 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 17 Mar 2008 04:17:43 +0000 Subject: [issue2314] Test issue In-Reply-To: <47DDAE1C.6070704@v.loewis.de> Message-ID: <1205727463.87.0.306363098018.issue2314@psf.upfronthosting.co.za> Martin v. L?wis added the comment: To: report at bugs.python.org Subject: Test issue [assignee=gvanrossum] The body was msg63609. The tricky part is to get the property names right. Roundup will reject (and return) the message if they are wrong, without telling what the right ones are. For issue, we currently have title (messagea) (files) nosy (*) superseder type components (*) versions (*) priority dependencies (*) assignee status resolution keywords (*) The ones in parentheses are irrelevant for the subject. The ones with an asterisk are multilink, so you can not only key=value, but also key=+value or key=-value (see the body of the email here for syntax examples) ---------- components: +Demos and Tools, Documentation nosy: +nnorwitz priority: -> immediate versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 05:39:06 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 17 Mar 2008 04:39:06 +0000 Subject: [issue719888] tokenize module w/ coding cookie Message-ID: <1205728746.74.0.894937501179.issue719888@psf.upfronthosting.co.za> Martin v. L?wis added the comment: In 3k, the tokenize module should definitely return strings, and, in doing so, it should definitely consider the encoding declaration (and also the default encoding in absence of the encoding declaration). For 2.6, I wouldn't mind if it were changed incompatibly so that it returns Unicode strings, or else that it parses in Unicode, and then encodes back to the source encoding before returning anything. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 17 07:41:12 2008 From: report at bugs.python.org (Trent Nelson) Date: Mon, 17 Mar 2008 06:41:12 +0000 Subject: [issue719888] tokenize module w/ coding cookie Message-ID: <1205736072.08.0.278224949232.issue719888@psf.upfronthosting.co.za> Trent Nelson added the comment: I've attached a patch to test_tokenizer.py and a bunch of text files (that should be dropped into Lib/test) that highlight this issue a *lot* better than the current state of affairs. The existing implementation defines roundup() in the doctest, then proceeds to define it again in the code body. The last for loop in the doctest is failing every so often -- what it's failing on isn't at all clear as a) ten random files are selected out of 332 in Lib/test, and b) there's no way of figuring out which files are causing it to fail unless you hack another method into the test case to try and replicate what the doctest is doing, with some additional print statements (which is the approach I took, only to get bitten by the fact that roundup() was being resolved to the bogus definition that's in the code body, not the functional one in the doctest, which resulted in even more misleading behaviour). FWIW, the file that causes the exception is test_doctest2.py as it contains encoded characters. So, the approach this patch takes is to drop the 'pick ten random test files and untokenize/tokenize' approach and add a class that specifically tests for the tokenizer's compliance with PEP 0263. I'll move on to a patch to tokenizer.py now, but this patch is ok to commit now -- it'll clean up the misleading errors being reported by the plethora of red 3.0 buildbots at the moment at the very least. ---------- nosy: +Trent.Nelson ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 17 07:45:31 2008 From: report at bugs.python.org (Trent Nelson) Date: Mon, 17 Mar 2008 06:45:31 +0000 Subject: [issue719888] tokenize module w/ coding cookie Message-ID: <1205736331.01.0.416102166805.issue719888@psf.upfronthosting.co.za> Trent Nelson added the comment: Hmm, I take it multiple file uploads aren't supported. I don't want to use svn diff for the text files as it looks like it's butchering the bom encodings, so, tar it is! (Untar in root py3k/ directory.) Added file: http://bugs.python.org/file9686/test_tokenize_patch.tar ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 17 08:42:42 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 17 Mar 2008 07:42:42 +0000 Subject: [issue2278] [Py30a3] xml.parsers.expat recognizes encoding="utf-8" but not encoding="utf8" In-Reply-To: <1205319843.23.0.2378782834.issue2278@psf.upfronthosting.co.za> Message-ID: <1205739762.64.0.472703793202.issue2278@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay to close this, then? ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 08:45:45 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 17 Mar 2008 07:45:45 +0000 Subject: [issue2176] Undocumented lastrowid attribute i sqlite3 cursor class In-Reply-To: <1203862408.41.0.133171732382.issue2176@psf.upfronthosting.co.za> Message-ID: <1205739945.67.0.130465799763.issue2176@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 09:00:09 2008 From: report at bugs.python.org (Per Cederqvist) Date: Mon, 17 Mar 2008 08:00:09 +0000 Subject: [issue2315] TimedRotatingFileHandler does not account for daylight savings time In-Reply-To: <1205740809.7.0.649649150956.issue2315@psf.upfronthosting.co.za> Message-ID: <1205740809.7.0.649649150956.issue2315@psf.upfronthosting.co.za> New submission from Per Cederqvist : If TimedRotatingFileHandler is instructed to roll over the log at midnight or on a certain weekday, it needs to consider when daylight savings time starts and ends. The current code just blindly adds self.interval to self.rolloverAt, totally ignoring that sometimes it should add 23 or 25 hours instead of 24 hours. (I suspect that the implementation would be simpler if you use the datetime module, rather than attempt to patch the existing code.) ---------- components: Library (Lib) messages: 63622 nosy: ceder severity: normal status: open title: TimedRotatingFileHandler does not account for daylight savings time type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 09:08:42 2008 From: report at bugs.python.org (Tim Golden) Date: Mon, 17 Mar 2008 08:08:42 +0000 Subject: =?utf-8?q?[issue2304]_subprocess_under_windows_fails_to_quote_properly_when=09shell=3DTrue?= In-Reply-To: <1205715572.75.0.0970173613617.issue2304@psf.upfronthosting.co.za> Message-ID: <47DE2742.9040207@timgolden.me.uk> Tim Golden added the comment: Gabriel Genellina wrote: > Gabriel Genellina added the comment: > > You aren't testing the modified code, the Popen call should say > shell=True. > > I think that a more PEP8-compliant style would be nice (removing the > spaces after open and read, and using consistent indentation) D'oh. Thanks, Gabriel. I'll rework the test and tidy up the patch. ---------- title: subprocess under windows fails to quote properly when shell=True -> subprocess under windows fails to quote properly when shell=True __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 09:17:55 2008 From: report at bugs.python.org (Per Cederqvist) Date: Mon, 17 Mar 2008 08:17:55 +0000 Subject: [issue2316] TimedRotatingFileHandler names files incorrectly if nothing is logged during an interval In-Reply-To: <1205741875.35.0.669932771172.issue2316@psf.upfronthosting.co.za> Message-ID: <1205741875.35.0.669932771172.issue2316@psf.upfronthosting.co.za> New submission from Per Cederqvist : If nothing is logged during an interval, the TimedRotatingFileHandler will give bad names to future log files. The enclosed example program sets up a logger that rotates the log every second. It then logs a few messages with sleep of 1, 2, 4, 1 and 1 seconds between the messages. The log files will have names that increase with one second per log file, but the content for the last file will be generated a different second. An example run produced the message 2008-03-17 09:16:06: 1 sec later in a log file named badlogdir/logfile.2008-03-17_09-16-02. This problem was likely introduced in revision 42066. The root cause is that self.rolloverAt is increased by self.interval in doRollover - but if nothing was logged for a while, it should be increased by a multiple of self.interval. ---------- messages: 63624 nosy: ceder severity: normal status: open title: TimedRotatingFileHandler names files incorrectly if nothing is logged during an interval __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 09:20:37 2008 From: report at bugs.python.org (Per Cederqvist) Date: Mon, 17 Mar 2008 08:20:37 +0000 Subject: [issue2316] TimedRotatingFileHandler names files incorrectly if nothing is logged during an interval In-Reply-To: <1205741875.35.0.669932771172.issue2316@psf.upfronthosting.co.za> Message-ID: <1205742037.47.0.480797140751.issue2316@psf.upfronthosting.co.za> Per Cederqvist added the comment: The attached program will generate log messages with a timestamp that are logged into a file with an unexpected extension. To run: mkdir badlogdir python badlogger.py Running the program takes about 9 seconds. Added file: http://bugs.python.org/file9687/badlogger.py __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 09:21:45 2008 From: report at bugs.python.org (Per Cederqvist) Date: Mon, 17 Mar 2008 08:21:45 +0000 Subject: [issue2316] TimedRotatingFileHandler names files incorrectly if nothing is logged during an interval In-Reply-To: <1205741875.35.0.669932771172.issue2316@psf.upfronthosting.co.za> Message-ID: <1205742105.99.0.926756648451.issue2316@psf.upfronthosting.co.za> Changes by Per Cederqvist : ---------- components: +Library (Lib) type: -> behavior versions: +Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 09:29:36 2008 From: report at bugs.python.org (Per Cederqvist) Date: Mon, 17 Mar 2008 08:29:36 +0000 Subject: [issue2317] TimedRotatingFileHandler logic for removing files wrong In-Reply-To: <1205742576.84.0.607022841001.issue2317@psf.upfronthosting.co.za> Message-ID: <1205742576.84.0.607022841001.issue2317@psf.upfronthosting.co.za> New submission from Per Cederqvist : There are three issues with log file removal in the TimedRotatingFileHandler class: - Removal will stop working in the year 2100, as the code assumes that timestamps start with ".20". - If you run an application with backupCount set to a high number, and then restarts it with a lower number, the code will still not remove as many log files as you expect. It will never remove more than one file when it rotates the log. - It assumes that no other files matches baseFilename + ".20*", so make sure that you don't log to both "log" and "log.20th.century.fox" in the same directory! Suggested fix: use os.listdir() instead of glob.glob(), filter all file names using a proper regexp, sort the result, and use a while loop to remove files until the result is small enough. To reduce the risk of accidentally removing an unrelated file, the filter regexp should be based on the logging interval, just as the filename is. My suggested fix means that old files may not be removed if you change the interval. I think that is an acceptable behavior, but it should probably be documented to avoid future bug reports on this subject. :-) ---------- components: Library (Lib) messages: 63626 nosy: ceder severity: normal status: open title: TimedRotatingFileHandler logic for removing files wrong type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 09:32:59 2008 From: report at bugs.python.org (Per Cederqvist) Date: Mon, 17 Mar 2008 08:32:59 +0000 Subject: [issue2318] TimedRotatingFileHandler: rotate every month, or every year In-Reply-To: <1205742779.64.0.634680353877.issue2318@psf.upfronthosting.co.za> Message-ID: <1205742779.64.0.634680353877.issue2318@psf.upfronthosting.co.za> New submission from Per Cederqvist : In my curent project, I would like to rotate log files on the 1st of every month. The TimedRotatingFileHandler class cannot do this, even though it tries to be very generic. I imagine that other projects would like to rotate the log file every year. That can also not be done. ---------- components: Library (Lib) messages: 63627 nosy: ceder severity: normal status: open title: TimedRotatingFileHandler: rotate every month, or every year type: feature request __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 09:56:15 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Mon, 17 Mar 2008 08:56:15 +0000 Subject: [issue2301] [Py3k] No text shown when SyntaxError (when not UTF8) In-Reply-To: <1205674653.18.0.28557522559.issue2301@psf.upfronthosting.co.za> Message-ID: <1205744175.37.0.470372180921.issue2301@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Hello. I tracked down source code and found where err->text is set. Index: Parser/parsetok.c =================================================================== --- Parser/parsetok.c (revision 61411) +++ Parser/parsetok.c (working copy) @@ -218,7 +218,7 @@ assert(tok->cur - tok->buf < INT_MAX); err_ret->offset = (int)(tok->cur - tok->buf); len = tok->inp - tok->buf; - text = PyTokenizer_RestoreEncoding(tok, len, &err_ret->offset); +/* text = PyTokenizer_RestoreEncoding(tok, len, &err_ret->offset); */ if (text == NULL) { text = (char *) PyObject_MALLOC(len + 1); if (text != NULL) { It seems tok->buf is encoded with UTF-8, and PyTokenizer_RestoreEncoding() resotores it to original encoding of source file. So I tried above patch, output was expected on cp932/euc_jp source files. Maybe this function is not needed in py3k? I cannot find other place where this function is used. # Probably PyErr_ProgramText() needs more effort to be fixed. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 11:09:45 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 17 Mar 2008 10:09:45 +0000 Subject: [issue2295] cPickle corner case - docs or bug? In-Reply-To: <1205608726.73.0.310899298914.issue2295@psf.upfronthosting.co.za> Message-ID: <1205748585.74.0.344426592.issue2295@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The following "Works for me": >>> import imp, cPickle >>> mymod = imp.load_module('mymod', *imp.find_module('codecs')) >>> cPickle.dumps(mymod.Codec(), cPickle.HIGHEST_PROTOCOL) '\x80\x02(cmymod\nCodec\nq\x01o}q\x02b.' Do you have a short test case to reproduce your problem? Does your code tweak sys.modules? ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 11:49:27 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 17 Mar 2008 10:49:27 +0000 Subject: [issue2319] abc.py:ABCMeta.__instancecheck__ broken for old style classes In-Reply-To: <1205750967.32.0.985818553342.issue2319@psf.upfronthosting.co.za> Message-ID: <1205750967.32.0.985818553342.issue2319@psf.upfronthosting.co.za> New submission from Ralf Schmitt : The following short program raises an exception: import UserList class C: pass print isinstance(C, UserList.UserList) --------- exception: Traceback (most recent call last): File "t.py", line 6, in print isinstance(C, UserList.UserList) File "/home/ralf/py26/lib/python2.6/abc.py", line 120, in __instancecheck__ subclass = instance.__class__ AttributeError: class C has no attribute '__class__' If I use a new style class it works. ---------- components: Interpreter Core messages: 63630 nosy: schmir severity: normal status: open title: abc.py:ABCMeta.__instancecheck__ broken for old style classes type: crash versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 11:55:21 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 17 Mar 2008 10:55:21 +0000 Subject: [issue2319] abc.py:ABCMeta.__instancecheck__ broken for old style classes In-Reply-To: <1205750967.32.0.985818553342.issue2319@psf.upfronthosting.co.za> Message-ID: <1205751321.02.0.842571941591.issue2319@psf.upfronthosting.co.za> Ralf Schmitt added the comment: I used svn revision 61433. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 12:02:28 2008 From: report at bugs.python.org (Eric Smith) Date: Mon, 17 Mar 2008 11:02:28 +0000 Subject: [issue2264] empty specifier for float.__format__ does not always print at least one decimal digit In-Reply-To: <1205147124.28.0.679572132371.issue2264@psf.upfronthosting.co.za> Message-ID: <1205751748.42.0.629384059323.issue2264@psf.upfronthosting.co.za> Eric Smith added the comment: Fixed checked in as r61434. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 12:18:17 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 17 Mar 2008 11:18:17 +0000 Subject: [issue2301] [Py3k] No text shown when SyntaxError (when not UTF8) In-Reply-To: <1205674653.18.0.28557522559.issue2301@psf.upfronthosting.co.za> Message-ID: <1205752697.93.0.710159288082.issue2301@psf.upfronthosting.co.za> Martin v. L?wis added the comment: You are probably right about the source of the problem; I was confusing it with a regular exception, e.g. print("?",a) However, I also fail to reproduce the problem on OSX. I get File "a.py", line 3 print "?N" ^ SyntaxError: invalid syntax I'm not quite sure what the N is doing in there, but the first character is the replacement character (hopefully, the tracker will reproduce it correctly); I get that because pythonrun uses the "replace" codec. I guess you are not seeing it because then the replacement character cannot actually be output to your terminal. Please try print("\ufffd") to see what that does. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 13:22:33 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 17 Mar 2008 12:22:33 +0000 Subject: [issue448736] pydoc needs readline completion Message-ID: <1205756553.87.0.795708276739.issue448736@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This was duplicated in issue726204 and fixed in r37026. ---------- nosy: +belopolsky ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 17 14:11:16 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 17 Mar 2008 13:11:16 +0000 Subject: [issue416670] MatchObjects not deepcopy()able Message-ID: <1205759476.58.0.856857806672.issue416670@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: A related issue419070 was closed with no resolution (or resolution did not survive the trip from SF), but it looks like the patch was rejected. Some work towards this issue was done in r21437, but 7 years later it is still marked as work in progress. Is there still interest is this feature? ---------- nosy: +belopolsky ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 17 14:30:17 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Mon, 17 Mar 2008 13:30:17 +0000 Subject: [issue2301] [Py3k] No text shown when SyntaxError (when not UTF8) In-Reply-To: <1205674653.18.0.28557522559.issue2301@psf.upfronthosting.co.za> Message-ID: <1205760617.1.0.758837686266.issue2301@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: > I was confusing it with a regular exception, e.g. > print("?",a) I'm now invesigating this problem. This comes from another reason. Please look at fp_setreadl in Parser/tokenizer.c. This function opens file using codec and doesn't seek to current position. (fp_setreadl is used when codecs is neigher utf-8 nor iso-8859-1 .... tok->decoding_state == STATE_NORMAL) So # coding: ascii # 1 # 2 # 3 raise RuntimeError("a") # 4 # 5 # 6 outputs C:\Documents and Settings\WhiteRabbit>py3k ascii.py Traceback (most recent call last): File "ascii.py", line 6, in # 4 RuntimeError: a [22821 refs] # One line shifted. And # dummy # coding: ascii # 1 # 2 # 3 raise RuntimeError("a") # 4 # 5 # 6 outputs C:\Documents and Settings\WhiteRabbit>py3k ascii.py Traceback (most recent call last): File "ascii.py", line 8, in # 5 RuntimeError: a [22821 refs] # Two lines shifted. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 14:31:52 2008 From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=) Date: Mon, 17 Mar 2008 13:31:52 +0000 Subject: [issue2320] Race condition in subprocess using stdin In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za> Message-ID: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za> New submission from Ludwig H?hne : Pythons subprocess module has a race condition when stdin is used. The problem can be reproduced with the following script (based on the script in issue "#1731717"/"msg32210" (slightly changed to use stdin): ---- import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen(("cat"), stdin=subprocess.PIPE) s.communicate(input = '#') for i in xrange(20): X(target = tt) ---- On multi-processor (or multi-core) machines the script hangs fairly reliably. Protecting the Popen call with a lock solves the problem. I searched the documentation if using stdin with subprocess.Popen was not thread-safe, but found no indication. Tested with Python 2.5.1, 2.5.2 and 2.6a1. The problem can be reproduced with all mentioned versions. ---------- components: Library (Lib) messages: 63637 nosy: Pankrat severity: normal status: open title: Race condition in subprocess using stdin versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 14:35:13 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 13:35:13 +0000 Subject: [issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString. In-Reply-To: <1201473895.18.0.771876708371.issue1950@psf.upfronthosting.co.za> Message-ID: <1205760913.05.0.443613231654.issue1950@psf.upfronthosting.co.za> Guido van Rossum added the comment: Any progress? ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 14:36:27 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Mon, 17 Mar 2008 13:36:27 +0000 Subject: [issue2301] [Py3k] No text shown when SyntaxError (when not UTF8) In-Reply-To: <1205674653.18.0.28557522559.issue2301@psf.upfronthosting.co.za> Message-ID: <1205760987.23.0.170049202534.issue2301@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: >However, I also fail to reproduce the problem on OSX. I get > > File "a.py", line 3 > print "?N" > ^ >SyntaxError: invalid syntax Umm, strange... I can output correct result even if using euc_jp (my terminal named command prompt cannot output euc_jp string directly, AFAIK) > print("\ufffd") >>> print("\ufffd") Traceback (most recent call last): File "", line 1, in File "e:\python-dev\py3k\lib\io.py", line 1247, in write b = encoder.encode(s) UnicodeEncodeError: 'cp932' codec can't encode character '\ufffd' in position 0: illegal multibyte sequence __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 14:38:08 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 17 Mar 2008 13:38:08 +0000 Subject: [issue2320] Race condition in subprocess using stdin In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za> Message-ID: <1205761088.73.0.73787410452.issue2320@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Unless noted, none of Python's stdlib guarantees that it's thread safe. So , you have to lock. ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 14:42:21 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Mon, 17 Mar 2008 13:42:21 +0000 Subject: [issue2301] [Py3k] No text shown when SyntaxError (when not UTF8) In-Reply-To: <1205674653.18.0.28557522559.issue2301@psf.upfronthosting.co.za> Message-ID: <1205761341.62.0.770743790898.issue2301@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: >I'm now invesigating this problem. This comes from another reason. Of course, even if this line number problem is fixed, encoding problem still remains. Probably I'll look at it next. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 14:43:19 2008 From: report at bugs.python.org (Amiga Lemming) Date: Mon, 17 Mar 2008 13:43:19 +0000 Subject: [issue416670] MatchObjects not deepcopy()able In-Reply-To: <1205759476.58.0.856857806672.issue416670@psf.upfronthosting.co.za> Message-ID: Amiga Lemming added the comment: On Mon, 17 Mar 2008, Alexander Belopolsky wrote: > Alexander Belopolsky added the comment: > > A related issue419070 was closed with no resolution (or resolution did > not survive the trip from SF), but it looks like the patch was rejected. > > Some work towards this issue was done in r21437, but 7 years later it is > still marked as work in progress. Is there still interest is this > feature? Not by me since I moved to Haskell. :-) ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 17 14:51:25 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 17 Mar 2008 13:51:25 +0000 Subject: [issue2298] Patch for "string without null bytes" check in getargs.c In-Reply-To: <1205647240.0.0.304059938651.issue2298@psf.upfronthosting.co.za> Message-ID: <1205761885.38.0.0694702171213.issue2298@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Yes, that sounds like a good idea. Although I haven't reviewed this patch yet, I find the naming of the `ustr` variable confusing -- e.g. is it a bytes object or a unicode object? (It seems to be bytes). Anyway, I will check this out later today, when I will get the time. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 15:01:52 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 17 Mar 2008 14:01:52 +0000 Subject: [issue433024] SRE: (?flag) isn't properly scoped Message-ID: <1205762512.34.0.887728944067.issue433024@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This is still a valid issue. (As of Python 2.6a1+ (trunk:61434, Mar 17 2008, 08:06:54).) >>> bool(re.match("abc(?i)","AbC")) True The documentation says that the behavior of a regex with (?) not at the beginning is undefined. Short of implementing Java/Perl behavior, this should be made an error rather than undefined so that users porting their code from Java/Perl get an early warning. ---------- nosy: +belopolsky ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 17 15:12:21 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 17 Mar 2008 14:12:21 +0000 Subject: [issue433027] SRE: (?-flag) is not supported. Message-ID: <1205763141.65.0.582763801904.issue433027@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This depends on issue433024 (SRE: (?flag) isn't properly scoped.) ---------- nosy: +belopolsky ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 17 15:26:05 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 17 Mar 2008 14:26:05 +0000 Subject: [issue2314] Test issue In-Reply-To: <47DDAE1C.6070704@v.loewis.de> Message-ID: <1205763965.4.0.161852143203.issue2314@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 15:43:33 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 17 Mar 2008 14:43:33 +0000 Subject: [issue1779871] Make python build with gcc-4.2 on OS X 10.4.9 Message-ID: <1205765013.41.0.393778956753.issue1779871@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: I've fixed this in r61436 with a bunch of back pointers to the previous issues. If anyone on old versions sees problems, we can add the flags back conditionally. ---------- resolution: accepted -> fixed status: open -> closed type: -> compile error _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 17 16:06:20 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 17 Mar 2008 15:06:20 +0000 Subject: [issue868845] Need unit tests for <...> reprs Message-ID: <1205766380.74.0.36521984685.issue868845@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: If any work needs to be done on this issue, it should probably be labeled "easy." (At least the writing the unit tests part. Making <...> reprs consistent is another story.) The unit tests for old-style and new-style class reprs are present in test_repr and seem to predate the original request. There are some more similar tests elsewhere (test_file, test_descr, etc.) ---------- nosy: +belopolsky ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 17 16:07:51 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 17 Mar 2008 15:07:51 +0000 Subject: [issue775892] test_coercion failing on Panther Message-ID: <1205766471.07.0.721855156579.issue775892@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: I reverted this in r61436 to fix issue 1779871. Either the test has changed in the mean time, or the gccs bundled since OS X 10.4 now preserve the signs of 0. ---------- nosy: +jyasskin ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 17 16:09:06 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 15:09:06 +0000 Subject: [issue2311] Update the ACKS file In-Reply-To: <1205702821.59.0.0634295065395.issue2311@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: On Sun, Mar 16, 2008 at 4:27 PM, Guido van Rossum wrote: > > New submission from Guido van Rossum : > > We should keep the ACKS files up to date. Have all the GHOP contributors > been added? They have been added as their code has been committed. Is there anything else you were thinking of for the file, or should I go ahead and close this issue? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 16:10:13 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 17 Mar 2008 15:10:13 +0000 Subject: [issue525481] long double causes compiler warnings Message-ID: <1205766613.24.0.977736859495.issue525481@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: I reverted this in r61436 to fix issue 1779871. The long double is still around, but the gcc bundled with OS X 10.4 doesn't warn about it anymore. ---------- nosy: +jyasskin ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 17 16:18:42 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 15:18:42 +0000 Subject: [issue2314] Test issue In-Reply-To: <47DDAE1C.6070704@v.loewis.de> Message-ID: <1205767122.59.0.916117848471.issue2314@psf.upfronthosting.co.za> Guido van Rossum added the comment: So what's the syntax for setting multiple attributes via an email subject? [assignee=+twouters,priority=low]? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 16:29:54 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 17 Mar 2008 15:29:54 +0000 Subject: [issue2298] Patch for "string without null bytes" check in getargs.c In-Reply-To: <1205761885.38.0.0694702171213.issue2298@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Mon, Mar 17, 2008 at 9:51 AM, Alexandre Vassalotti < report at bugs.python.org> wrote: > > Alexandre Vassalotti added the comment: > > .. Although I haven't reviewed this > patch yet, I find the naming of the `ustr` variable confusing -- e.g. is > it a bytes object or a unicode object? There is no `ustr` variable , you probably mean `uarg`. If so, it is not introduced by the patch. To me the patch looks straightforward and correct, but a unit test should be added. Some additional refactoring is due for getargs.c (does py3k support builds without Py_USING_UNICODE?), but the bug fix should not wait for that. Added file: http://bugs.python.org/file9688/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080317/c0f906f6/attachment.txt From report at bugs.python.org Mon Mar 17 16:48:22 2008 From: report at bugs.python.org (Neal Norwitz) Date: Mon, 17 Mar 2008 15:48:22 +0000 Subject: [issue2321] return more memory from unicode objects to system In-Reply-To: <1205768902.73.0.245115475399.issue2321@psf.upfronthosting.co.za> Message-ID: <1205768902.73.0.245115475399.issue2321@psf.upfronthosting.co.za> New submission from Neal Norwitz : This patch returns more memory to the system when doing: >>> x = [unicode(i) for i in xrange(1000000)] >>> del x If the above code is done, the memory before and after is quite different. After this patch, the memory of the process as reported by the system (like top/ps) should be approximately the same ---------- components: Interpreter Core files: uni.diff keywords: patch, patch messages: 63654 nosy: nnorwitz severity: normal status: open title: return more memory from unicode objects to system type: resource usage versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9689/uni.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 16:54:10 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 17 Mar 2008 15:54:10 +0000 Subject: [issue1397] mysteriously failing test_bsddb3 threading test in other threads In-Reply-To: <1194352164.91.0.707733802252.issue1397@psf.upfronthosting.co.za> Message-ID: <1205769250.79.0.664147001874.issue1397@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I updated the subject to better reflect what this is. My guess is that the test code itself has issues and is asserting something that isn't quite guaranteed to be true. ---------- title: py3k-pep3137: failing unit test test_bsddb -> mysteriously failing test_bsddb3 threading test in other threads versions: +Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 16:54:38 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 15:54:38 +0000 Subject: [issue2314] Test issue In-Reply-To: <47DDAE1C.6070704@v.loewis.de> Message-ID: Guido van Rossum added the comment: Picky! ---------- assignee: gvanrossum -> nnorwitz nosy: +twouters priority: immediate -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 16:55:44 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 15:55:44 +0000 Subject: [issue2314] Test issue In-Reply-To: <47DDAE1C.6070704@v.loewis.de> Message-ID: Guido van Rossum added the comment: [assignee=guido] Does it also work in the body of the message? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 16:57:00 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 15:57:00 +0000 Subject: [issue2314] Test issue In-Reply-To: <47DDAE1C.6070704@v.loewis.de> Message-ID: <1205769420.55.0.323926260155.issue2314@psf.upfronthosting.co.za> Guido van Rossum added the comment: No. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 16:57:44 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 17 Mar 2008 15:57:44 +0000 Subject: [issue2314] Test issue In-Reply-To: <1205767122.59.0.916117848471.issue2314@psf.upfronthosting.co.za> Message-ID: <47DE94F6.1000808@v.loewis.de> Martin v. L?wis added the comment: Guido van Rossum schrieb: > Guido van Rossum added the comment: > > So what's the syntax for setting multiple attributes via an email subject? > [assignee=+twouters,priority=low]? assignee is not multilink, and the separator is semicolon (;); otherwise, that's the syntax. , is the separator multilink values. [nosy=richard,cliff] ---------- assignee: nnorwitz -> twouters __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 16:59:49 2008 From: report at bugs.python.org (Jeff Balogh) Date: Mon, 17 Mar 2008 15:59:49 +0000 Subject: [issue2282] TextIOWrapper.seekable() always returns False In-Reply-To: <1205382751.6.0.0963204550732.issue2282@psf.upfronthosting.co.za> Message-ID: <1205769589.3.0.123431346853.issue2282@psf.upfronthosting.co.za> Jeff Balogh added the comment: Attaching a patch that fixes this issue and adds a regression test. ---------- keywords: +patch nosy: +jbalogh Added file: http://bugs.python.org/file9690/issue2282.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:02:24 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 17 Mar 2008 16:02:24 +0000 Subject: [issue2282] TextIOWrapper.seekable() always returns False In-Reply-To: <1205382751.6.0.0963204550732.issue2282@psf.upfronthosting.co.za> Message-ID: <1205769744.94.0.0454021662203.issue2282@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:06:41 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 17 Mar 2008 16:06:41 +0000 Subject: [issue2305] Update What's new in 2.6 In-Reply-To: <1205701570.77.0.602719062541.issue2305@psf.upfronthosting.co.za> Message-ID: <1205770001.51.0.0144723078643.issue2305@psf.upfronthosting.co.za> A.M. Kuchling added the comment: I intend to finish writing the 2.6 document; PyCon has been taking up all of my free time the past few weeks, but obviously that's over now. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:13:02 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 16:13:02 +0000 Subject: [issue868845] Need unit tests for <...> reprs Message-ID: <1205770382.2.0.217532503986.issue868845@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'd rather not label this as easy yet, since there's a decision to be made. I would welcome a doc patch though! ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 17 17:15:28 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 16:15:28 +0000 Subject: [issue2282] TextIOWrapper.seekable() always returns False In-Reply-To: <1205382751.6.0.0963204550732.issue2282@psf.upfronthosting.co.za> Message-ID: <1205770528.26.0.175525136053.issue2282@psf.upfronthosting.co.za> Guido van Rossum added the comment: Confirmed. Ping, since you're looking at io.py anyway, can you fix this too? ---------- assignee: -> ping nosy: +ping priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:27:12 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 17 Mar 2008 16:27:12 +0000 Subject: [issue1202] zlib.crc32() and adler32() return value In-Reply-To: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za> Message-ID: <1205771232.04.0.638409811034.issue1202@psf.upfronthosting.co.za> Gregory P. Smith added the comment: working on this now. foo = 'abcdefghijklmnop' 2.x 32-bit long: zlib.crc32(foo) returns -1808088941 2.x 64-bit long: zlib.crc32(foo) returns 2486878355 This is because PyInt_FromLong() happily fits the value into a signed long internally to the integer object on 64-bit platforms. They are both the same number if considered with & 0xffffffff. I'm doing as guido suggests and leaving this slightly odd behavior for 2.x so that crc32 and adler32 always return an integer object. in 3.0 they'll always return an unsigned value. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:27:50 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 16:27:50 +0000 Subject: [issue2322] Clean up getargs.c and its formatting possibilities In-Reply-To: <1205771270.76.0.30305062324.issue2322@psf.upfronthosting.co.za> Message-ID: <1205771270.76.0.30305062324.issue2322@psf.upfronthosting.co.za> New submission from Brett Cannon : It was mentioned by Georg on python-3000 that getargs.c needs to be cleaned up and worked on before Python 3.0 goes out the door. ---------- assignee: georg.brandl components: Interpreter Core messages: 63665 nosy: brett.cannon, georg.brandl priority: immediate severity: normal status: open title: Clean up getargs.c and its formatting possibilities type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:33:02 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 16:33:02 +0000 Subject: [issue2305] Update What's new in 2.6 In-Reply-To: <1205701570.77.0.602719062541.issue2305@psf.upfronthosting.co.za> Message-ID: <1205771582.68.0.482532261341.issue2305@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- assignee: georg.brandl -> akuchling __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:33:14 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 17 Mar 2008 16:33:14 +0000 Subject: [issue1202] zlib.crc32() and adler32() return value In-Reply-To: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za> Message-ID: <1205771594.21.0.0919593095431.issue1202@psf.upfronthosting.co.za> Gregory P. Smith added the comment: question: should I also make 64-bit 2.x return a signed value as well to be consistent with 32bit python 2.x? Consistency in case someone ever pickles the value and sends it to another python instance of a different word length would be good... __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:34:27 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 16:34:27 +0000 Subject: [issue2323] Unify structseq and namedtuple's API In-Reply-To: <1205771667.83.0.681502782029.issue2323@psf.upfronthosting.co.za> Message-ID: <1205771667.83.0.681502782029.issue2323@psf.upfronthosting.co.za> New submission from Brett Cannon : structseq and namedtuple should end up with a uniformed API. ---------- components: Extension Modules messages: 63667 nosy: brett.cannon priority: immediate severity: normal status: open title: Unify structseq and namedtuple's API versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:35:37 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 16:35:37 +0000 Subject: [issue1202] zlib.crc32() and adler32() return value In-Reply-To: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za> Message-ID: <1205771737.2.0.610752405222.issue1202@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sure. (Though sending pickles to 3.0 would still cause problems. Consumers of pickled checksums would do wise to *always* take the CRC mod 2**32 before doing comparisons.) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:36:42 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 16:36:42 +0000 Subject: [issue2324] Document that 2.6 pickles of strings turn into pickles of unicode in 3.0 In-Reply-To: <1205771802.78.0.509532879675.issue2324@psf.upfronthosting.co.za> Message-ID: <1205771802.78.0.509532879675.issue2324@psf.upfronthosting.co.za> New submission from Brett Cannon : It turns out that unpickling a string from 2.6 leads to a Unicode string in 3.0. That might fail since the encoding was never specified. This should be documented probably in both 2.6 and 3.0. ---------- assignee: georg.brandl components: Documentation messages: 63669 nosy: brett.cannon, georg.brandl priority: immediate severity: normal status: open title: Document that 2.6 pickles of strings turn into pickles of unicode in 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:38:17 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 17 Mar 2008 16:38:17 +0000 Subject: [issue2319] abc.py:ABCMeta.__instancecheck__ broken for old style classes In-Reply-To: <1205750967.32.0.985818553342.issue2319@psf.upfronthosting.co.za> Message-ID: <1205771897.08.0.926924373787.issue2319@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Missed this. It's now fixed by r61438. ---------- nosy: +jyasskin status: open -> closed type: crash -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:45:07 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 17 Mar 2008 16:45:07 +0000 Subject: [issue2325] isinstance(anything, MetaclassThatDefinesInstancecheck) raises instead of returning False In-Reply-To: <1205772306.86.0.317312162506.issue2325@psf.upfronthosting.co.za> Message-ID: <1205772306.86.0.317312162506.issue2325@psf.upfronthosting.co.za> New submission from Jeffrey Yasskin : >>> class Meta(type): ... def __instancecheck__(self, other): ... return False >>> isinstance(3, Meta) In 2.6, this results in: Traceback (most recent call last): File "", line 1, in RuntimeError: maximum recursion depth exceeded while calling a Python object (That's a recursion in C, through PyObject_IsInstance and instancemethod_call) In 3.0, I get: Traceback (most recent call last): File "", line 1, in TypeError: __instancecheck__() takes exactly 2 positional arguments (1 given) ---------- components: Interpreter Core messages: 63671 nosy: jyasskin severity: normal status: open title: isinstance(anything, MetaclassThatDefinesInstancecheck) raises instead of returning False type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:48:02 2008 From: report at bugs.python.org (Armin Ronacher) Date: Mon, 17 Mar 2008 16:48:02 +0000 Subject: [issue2321] return more memory from unicode objects to system In-Reply-To: <1205768902.73.0.245115475399.issue2321@psf.upfronthosting.co.za> Message-ID: <1205772482.28.0.562822374457.issue2321@psf.upfronthosting.co.za> Changes by Armin Ronacher : ---------- nosy: +aronacher __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:48:40 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 16:48:40 +0000 Subject: [issue2326] Doc isnumeric and isdecimal for the unicode object In-Reply-To: <1205772520.65.0.452257175762.issue2326@psf.upfronthosting.co.za> Message-ID: <1205772520.65.0.452257175762.issue2326@psf.upfronthosting.co.za> New submission from Brett Cannon : Both the isnumeric and isdecimal methods on the unicode object need to be documented. ---------- assignee: georg.brandl components: Documentation messages: 63672 nosy: brett.cannon, georg.brandl priority: immediate severity: normal status: open title: Doc isnumeric and isdecimal for the unicode object versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:48:50 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Mar 2008 16:48:50 +0000 Subject: [issue1207] Load tests from path (patch included) In-Reply-To: <1190834704.12.0.956914269209.issue1207@psf.upfronthosting.co.za> Message-ID: <1205772530.35.0.567857557697.issue1207@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Patch is inline. A few notes for submitter: This also needs to include a documentation patch before it can be accepted. Please format the docstring for a line length of 78 characters or less. Ideally, please submit a "diff -c" style patch as an attachment. Please discuss this approach on python-dev and/or with Steve Purcell (copied). ---------- assignee: -> purcell keywords: +patch nosy: +jafo, purcell priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:55:52 2008 From: report at bugs.python.org (Alec Thomas) Date: Mon, 17 Mar 2008 16:55:52 +0000 Subject: [issue2321] return more memory from unicode objects to system In-Reply-To: <1205768902.73.0.245115475399.issue2321@psf.upfronthosting.co.za> Message-ID: <1205772952.0.0.890459758617.issue2321@psf.upfronthosting.co.za> Alec Thomas added the comment: Hi Neal, This seems to be a more general problem than just unicode. eg. Tuples: >>> x = [(1, 2, 3, 4, i) for i in xrange(800000)] >>> del x And user-defined objects: >>> class A(object): ... def __init__(self): ... self.x = random.random() >>> x = [A() for i in xrange(800000)] >>> del x Both exhibit the same behaviour. Naively to me it seems like using the custom allocator uniformly would fix this problem. ---------- nosy: +alecthomas __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 17:55:59 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Mar 2008 16:55:59 +0000 Subject: [issue1230] Tix HList class missing method implementation for info_bbox In-Reply-To: <1205772959.19.0.842538363686.issue1230@psf.upfronthosting.co.za> Message-ID: <1205772959.19.0.842538363686.issue1230@psf.upfronthosting.co.za> New submission from Sean Reifschneider : No body included in original message. ---------- assignee: -> loewis nosy: +jafo, loewis priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:01:18 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Mar 2008 17:01:18 +0000 Subject: [issue1250] Building external modules using Sun Studio 12 In-Reply-To: <1191964251.86.0.558465608726.issue1250@psf.upfronthosting.co.za> Message-ID: <1205773278.05.0.96576595129.issue1250@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> niemeyer nosy: +niemeyer priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:03:03 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Mar 2008 17:03:03 +0000 Subject: [issue1230] Tix HList class missing method implementation for info_bbox In-Reply-To: <1205772959.19.0.842538363686.issue1230@psf.upfronthosting.co.za> Message-ID: <1205773383.36.0.209018285671.issue1230@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- type: behavior -> feature request __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:05:03 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Mon, 17 Mar 2008 17:05:03 +0000 Subject: [issue1202] zlib.crc32() and adler32() return value In-Reply-To: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za> Message-ID: <1205773503.64.0.503258868106.issue1202@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I store CRC in reed-solomon schema of mine. I compare with equality, so, I think we should enforce "CRC(python 32 bits) == CRC(python 64 bits)". I will need to touch my code in python 3.0, but that will be inevitable anyway... __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:11:29 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 17:11:29 +0000 Subject: [issue2324] Document that 2.6 pickles of strings turn into pickles of unicode in 3.0 In-Reply-To: <1205771802.78.0.509532879675.issue2324@psf.upfronthosting.co.za> Message-ID: <1205773889.94.0.370239300871.issue2324@psf.upfronthosting.co.za> Guido van Rossum added the comment: The issue is different; there is already a bug open for this (bug 2307). ---------- nosy: +gvanrossum resolution: -> invalid status: open -> closed superseder: -> Decide what to do with bytes/str when transferring pickles between 2.6 and 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:15:15 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 17:15:15 +0000 Subject: [issue2307] Decide what to do with bytes/str when transferring pickles between 2.6 and 3.0 In-Reply-To: <1205702162.93.0.846570819567.issue2307@psf.upfronthosting.co.za> Message-ID: <1205774115.18.0.430647398765.issue2307@psf.upfronthosting.co.za> Guido van Rossum added the comment: We have a proposed solution for 2.x -> 3.x. In 3.x, an (8-bit) str instance received from 2.x will be decoded into a (Unicode) str instance. The encoding defaults to ASCII; you can specify a different encoding and also an error value on the load() or loads() call. This of course doesn't solve all problems; str instances representing binary data will be unpickled as strings. The app will have to deal with this. By default 3.x will *write* pickles using a new version number which is incompatible with 2.x. I'm not sure yet if we should allow writing pickles in 3.x that can be read in 2.x; we need use cases for that. ---------- resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:18:56 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 17:18:56 +0000 Subject: [issue2327] Backport keyword-only arguments to 2.6 In-Reply-To: <1205774336.48.0.251602118658.issue2327@psf.upfronthosting.co.za> Message-ID: <1205774336.48.0.251602118658.issue2327@psf.upfronthosting.co.za> New submission from Brett Cannon : Keyword-only arguments have not been backported to 2.6 from 3.0. ---------- components: Interpreter Core keywords: 26backport messages: 63679 nosy: brett.cannon priority: immediate severity: normal status: open title: Backport keyword-only arguments to 2.6 type: behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:19:27 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 17 Mar 2008 17:19:27 +0000 Subject: [issue868845] Need unit tests for <...> reprs Message-ID: <1205774367.38.0.934722531282.issue868845@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I think the attached patch captures the most of what can currently be said about <...> reprs. I think the biggest offender in terms of inconsistency in the 2.x series is the file object with the repr which does not even start with the name of the type. For 3.0, I think it is feasible to standardize on the <{type} object ['{name}'] ... at 0x{addr}> pattern. ---------- keywords: +patch Added file: http://bugs.python.org/file9691/doc-repr.diff ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 17 18:24:20 2008 From: report at bugs.python.org (Jack Diederich) Date: Mon, 17 Mar 2008 17:24:20 +0000 Subject: [issue2328] Class **kwds broken (PEP 3115) In-Reply-To: <1205774660.42.0.856799226329.issue2328@psf.upfronthosting.co.za> Message-ID: <1205774660.42.0.856799226329.issue2328@psf.upfronthosting.co.za> New submission from Jack Diederich : typeobject.c:type_new only allows 0 or 1 keyword arg in class creation instead of an arbitrary number as per PEP3115. I'm working on a patch. ---------- assignee: jackdied components: Interpreter Core messages: 63681 nosy: jackdied priority: normal severity: normal status: open title: Class **kwds broken (PEP 3115) type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:25:42 2008 From: report at bugs.python.org (dd) Date: Mon, 17 Mar 2008 17:25:42 +0000 Subject: [issue2329] ImportError: No module named _bsddb In-Reply-To: <1205774742.16.0.265427731372.issue2329@psf.upfronthosting.co.za> Message-ID: <1205774742.16.0.265427731372.issue2329@psf.upfronthosting.co.za> New submission from dd : Installation from source, python.2.4.5.tgz. It seems that severals *.so from bsddb are missing: >>> import bsddb Traceback (most recent call last): File "", line 1, in ? File "/tmp/Python-2.4.5/Lib/bsddb/__init__.py", line 47, in ? import _bsddb ImportError: No module named _bsddb ---------- components: Library (Lib) messages: 63682 nosy: ddk severity: normal status: open title: ImportError: No module named _bsddb versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:26:42 2008 From: report at bugs.python.org (Steven Bethard) Date: Mon, 17 Mar 2008 17:26:42 +0000 Subject: [issue2326] Doc isnumeric and isdecimal for the unicode object In-Reply-To: <1205772520.65.0.452257175762.issue2326@psf.upfronthosting.co.za> Message-ID: <1205774802.73.0.478656314968.issue2326@psf.upfronthosting.co.za> Steven Bethard added the comment: I'll take care of this, adding a bit to section 3.6.1, String Methods. ---------- nosy: +bethard __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:27:05 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 17 Mar 2008 17:27:05 +0000 Subject: [issue2298] Patch for "string without null bytes" check in getargs.c In-Reply-To: <1205647240.0.0.304059938651.issue2298@psf.upfronthosting.co.za> Message-ID: <1205774825.89.0.56838040458.issue2298@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: There is now issue2322 (Clean up getargs.c and its formatting possibilities) related to this. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:29:14 2008 From: report at bugs.python.org (Paul Winkler) Date: Mon, 17 Mar 2008 17:29:14 +0000 Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za> Message-ID: <1205774954.61.0.734336347056.issue1180@psf.upfronthosting.co.za> Paul Winkler added the comment: I'm working on this (at the pycon sprint). ---------- nosy: +slinkp __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:32:03 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 17:32:03 +0000 Subject: [issue2330] Update PEP 3000 with new release schedule In-Reply-To: <1205775123.38.0.0848585015118.issue2330@psf.upfronthosting.co.za> Message-ID: <1205775123.38.0.0848585015118.issue2330@psf.upfronthosting.co.za> New submission from Guido van Rossum : Barry, can you update the PEP with a discussion of the schedule, so we can refer to it? ---------- assignee: barry components: Documentation messages: 63686 nosy: barry, gvanrossum priority: urgent severity: normal status: open title: Update PEP 3000 with new release schedule versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:34:05 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Mar 2008 17:34:05 +0000 Subject: [issue1366] popen spawned process may not write to stdout under windows In-Reply-To: <1193824783.73.0.865697244253.issue1366@psf.upfronthosting.co.za> Message-ID: <1205775245.73.0.444910185005.issue1366@psf.upfronthosting.co.za> Sean Reifschneider added the comment: We've discussed this at the PyCon sprints, and here's the concensus: os.popen inherits the parents stderr, and on Windows there is not an existing valid stderr by default. So the parent should, to be compatible with the Windows environment, create stderr or use popen2. However, popen is deprecated. The best solution would be to use subprocess module which is defined to do the right thing in this case. popen is not. Because popen is deprecated, we are going to leave this behavior and documentation as it is. ---------- nosy: +jafo priority: -> normal resolution: -> wont fix __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:34:30 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 17:34:30 +0000 Subject: [issue2331] Backport parameter annotations In-Reply-To: <1205775270.85.0.593709274943.issue2331@psf.upfronthosting.co.za> Message-ID: <1205775270.85.0.593709274943.issue2331@psf.upfronthosting.co.za> New submission from Brett Cannon : Parameter annotations (e.g., ``def fxn(a:int) -> str: pass`` need to be backported. ---------- components: Interpreter Core keywords: 26backport messages: 63688 nosy: brett.cannon priority: immediate severity: normal status: open title: Backport parameter annotations type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:36:04 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 17:36:04 +0000 Subject: [issue2332] Renaming of attributes on functions need to be backported. In-Reply-To: <1205775364.33.0.962245412201.issue2332@psf.upfronthosting.co.za> Message-ID: <1205775364.33.0.962245412201.issue2332@psf.upfronthosting.co.za> New submission from Brett Cannon : It should be double-checked that the renaming of attributes from functions has been completed. ---------- assignee: nnorwitz components: Interpreter Core keywords: 26backport messages: 63689 nosy: brett.cannon, nnorwitz priority: immediate severity: normal status: open title: Renaming of attributes on functions need to be backported. type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:37:33 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 17:37:33 +0000 Subject: [issue2333] Backport dict comprehensions In-Reply-To: <1205775453.72.0.387864116054.issue2333@psf.upfronthosting.co.za> Message-ID: <1205775453.72.0.387864116054.issue2333@psf.upfronthosting.co.za> New submission from Brett Cannon : Dict comprehensions need to be backported. ---------- components: Interpreter Core keywords: 26backport messages: 63690 nosy: brett.cannon priority: immediate severity: normal status: open title: Backport dict comprehensions type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:38:17 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 17:38:17 +0000 Subject: [issue2334] Backport set comprehensions In-Reply-To: <1205775496.96.0.230528149509.issue2334@psf.upfronthosting.co.za> Message-ID: <1205775496.96.0.230528149509.issue2334@psf.upfronthosting.co.za> New submission from Brett Cannon : Set comprehensions need to be backported. ---------- components: Interpreter Core keywords: 26backport messages: 63691 nosy: brett.cannon priority: immediate severity: normal status: open title: Backport set comprehensions versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:38:47 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 17:38:47 +0000 Subject: [issue2335] Backport set literals In-Reply-To: <1205775527.12.0.350527481128.issue2335@psf.upfronthosting.co.za> Message-ID: <1205775527.12.0.350527481128.issue2335@psf.upfronthosting.co.za> New submission from Brett Cannon : Set literals need to be backported. ---------- components: Interpreter Core keywords: 26backport messages: 63692 nosy: brett.cannon priority: immediate severity: normal status: open title: Backport set literals type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:48:48 2008 From: report at bugs.python.org (Neal Norwitz) Date: Mon, 17 Mar 2008 17:48:48 +0000 Subject: [issue2321] return more memory from unicode objects to system In-Reply-To: <1205772952.0.0.890459758617.issue2321@psf.upfronthosting.co.za> Message-ID: Neal Norwitz added the comment: On Mon, Mar 17, 2008 at 11:55 AM, Alec Thomas wrote: > > Alec Thomas added the comment: > > Hi Neal, > > This seems to be a more general problem than just unicode. Kinda, sorta. The general issue is the pattern of memory allocation/deallocation. In the case of >>> x = [(1, 2, 3, 4, i) for i in xrange(800000)] The memory that is not returned is in the integer free list. If this code is changed to: >>> for x in ((1, 2, 3, 4, i) for i in xrange(800000)): pass That doesn't hold on to any extra memory. The problem is that holes are left in memory and a lot of it can't always be returned to the O/S. It can still be re-used by python. > Both exhibit the same behaviour. Naively to me it seems like using the > custom allocator uniformly would fix this problem. In general, we should find places (like unicode) that use PyMem_* (ie, system malloc) and replace them with PyObject_* (pymalloc). That should improve the behaviour, but there will always be some allocation patterns that will be suboptimal. Note that using pymalloc will only help for objects < 256 bytes. Larger objects are delegated to the system malloc and will still exhibit some of the bad problems. Alec, can you find places that are using the PyMem_* interface and create a patch to fix them. That would be great! __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:49:24 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 17:49:24 +0000 Subject: [issue2336] Backport PEP 3114 (__next__) In-Reply-To: <1205776164.44.0.568084726055.issue2336@psf.upfronthosting.co.za> Message-ID: <1205776164.44.0.568084726055.issue2336@psf.upfronthosting.co.za> New submission from Brett Cannon : PEP 3114 needs to be backported. Most likely the best approach is to backport the next() built-in but to have it call next() on the iterator instead of __next__(). That should hopefully minimize breakage while allowing for moving over to the new built-in. ---------- keywords: 26backport messages: 63694 nosy: brett.cannon priority: immediate severity: normal status: open title: Backport PEP 3114 (__next__) type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:51:06 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 17:51:06 +0000 Subject: [issue2337] Backport oct() and hex() to use __index__ In-Reply-To: <1205776266.64.0.297851457778.issue2337@psf.upfronthosting.co.za> Message-ID: <1205776266.64.0.297851457778.issue2337@psf.upfronthosting.co.za> New submission from Brett Cannon : oct() and hex() need to use __index__ when available and then emit a Py3K warning when they fall back on __oct__ and __hex__. ---------- components: Interpreter Core keywords: 26backport messages: 63695 nosy: brett.cannon priority: immediate severity: normal status: open title: Backport oct() and hex() to use __index__ versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:52:31 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Mar 2008 17:52:31 +0000 Subject: [issue1399] XML codec In-Reply-To: <1194457938.94.0.302802489446.issue1399@psf.upfronthosting.co.za> Message-ID: <1205776351.06.0.119868316598.issue1399@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Marc-Andre: Is this good to be committed, or does it need to be reviewed further? ---------- assignee: -> lemburg nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:53:00 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 17:53:00 +0000 Subject: [issue2338] Backport reload() moving to imp.reload() In-Reply-To: <1205776379.99.0.615033547761.issue2338@psf.upfronthosting.co.za> Message-ID: <1205776379.99.0.615033547761.issue2338@psf.upfronthosting.co.za> New submission from Brett Cannon : A fixer to change calls from reload() to imp.reload() needs to happen. Plus imp.reload() should come into existence. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) keywords: 26backport messages: 63697 nosy: brett.cannon, collinwinter priority: immediate severity: normal status: open title: Backport reload() moving to imp.reload() type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:55:49 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 17:55:49 +0000 Subject: [issue2339] Backport intern() -> sys.intern() In-Reply-To: <1205776549.43.0.234152621457.issue2339@psf.upfronthosting.co.za> Message-ID: <1205776549.43.0.234152621457.issue2339@psf.upfronthosting.co.za> New submission from Brett Cannon : intern() needs to be added as sys.intern(). Then a 2to3 fixer needs to be written. ---------- components: Interpreter Core keywords: 26backport messages: 63698 nosy: brett.cannon priority: immediate severity: normal status: open title: Backport intern() -> sys.intern() versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:56:12 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 17:56:12 +0000 Subject: [issue2338] Backport reload() moving to imp.reload() In-Reply-To: <1205776379.99.0.615033547761.issue2338@psf.upfronthosting.co.za> Message-ID: <1205776572.8.0.423128026244.issue2338@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- components: +Interpreter Core -2to3 (2.x to 3.0 conversion tool) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 18:58:35 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 17:58:35 +0000 Subject: [issue2340] Backport PEP 3132 (extended iterable unpacking) In-Reply-To: <1205776715.68.0.275061992416.issue2340@psf.upfronthosting.co.za> Message-ID: <1205776715.68.0.275061992416.issue2340@psf.upfronthosting.co.za> New submission from Brett Cannon : PEP 3132 (extended iterable unpacking) needs to be backported. ---------- components: Interpreter Core keywords: 26backport messages: 63699 nosy: brett.cannon priority: immediate severity: normal status: open title: Backport PEP 3132 (extended iterable unpacking) versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 19:01:01 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 18:01:01 +0000 Subject: [issue2291] Raise a Py3K warning for catching non-BaseException exceptions In-Reply-To: <1205533155.39.0.576388305845.issue2291@psf.upfronthosting.co.za> Message-ID: <1205776861.5.0.123925962286.issue2291@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: -> immediate title: Catching all exceptions with 'object' -> Raise a Py3K warning for catching non-BaseException exceptions __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 19:10:56 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 18:10:56 +0000 Subject: [issue2341] Raise a Py3K warning when raise non-BaseException exceptions In-Reply-To: <1205777456.01.0.538815512793.issue2341@psf.upfronthosting.co.za> Message-ID: <1205777456.01.0.538815512793.issue2341@psf.upfronthosting.co.za> New submission from Brett Cannon : Raising exceptions that do not inherit from BaseException (e.g., classic classes) should raise a Py3K warning. ---------- components: Interpreter Core keywords: 26backport messages: 63700 nosy: brett.cannon priority: immediate severity: normal status: open title: Raise a Py3K warning when raise non-BaseException exceptions type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 19:12:21 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 18:12:21 +0000 Subject: [issue2336] Backport PEP 3114 (__next__) In-Reply-To: <1205776164.44.0.568084726055.issue2336@psf.upfronthosting.co.za> Message-ID: <1205777541.46.0.00935409111584.issue2336@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I don't think this should be backported. It leaves Py2.6 with a confused mess of protocols. The 2-to-3 transformation is simple. Backporting doesn't add value. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 19:12:55 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 18:12:55 +0000 Subject: [issue2342] Comparing between disparate types should raise a Py3K warning In-Reply-To: <1205777575.3.0.830443648256.issue2342@psf.upfronthosting.co.za> Message-ID: <1205777575.3.0.830443648256.issue2342@psf.upfronthosting.co.za> New submission from Brett Cannon : When you compare disparate types through something other than == and != a Py3K warning should be raised. ---------- components: Interpreter Core keywords: 26backport messages: 63702 nosy: brett.cannon priority: immediate severity: normal status: open title: Comparing between disparate types should raise a Py3K warning versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 19:14:26 2008 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Mon, 17 Mar 2008 18:14:26 +0000 Subject: [issue1399] XML codec In-Reply-To: <1194457938.94.0.302802489446.issue1399@psf.upfronthosting.co.za> Message-ID: <1205777666.53.0.373384461635.issue1399@psf.upfronthosting.co.za> Walter D?rwald added the comment: There was resistance in python-dev against this patch (see the thread at http://mail.python.org/pipermail/python-dev/2007-November/075138.html), so this issue should probably closed as rejected. However there was consensus, that a detect_xml_encoding() function might be usefull. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 19:16:18 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 18:16:18 +0000 Subject: [issue2343] Raise a Py3K warning when using a float where an int is expected In-Reply-To: <1205777778.13.0.206701956987.issue2343@psf.upfronthosting.co.za> Message-ID: <1205777778.13.0.206701956987.issue2343@psf.upfronthosting.co.za> New submission from Brett Cannon : Using a float where an int should only be used (e.g., ``[].insert(.5, 0)``) should raise a Py3K warning. ---------- components: Interpreter Core keywords: 26backport messages: 63704 nosy: brett.cannon priority: immediate severity: normal status: open title: Raise a Py3K warning when using a float where an int is expected versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 19:18:56 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Mar 2008 18:18:56 +0000 Subject: [issue1328] Force BOM option in UTF output. In-Reply-To: <1193353176.1.0.485065586233.issue1328@psf.upfronthosting.co.za> Message-ID: <1205777936.83.0.47143256057.issue1328@psf.upfronthosting.co.za> Sean Reifschneider added the comment: It sounds like the Unicode FAQ has an authoritative statement on this, is this a "wontfix", or does this need more discussion? Perhaps on python-dev or at the sprints this week? ---------- assignee: -> doerwalter nosy: +jafo priority: -> normal title: feature request: force BOM option -> Force BOM option in UTF output. type: behavior -> feature request __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 19:20:04 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 18:20:04 +0000 Subject: [issue2344] Using an iteration variable outside a list comprehension needs a Py3K warning In-Reply-To: <1205778004.51.0.0647688258878.issue2344@psf.upfronthosting.co.za> Message-ID: <1205778004.51.0.0647688258878.issue2344@psf.upfronthosting.co.za> New submission from Brett Cannon : If you use a iteration variable from a list comprehension from outside the list comprehension itself should raise a Py3K warning. ---------- components: Interpreter Core keywords: 26backport messages: 63706 nosy: brett.cannon priority: immediate severity: normal status: open title: Using an iteration variable outside a list comprehension needs a Py3K warning type: behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 19:23:28 2008 From: report at bugs.python.org (Domen) Date: Mon, 17 Mar 2008 18:23:28 +0000 Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217 In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za> Message-ID: <1205778208.54.0.518918419376.issue2054@psf.upfronthosting.co.za> Domen added the comment: The lib should give programmer choice wether to send login through TLS or not. (as it is described in RFC 4217). Also, there should be an optional parameter to specify port for ftp connection. ---------- nosy: +iElectric __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 19:29:09 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 18:29:09 +0000 Subject: [issue2345] Using an exception variable outside an 'except' clause should raise a Py3K warning In-Reply-To: <1205778549.05.0.340690581025.issue2345@psf.upfronthosting.co.za> Message-ID: <1205778549.05.0.340690581025.issue2345@psf.upfronthosting.co.za> New submission from Brett Cannon : If one tries to use an exception bound to a variable in an 'except' clause it should raise a Py3K warning. ---------- components: Interpreter Core keywords: 26backport messages: 63708 nosy: brett.cannon priority: immediate severity: normal status: open title: Using an exception variable outside an 'except' clause should raise a Py3K warning type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 19:39:02 2008 From: report at bugs.python.org (Steven Bethard) Date: Mon, 17 Mar 2008 18:39:02 +0000 Subject: [issue2326] Doc isnumeric and isdecimal for the unicode object In-Reply-To: <1205772520.65.0.452257175762.issue2326@psf.upfronthosting.co.za> Message-ID: <1205779142.09.0.40829287462.issue2326@psf.upfronthosting.co.za> Steven Bethard added the comment: I've got a patch against 2.6, and the docs seem to build fine. Since I've never committed a doc patch before, I'd appreciate it if someone could glance at this and make sure there's nothing obviously wrong. ---------- keywords: +patch Added file: http://bugs.python.org/file9692/unicode_methods.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 19:54:03 2008 From: report at bugs.python.org (Alec Thomas) Date: Mon, 17 Mar 2008 18:54:03 +0000 Subject: [issue2321] return more memory from unicode objects to system In-Reply-To: <1205768902.73.0.245115475399.issue2321@psf.upfronthosting.co.za> Message-ID: <1205780043.98.0.780624533911.issue2321@psf.upfronthosting.co.za> Alec Thomas added the comment: > Alec, can you find places that are using the PyMem_* interface and > create a patch to fix them. That would be great! Sure thing! I'll see if I can finish it today, but if not I'll work on it during the flight to Zurich tonight. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:01:42 2008 From: report at bugs.python.org (Gregor Lingl) Date: Mon, 17 Mar 2008 19:01:42 +0000 Subject: [issue1513695] new turtle module Message-ID: <1205780502.63.0.910984789751.issue1513695@psf.upfronthosting.co.za> Gregor Lingl added the comment: This version runs under Python 2.5 and should run under python 2.6 It still needs some amendments and polishing concerning the code as well as the docstrings. Here it can serve as a starting point for a discussion about necessary and/or desirable modifications. A version for Python-3000 is under construction For the new features please consult xturtle-docs. Remarks on Martin's 10 points (msg 50550): 1) Should be discussed. I think a few demos would be fine, the whole package perhaps would be to large. (I'll prepare a selection and upload it in due time) 2) decision about replacement or supllement has still to be done. This update will be easy ;-) 3) Who is that somebody? 4) Still has to be done 5) I for my part don't like Point, because this name refers more to the geometrical than to the computational aspects of the object. What about _Vec2 or _Vec2D? In this version an alias without the leading underscore can be created via an entry in the xturtle.cfg file. 6) camelCase methodnames are changed to lowercase (at least the public ones) 7) Docstrings has still to be checked 8) n argument of clear has been dropped. 9) checkargs has been dropped (for now). It's purpose was intended to be to check the types of the arguments and construct appropriate error messages useful for programming beginners. I deferred it until I eventually be able to come up with some intelligent solution using decorators ;-) Would be fine but is not urgent. 10) Maybe there are still a few. These will be changed. ---------- nosy: +glingl versions: +Python 2.6 -Python 2.4 Added file: http://bugs.python.org/file9693/xturtle.py _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 17 20:05:15 2008 From: report at bugs.python.org (Gregor Lingl) Date: Mon, 17 Mar 2008 19:05:15 +0000 Subject: [issue1513695] new turtle module Message-ID: <1205780715.78.0.996604212381.issue1513695@psf.upfronthosting.co.za> Changes by Gregor Lingl : Added file: http://bugs.python.org/file9694/xturtle-docs.txt _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 17 20:14:48 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 17 Mar 2008 19:14:48 +0000 Subject: [issue2326] Doc isnumeric and isdecimal for the unicode object In-Reply-To: <1205772520.65.0.452257175762.issue2326@psf.upfronthosting.co.za> Message-ID: <1205781288.67.0.335331600323.issue2326@psf.upfronthosting.co.za> Georg Brandl added the comment: Looks good to me. ---------- resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:15:56 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:15:56 +0000 Subject: [issue2346] Py3K warn against using __members__ In-Reply-To: <1205781355.97.0.143101300316.issue2346@psf.upfronthosting.co.za> Message-ID: <1205781355.97.0.143101300316.issue2346@psf.upfronthosting.co.za> New submission from Brett Cannon : Using __members__ should raise a Py3K warning. ---------- components: Interpreter Core keywords: 26backport messages: 63713 nosy: brett.cannon priority: immediate severity: normal status: open title: Py3K warn against using __members__ versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:16:17 2008 From: report at bugs.python.org (Gregor Lingl) Date: Mon, 17 Mar 2008 19:16:17 +0000 Subject: [issue1513695] new turtle module Message-ID: <1205781377.12.0.55626306444.issue1513695@psf.upfronthosting.co.za> Gregor Lingl added the comment: If you put (this example of) xturtle.cfg either into the directory where xturtle.py resides or into the current working directory, the configuration will be loaded. In this case window size and turtle are configured to look like in module turtle. If no config-file is found a standard configuration is used. (This standard configuration currently uses a scrolled canvas but could of course be changed to look like that furnished by the above cfg-file.) Added file: http://bugs.python.org/file9695/xturtle.cfg _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 17 20:16:35 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:16:35 +0000 Subject: [issue2347] Py3K warn for using __methods__ In-Reply-To: <1205781395.77.0.22785481066.issue2347@psf.upfronthosting.co.za> Message-ID: <1205781395.77.0.22785481066.issue2347@psf.upfronthosting.co.za> New submission from Brett Cannon : Using __methods__ should trigger a Py3K warning. ---------- components: Interpreter Core keywords: 26backport messages: 63715 nosy: brett.cannon priority: immediate severity: normal status: open title: Py3K warn for using __methods__ versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:17:34 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:17:34 +0000 Subject: [issue2348] Py3K warn using file.whitespace In-Reply-To: <1205781454.44.0.267838748773.issue2348@psf.upfronthosting.co.za> Message-ID: <1205781454.44.0.267838748773.issue2348@psf.upfronthosting.co.za> New submission from Brett Cannon : A Py3K warning should be raised if file.whitespace is used in any way. ---------- components: Interpreter Core keywords: 26backport messages: 63716 nosy: brett.cannon priority: immediate severity: normal status: open title: Py3K warn using file.whitespace versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:19:15 2008 From: report at bugs.python.org (chrysn) Date: Mon, 17 Mar 2008 19:19:15 +0000 Subject: [issue1649329] gettext.py incompatible with eggs Message-ID: <1205781555.23.0.358953460027.issue1649329@psf.upfronthosting.co.za> Changes by chrysn : ---------- nosy: +chrysn _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 17 20:19:18 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:19:18 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> New submission from Brett Cannon : Assigning to True of False should raise at least a Py3K warning (maybe something more severe?). ---------- components: Interpreter Core keywords: 26backport messages: 63717 nosy: brett.cannon priority: immediate severity: normal status: open title: Py3K warn against assigning to True/False versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:22:09 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:22:09 +0000 Subject: [issue2350] Warn against importing 'exceptions' In-Reply-To: <1205781728.94.0.172904523331.issue2350@psf.upfronthosting.co.za> Message-ID: <1205781728.94.0.172904523331.issue2350@psf.upfronthosting.co.za> New submission from Brett Cannon : Importing 'exceptions' should raise at least a Py3K warning, if not a full DeprecationWarning. ---------- keywords: 26backport messages: 63718 nosy: brett.cannon priority: immediate severity: normal status: open title: Warn against importing 'exceptions' versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:24:27 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 17 Mar 2008 19:24:27 +0000 Subject: [issue1513695] new turtle module Message-ID: <1205781867.71.0.0115331904432.issue1513695@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- versions: +Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 17 20:24:24 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 17 Mar 2008 19:24:24 +0000 Subject: [issue2309] Add xturtle to the standard library? In-Reply-To: <1205702565.16.0.164147436209.issue2309@psf.upfronthosting.co.za> Message-ID: <1205781864.52.0.583314713835.issue2309@psf.upfronthosting.co.za> Georg Brandl added the comment: Closing in favor of #1513695. ---------- nosy: +georg.brandl superseder: -> new turtle module __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:24:37 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 17 Mar 2008 19:24:37 +0000 Subject: [issue2309] Add xturtle to the standard library? In-Reply-To: <1205702565.16.0.164147436209.issue2309@psf.upfronthosting.co.za> Message-ID: <1205781877.93.0.442784715162.issue2309@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:25:22 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 17 Mar 2008 19:25:22 +0000 Subject: [issue2310] Reorganize the 3.0 Misc/NEWS file In-Reply-To: <1205702758.46.0.979295500245.issue2310@psf.upfronthosting.co.za> Message-ID: <1205781922.76.0.181925625438.issue2310@psf.upfronthosting.co.za> Georg Brandl added the comment: Stuff ported from 2.6 needn't be in the 3.0 NEWS, needs it? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:25:50 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:25:50 +0000 Subject: [issue2351] Using __(get|set|del)slice__ needs a Py3K warning In-Reply-To: <1205781950.27.0.373262403041.issue2351@psf.upfronthosting.co.za> Message-ID: <1205781950.27.0.373262403041.issue2351@psf.upfronthosting.co.za> New submission from Brett Cannon : Using any of the slicing methods (e.g., __getslice__) should raise a Py3K warning. ---------- components: Interpreter Core keywords: 26backport messages: 63721 nosy: brett.cannon priority: immediate severity: normal status: open title: Using __(get|set|del)slice__ needs a Py3K warning versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:26:31 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 17 Mar 2008 19:26:31 +0000 Subject: [issue2315] TimedRotatingFileHandler does not account for daylight savings time In-Reply-To: <1205740809.7.0.649649150956.issue2315@psf.upfronthosting.co.za> Message-ID: <1205781991.35.0.157224525667.issue2315@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: -> vsajip nosy: +vsajip __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:26:37 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 17 Mar 2008 19:26:37 +0000 Subject: [issue2316] TimedRotatingFileHandler names files incorrectly if nothing is logged during an interval In-Reply-To: <1205741875.35.0.669932771172.issue2316@psf.upfronthosting.co.za> Message-ID: <1205781997.12.0.402047493818.issue2316@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: -> vsajip nosy: +vsajip __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:26:43 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 17 Mar 2008 19:26:43 +0000 Subject: [issue2317] TimedRotatingFileHandler logic for removing files wrong In-Reply-To: <1205742576.84.0.607022841001.issue2317@psf.upfronthosting.co.za> Message-ID: <1205782003.68.0.580229434137.issue2317@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: -> vsajip nosy: +vsajip __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:26:49 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 17 Mar 2008 19:26:49 +0000 Subject: [issue2318] TimedRotatingFileHandler: rotate every month, or every year In-Reply-To: <1205742779.64.0.634680353877.issue2318@psf.upfronthosting.co.za> Message-ID: <1205782009.0.0.680967970975.issue2318@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: -> vsajip nosy: +vsajip __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:27:14 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:27:14 +0000 Subject: [issue2352] Use of __oct__/__hex__ should raise a Py3K warning In-Reply-To: <1205782034.73.0.229035988217.issue2352@psf.upfronthosting.co.za> Message-ID: <1205782034.73.0.229035988217.issue2352@psf.upfronthosting.co.za> New submission from Brett Cannon : Use of __hex__ and __oct__ should raise a Py3K warning. ---------- components: Interpreter Core keywords: 26backport messages: 63722 nosy: brett.cannon priority: immediate severity: normal status: open title: Use of __oct__/__hex__ should raise a Py3K warning versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:27:34 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 17 Mar 2008 19:27:34 +0000 Subject: [issue448736] pydoc needs readline completion Message-ID: <1205782054.08.0.987229405348.issue448736@psf.upfronthosting.co.za> Georg Brandl added the comment: Closing as duplicate, then. ---------- nosy: +georg.brandl resolution: -> duplicate status: open -> closed superseder: -> help() with readline support ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 17 20:29:00 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:29:00 +0000 Subject: [issue2353] Use of file.xreadlines() should raise a Py3K warning In-Reply-To: <1205782140.75.0.577448630615.issue2353@psf.upfronthosting.co.za> Message-ID: <1205782140.75.0.577448630615.issue2353@psf.upfronthosting.co.za> New submission from Brett Cannon : Using file.xreadlines() should raise a Py3K warning. ---------- components: Interpreter Core keywords: 26backport messages: 63724 nosy: brett.cannon priority: immediate severity: normal status: open title: Use of file.xreadlines() should raise a Py3K warning versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:30:11 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:30:11 +0000 Subject: [issue2354] cmp argument to list.sort()/sorted() should raise a Py3K warning In-Reply-To: <1205782211.6.0.934088370296.issue2354@psf.upfronthosting.co.za> Message-ID: <1205782211.6.0.934088370296.issue2354@psf.upfronthosting.co.za> New submission from Brett Cannon : The cmp argument for list.sort() and sorted() should raise a Py3K warning. ---------- keywords: 26backport messages: 63725 nosy: brett.cannon priority: immediate severity: normal status: open title: cmp argument to list.sort()/sorted() should raise a Py3K warning __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:30:56 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:30:56 +0000 Subject: [issue2355] Using buffer() should raise a Py3K warning In-Reply-To: <1205782256.14.0.33369210051.issue2355@psf.upfronthosting.co.za> Message-ID: <1205782256.14.0.33369210051.issue2355@psf.upfronthosting.co.za> New submission from Brett Cannon : Using buffer() should raise a Py3K warning. ---------- components: Interpreter Core keywords: 26backport messages: 63726 nosy: brett.cannon priority: immediate severity: normal status: open title: Using buffer() should raise a Py3K warning versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:33:12 2008 From: report at bugs.python.org (Jack Diederich) Date: Mon, 17 Mar 2008 19:33:12 +0000 Subject: [issue2328] Class **kwds broken (PEP 3115) In-Reply-To: <1205774660.42.0.856799226329.issue2328@psf.upfronthosting.co.za> Message-ID: <1205782392.09.0.0308536611098.issue2328@psf.upfronthosting.co.za> Jack Diederich added the comment: Not a bug. If you pass arbitrary keywords in class construction you have to define __new__ and __init__ on the metaclass to handle them. ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:34:19 2008 From: report at bugs.python.org (Steven Bethard) Date: Mon, 17 Mar 2008 19:34:19 +0000 Subject: [issue2326] Doc isnumeric and isdecimal for the unicode object In-Reply-To: <1205772520.65.0.452257175762.issue2326@psf.upfronthosting.co.za> Message-ID: <1205782459.62.0.540796399323.issue2326@psf.upfronthosting.co.za> Steven Bethard added the comment: Committed in revision 61453. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:35:01 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 19:35:01 +0000 Subject: [issue2310] Reorganize the 3.0 Misc/NEWS file In-Reply-To: <1205702758.46.0.979295500245.issue2310@psf.upfronthosting.co.za> Message-ID: <1205782501.16.0.352469423703.issue2310@psf.upfronthosting.co.za> Guido van Rossum added the comment: Correct. Martin & I just discussed this. We'll empty the current 3.0 NEWS file and start adding stuff consistently from 3.0a3, but skipping stuff merged from 3.0. For the big changes since 2.x, people will have to refer to other porting docs, like whatsnew. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:35:21 2008 From: report at bugs.python.org (Joseph Armbruster) Date: Mon, 17 Mar 2008 19:35:21 +0000 Subject: [issue2313] correct int / long object type casts In-Reply-To: <1205709502.77.0.893498330113.issue2313@psf.upfronthosting.co.za> Message-ID: <1205782521.86.0.208443454754.issue2313@psf.upfronthosting.co.za> Changes by Joseph Armbruster : ---------- type: -> compile error __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:37:05 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Mar 2008 19:37:05 +0000 Subject: [issue1477] UnicodeDecodeError that cannot be caught in narrow unicode builds In-Reply-To: <1195593459.02.0.388666867716.issue1477@psf.upfronthosting.co.za> Message-ID: <1205782625.0.0.756752062966.issue1477@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Can someone comment on this, or bring it up on python-dev if it needs more discussion? ---------- assignee: -> doerwalter nosy: +doerwalter, jafo priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:37:32 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:37:32 +0000 Subject: [issue2356] sys.exitfunc should raise a Py3K warning In-Reply-To: <1205782652.14.0.516090878435.issue2356@psf.upfronthosting.co.za> Message-ID: <1205782652.14.0.516090878435.issue2356@psf.upfronthosting.co.za> New submission from Brett Cannon : sys.exitfunc should raise a Py3K warning when set/used. ---------- components: Interpreter Core keywords: 26backport messages: 63731 nosy: brett.cannon priority: immediate severity: normal status: open title: sys.exitfunc should raise a Py3K warning versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:38:47 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:38:47 +0000 Subject: [issue2357] sys.exc_{type, values, traceback} should raise a Py3K warning In-Reply-To: <1205782726.96.0.925182629024.issue2357@psf.upfronthosting.co.za> Message-ID: <1205782726.96.0.925182629024.issue2357@psf.upfronthosting.co.za> New submission from Brett Cannon : Using sys.exc_{type,values,traceback} should raise a Py3K warning. ---------- components: Interpreter Core keywords: 26backport messages: 63732 nosy: brett.cannon priority: immediate severity: normal status: open title: sys.exc_{type,values,traceback} should raise a Py3K warning type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:39:31 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:39:31 +0000 Subject: [issue2358] Using sys.exc_clear should raise a Py3K warning In-Reply-To: <1205782771.08.0.305016984378.issue2358@psf.upfronthosting.co.za> Message-ID: <1205782771.08.0.305016984378.issue2358@psf.upfronthosting.co.za> New submission from Brett Cannon : Using sys.exc_clear should raise a Py3K warning. ---------- components: Interpreter Core keywords: 26backport messages: 63733 nosy: brett.cannon priority: immediate severity: normal status: open title: Using sys.exc_clear should raise a Py3K warning versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:40:57 2008 From: report at bugs.python.org (Steven Bethard) Date: Mon, 17 Mar 2008 19:40:57 +0000 Subject: [issue2342] Comparing between disparate types should raise a Py3K warning In-Reply-To: <1205777575.3.0.830443648256.issue2342@psf.upfronthosting.co.za> Message-ID: <1205782857.77.0.238431161269.issue2342@psf.upfronthosting.co.za> Steven Bethard added the comment: I'll start looking at this. ---------- nosy: +bethard __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:41:23 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:41:23 +0000 Subject: [issue2359] A Py3K warning for array.array.{read,write} is needed In-Reply-To: <1205782883.21.0.134767238935.issue2359@psf.upfronthosting.co.za> Message-ID: <1205782883.21.0.134767238935.issue2359@psf.upfronthosting.co.za> New submission from Brett Cannon : array.{read,write} from the array module should raise at least a Py3K warning, if not a DeprecationWarning. ---------- components: Interpreter Core keywords: 26backport messages: 63735 nosy: brett.cannon priority: immediate severity: normal status: open title: A Py3K warning for array.array.{read,write} is needed versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:46:01 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:46:01 +0000 Subject: [issue2360] Fixer for itertools.imap() -> map() In-Reply-To: <1205783160.99.0.976261842944.issue2360@psf.upfronthosting.co.za> Message-ID: <1205783160.99.0.976261842944.issue2360@psf.upfronthosting.co.za> New submission from Brett Cannon : A fixer for converting itertools.imap() to -> map() is needed. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) keywords: 26backport messages: 63736 nosy: brett.cannon, collinwinter priority: immediate severity: normal status: open title: Fixer for itertools.imap() -> map() type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:47:30 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:47:30 +0000 Subject: [issue2361] Fixer for itertools.ifilter() -> filter() In-Reply-To: <1205783250.41.0.363081316458.issue2361@psf.upfronthosting.co.za> Message-ID: <1205783250.41.0.363081316458.issue2361@psf.upfronthosting.co.za> New submission from Brett Cannon : A fixer to go from itertools.ifilter() to filter() is needed. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) keywords: 26backport messages: 63737 nosy: brett.cannon, collinwinter priority: immediate severity: normal status: open title: Fixer for itertools.ifilter() -> filter() versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:48:07 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:48:07 +0000 Subject: [issue2362] Fixer for itertools.izip() -> zip() In-Reply-To: <1205783287.8.0.394861371785.issue2362@psf.upfronthosting.co.za> Message-ID: <1205783287.8.0.394861371785.issue2362@psf.upfronthosting.co.za> New submission from Brett Cannon : A fixer for itertools.izip() to zip() is needed. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) keywords: 26backport messages: 63738 nosy: brett.cannon, collinwinter priority: immediate severity: normal status: open title: Fixer for itertools.izip() -> zip() versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:50:15 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:50:15 +0000 Subject: [issue2363] Fixer for itertools.ifilterfalse() -> itertools.filterfalse() In-Reply-To: <1205783415.62.0.638293283176.issue2363@psf.upfronthosting.co.za> Message-ID: <1205783415.62.0.638293283176.issue2363@psf.upfronthosting.co.za> New submission from Brett Cannon : A fixer is needed to go from itertools.ifilterfalse() to itertools.filterfalse(). ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) keywords: 26backport messages: 63739 nosy: brett.cannon, collinwinter priority: immediate severity: normal status: open title: Fixer for itertools.ifilterfalse() -> itertools.filterfalse() type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:50:39 2008 From: report at bugs.python.org (David Wolever) Date: Mon, 17 Mar 2008 19:50:39 +0000 Subject: [issue2364] Patch to make 2to3 testing easier In-Reply-To: <1205783439.73.0.272179327902.issue2364@psf.upfronthosting.co.za> Message-ID: <1205783439.73.0.272179327902.issue2364@psf.upfronthosting.co.za> New submission from David Wolever : This patch makes it easier to run tests in the 2to3 suite. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) files: 2to3tester.patch keywords: patch messages: 63740 nosy: David Wolever, collinwinter severity: normal status: open title: Patch to make 2to3 testing easier type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file9696/2to3tester.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:52:40 2008 From: report at bugs.python.org (Jeff Balogh) Date: Mon, 17 Mar 2008 19:52:40 +0000 Subject: [issue2091] file accepts 'rU+' as a mode In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za> Message-ID: <1205783560.68.0.944631976684.issue2091@psf.upfronthosting.co.za> Jeff Balogh added the comment: Attaching a patch that checks for '+' in the mode string, updates the docs, and tests bad mode strings. ---------- keywords: +patch nosy: +jbalogh Added file: http://bugs.python.org/file9697/issue2091.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:53:15 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:53:15 +0000 Subject: [issue2365] Fixer for filter(None, ...) -> filter(bool, ...) In-Reply-To: <1205783595.14.0.905564952624.issue2365@psf.upfronthosting.co.za> Message-ID: <1205783595.14.0.905564952624.issue2365@psf.upfronthosting.co.za> New submission from Brett Cannon : A fixer to go from filter(None, ..) to filter(bool, ..) is needed. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) keywords: 26backport messages: 63742 nosy: brett.cannon, collinwinter priority: immediate severity: normal status: open title: Fixer for filter(None, ...) -> filter(bool, ...) versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:54:32 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:54:32 +0000 Subject: [issue2366] Fixer for new metaclass syntax is needed In-Reply-To: <1205783672.52.0.982802083184.issue2366@psf.upfronthosting.co.za> Message-ID: <1205783672.52.0.982802083184.issue2366@psf.upfronthosting.co.za> New submission from Brett Cannon : * new metaclass syntax (removing __metaclass__?) - __metaclass__ = type at global level disappear - __metaclass__ = should generate warning - __metaclass__ = within a class should use new syntax - class __metaclass__ should be warned about - any other use of __metaclass__ should be warned about ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) keywords: 26backport messages: 63743 nosy: brett.cannon, collinwinter priority: immediate severity: normal status: open title: Fixer for new metaclass syntax is needed type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:55:54 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:55:54 +0000 Subject: [issue2367] Fixer to handle new places where parentheses are needed In-Reply-To: <1205783754.65.0.365050189029.issue2367@psf.upfronthosting.co.za> Message-ID: <1205783754.65.0.365050189029.issue2367@psf.upfronthosting.co.za> New submission from Brett Cannon : Py3K has some places where parentheses are now required (e.g., ``[x for x in 1, 2]`` to ``[x for x in (1, 2)``). A fixer is needed to handle the conversion. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) keywords: 26backport messages: 63744 nosy: brett.cannon, collinwinter priority: immediate severity: normal status: open title: Fixer to handle new places where parentheses are needed type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:57:05 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:57:05 +0000 Subject: [issue2368] Backport __builtin__ to 'builtins' In-Reply-To: <1205783825.31.0.623855463927.issue2368@psf.upfronthosting.co.za> Message-ID: <1205783825.31.0.623855463927.issue2368@psf.upfronthosting.co.za> New submission from Brett Cannon : 'builtins' needs to be added as a module for __builtin__. A fixer will also be needed. ---------- components: Interpreter Core keywords: 26backport messages: 63745 nosy: brett.cannon priority: immediate severity: normal status: open title: Backport __builtin__ to 'builtins' type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:58:51 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:58:51 +0000 Subject: [issue2356] sys.exitfunc should raise a Py3K warning In-Reply-To: <1205782652.14.0.516090878435.issue2356@psf.upfronthosting.co.za> Message-ID: <1205783931.71.0.876515466211.issue2356@psf.upfronthosting.co.za> Brett Cannon added the comment: A fixer to use the atexit module is needed. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 20:59:24 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 19:59:24 +0000 Subject: [issue2357] sys.exc_{type, values, traceback} should raise a Py3K warning In-Reply-To: <1205782726.96.0.925182629024.issue2357@psf.upfronthosting.co.za> Message-ID: <1205783964.52.0.150998644177.issue2357@psf.upfronthosting.co.za> Brett Cannon added the comment: A fixer to use sys.exc_info is needed. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:00:13 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 20:00:13 +0000 Subject: [issue2354] cmp argument to list.sort()/sorted() should raise a Py3K warning In-Reply-To: <1205782211.6.0.934088370296.issue2354@psf.upfronthosting.co.za> Message-ID: <1205784013.92.0.634734771729.issue2354@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I've got this one. ---------- assignee: -> rhettinger nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:00:32 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:00:32 +0000 Subject: [issue2369] Fixer for new integer literals are needed In-Reply-To: <1205784031.99.0.585423038669.issue2369@psf.upfronthosting.co.za> Message-ID: <1205784031.99.0.585423038669.issue2369@psf.upfronthosting.co.za> New submission from Brett Cannon : A fixer(s) to handle the new integer literals are needed. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) keywords: 26backport messages: 63749 nosy: brett.cannon, collinwinter priority: immediate severity: normal status: open title: Fixer for new integer literals are needed versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:03:59 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 17 Mar 2008 20:03:59 +0000 Subject: [issue2339] Backport intern() -> sys.intern() In-Reply-To: <1205776549.43.0.234152621457.issue2339@psf.upfronthosting.co.za> Message-ID: <1205784239.12.0.425700316917.issue2339@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Here's a patch which moves intern to sysmodule.c, adds a Py3k warning, updates the docs, and moves the tests. ---------- keywords: +patch nosy: +benjamin.peterson Added file: http://bugs.python.org/file9698/backport_sys_intern.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:04:33 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:04:33 +0000 Subject: [issue2370] operator.{isCallable,sequenceIncludes} needs a fixer In-Reply-To: <1205784272.93.0.866002228926.issue2370@psf.upfronthosting.co.za> Message-ID: <1205784272.93.0.866002228926.issue2370@psf.upfronthosting.co.za> New submission from Brett Cannon : A fixer for operator.{isCallable,sequenceIncludes} similar to the one for callable() is needed. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) keywords: 26backport messages: 63751 nosy: brett.cannon, collinwinter priority: immediate severity: normal status: open title: operator.{isCallable,sequenceIncludes} needs a fixer type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:04:54 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 20:04:54 +0000 Subject: [issue2365] Fixer for filter(None, ...) -> filter(bool, ...) In-Reply-To: <1205783595.14.0.905564952624.issue2365@psf.upfronthosting.co.za> Message-ID: <1205784294.95.0.249796874264.issue2365@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: collinwinter -> rhettinger nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:08:13 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:08:13 +0000 Subject: [issue2322] Clean up getargs.c and its formatting possibilities In-Reply-To: <1205771270.76.0.30305062324.issue2322@psf.upfronthosting.co.za> Message-ID: <1205784493.46.0.22615172366.issue2322@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:08:57 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:08:57 +0000 Subject: [issue2323] Unify structseq and namedtuple's API In-Reply-To: <1205771667.83.0.681502782029.issue2323@psf.upfronthosting.co.za> Message-ID: <1205784537.23.0.557839684209.issue2323@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:09:07 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:09:07 +0000 Subject: [issue2327] Backport keyword-only arguments to 2.6 In-Reply-To: <1205774336.48.0.251602118658.issue2327@psf.upfronthosting.co.za> Message-ID: <1205784547.28.0.160815503258.issue2327@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:09:20 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:09:20 +0000 Subject: [issue2331] Backport parameter annotations In-Reply-To: <1205775270.85.0.593709274943.issue2331@psf.upfronthosting.co.za> Message-ID: <1205784560.33.0.351251705358.issue2331@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:09:47 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:09:47 +0000 Subject: [issue2332] Renaming of attributes on functions need to be backported. In-Reply-To: <1205775364.33.0.962245412201.issue2332@psf.upfronthosting.co.za> Message-ID: <1205784587.28.0.768019632147.issue2332@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:10:00 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:10:00 +0000 Subject: [issue2333] Backport dict comprehensions In-Reply-To: <1205775453.72.0.387864116054.issue2333@psf.upfronthosting.co.za> Message-ID: <1205784600.34.0.542198890867.issue2333@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:10:14 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:10:14 +0000 Subject: [issue2334] Backport set comprehensions In-Reply-To: <1205775496.96.0.230528149509.issue2334@psf.upfronthosting.co.za> Message-ID: <1205784614.87.0.572517795593.issue2334@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:10:26 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:10:26 +0000 Subject: [issue2335] Backport set literals In-Reply-To: <1205775527.12.0.350527481128.issue2335@psf.upfronthosting.co.za> Message-ID: <1205784626.6.0.418144327761.issue2335@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:10:36 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:10:36 +0000 Subject: [issue2337] Backport oct() and hex() to use __index__ In-Reply-To: <1205776266.64.0.297851457778.issue2337@psf.upfronthosting.co.za> Message-ID: <1205784636.96.0.543947240358.issue2337@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:10:46 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:10:46 +0000 Subject: [issue2338] Backport reload() moving to imp.reload() In-Reply-To: <1205776379.99.0.615033547761.issue2338@psf.upfronthosting.co.za> Message-ID: <1205784646.25.0.707218499021.issue2338@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:10:58 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:10:58 +0000 Subject: [issue2340] Backport PEP 3132 (extended iterable unpacking) In-Reply-To: <1205776715.68.0.275061992416.issue2340@psf.upfronthosting.co.za> Message-ID: <1205784658.41.0.308125463027.issue2340@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:11:11 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:11:11 +0000 Subject: [issue2291] Raise a Py3K warning for catching non-BaseException exceptions In-Reply-To: <1205533155.39.0.576388305845.issue2291@psf.upfronthosting.co.za> Message-ID: <1205784671.1.0.110696630922.issue2291@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:11:24 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:11:24 +0000 Subject: [issue2341] Raise a Py3K warning when raise non-BaseException exceptions In-Reply-To: <1205777456.01.0.538815512793.issue2341@psf.upfronthosting.co.za> Message-ID: <1205784684.26.0.243180194005.issue2341@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:11:37 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:11:37 +0000 Subject: [issue2336] Backport PEP 3114 (__next__) In-Reply-To: <1205776164.44.0.568084726055.issue2336@psf.upfronthosting.co.za> Message-ID: <1205784697.27.0.824880447972.issue2336@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:11:51 2008 From: report at bugs.python.org (Jack Diederich) Date: Mon, 17 Mar 2008 20:11:51 +0000 Subject: [issue2366] Fixer for new metaclass syntax is needed In-Reply-To: <1205783672.52.0.982802083184.issue2366@psf.upfronthosting.co.za> Message-ID: <1205784711.39.0.1142156507.issue2366@psf.upfronthosting.co.za> Changes by Jack Diederich : ---------- nosy: +jackdied __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:11:48 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:11:48 +0000 Subject: [issue2343] Raise a Py3K warning when using a float where an int is expected In-Reply-To: <1205777778.13.0.206701956987.issue2343@psf.upfronthosting.co.za> Message-ID: <1205784708.22.0.188467811725.issue2343@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:12:00 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:12:00 +0000 Subject: [issue2344] Using an iteration variable outside a list comprehension needs a Py3K warning In-Reply-To: <1205778004.51.0.0647688258878.issue2344@psf.upfronthosting.co.za> Message-ID: <1205784720.69.0.540706246075.issue2344@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:12:08 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 17 Mar 2008 20:12:08 +0000 Subject: [issue2364] Patch to make 2to3 testing easier In-Reply-To: <1205783439.73.0.272179327902.issue2364@psf.upfronthosting.co.za> Message-ID: <1205784728.89.0.214281780964.issue2364@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks! Committed as r61456 ---------- nosy: +loewis resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:12:14 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:12:14 +0000 Subject: [issue2345] Using an exception variable outside an 'except' clause should raise a Py3K warning In-Reply-To: <1205778549.05.0.340690581025.issue2345@psf.upfronthosting.co.za> Message-ID: <1205784734.88.0.0787754213474.issue2345@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:12:53 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:12:53 +0000 Subject: [issue2346] Py3K warn against using __members__ In-Reply-To: <1205781355.97.0.143101300316.issue2346@psf.upfronthosting.co.za> Message-ID: <1205784773.08.0.665831962751.issue2346@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:13:07 2008 From: report at bugs.python.org (Jeff Balogh) Date: Mon, 17 Mar 2008 20:13:07 +0000 Subject: [issue2359] A Py3K warning for array.array.{read,write} is needed In-Reply-To: <1205782883.21.0.134767238935.issue2359@psf.upfronthosting.co.za> Message-ID: <1205784787.09.0.17640198511.issue2359@psf.upfronthosting.co.za> Jeff Balogh added the comment: I've got this one. ---------- nosy: +jbalogh __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:13:45 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:13:45 +0000 Subject: [issue2347] Py3K warn for using __methods__ In-Reply-To: <1205781395.77.0.22785481066.issue2347@psf.upfronthosting.co.za> Message-ID: <1205784825.71.0.401141681502.issue2347@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:13:58 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:13:58 +0000 Subject: [issue2348] Py3K warn using file.whitespace In-Reply-To: <1205781454.44.0.267838748773.issue2348@psf.upfronthosting.co.za> Message-ID: <1205784838.42.0.859841126547.issue2348@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:14:12 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:14:12 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205784852.65.0.266316187068.issue2349@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:14:26 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:14:26 +0000 Subject: [issue2350] Warn against importing 'exceptions' In-Reply-To: <1205781728.94.0.172904523331.issue2350@psf.upfronthosting.co.za> Message-ID: <1205784866.4.0.79909713179.issue2350@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:14:40 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:14:40 +0000 Subject: [issue2351] Using __(get|set|del)slice__ needs a Py3K warning In-Reply-To: <1205781950.27.0.373262403041.issue2351@psf.upfronthosting.co.za> Message-ID: <1205784880.32.0.695268028962.issue2351@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:14:51 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:14:51 +0000 Subject: [issue2352] Use of __oct__/__hex__ should raise a Py3K warning In-Reply-To: <1205782034.73.0.229035988217.issue2352@psf.upfronthosting.co.za> Message-ID: <1205784891.1.0.832408260429.issue2352@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:15:10 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:15:10 +0000 Subject: [issue2353] Use of file.xreadlines() should raise a Py3K warning In-Reply-To: <1205782140.75.0.577448630615.issue2353@psf.upfronthosting.co.za> Message-ID: <1205784910.44.0.143027057398.issue2353@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:15:19 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:15:19 +0000 Subject: [issue2355] Using buffer() should raise a Py3K warning In-Reply-To: <1205782256.14.0.33369210051.issue2355@psf.upfronthosting.co.za> Message-ID: <1205784919.12.0.92956943158.issue2355@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:15:30 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:15:30 +0000 Subject: [issue2358] Using sys.exc_clear should raise a Py3K warning In-Reply-To: <1205782771.08.0.305016984378.issue2358@psf.upfronthosting.co.za> Message-ID: <1205784930.62.0.678192887151.issue2358@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:15:44 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:15:44 +0000 Subject: [issue2342] Comparing between disparate types should raise a Py3K warning In-Reply-To: <1205777575.3.0.830443648256.issue2342@psf.upfronthosting.co.za> Message-ID: <1205784944.02.0.278087334285.issue2342@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:15:54 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:15:54 +0000 Subject: [issue2360] Fixer for itertools.imap() -> map() In-Reply-To: <1205783160.99.0.976261842944.issue2360@psf.upfronthosting.co.za> Message-ID: <1205784954.92.0.456998487639.issue2360@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:16:05 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:16:05 +0000 Subject: [issue2361] Fixer for itertools.ifilter() -> filter() In-Reply-To: <1205783250.41.0.363081316458.issue2361@psf.upfronthosting.co.za> Message-ID: <1205784965.3.0.0746950788481.issue2361@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:16:06 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 17 Mar 2008 20:16:06 +0000 Subject: [issue2341] Raise a Py3K warning when raise non-BaseException exceptions In-Reply-To: <1205777456.01.0.538815512793.issue2341@psf.upfronthosting.co.za> Message-ID: <1205784966.34.0.752969275633.issue2341@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: See attached. I don't know how to write unit tests for -3 warnings. ---------- keywords: +patch nosy: +belopolsky Added file: http://bugs.python.org/file9699/issue2341.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:16:16 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:16:16 +0000 Subject: [issue2362] Fixer for itertools.izip() -> zip() In-Reply-To: <1205783287.8.0.394861371785.issue2362@psf.upfronthosting.co.za> Message-ID: <1205784976.16.0.35859314223.issue2362@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:16:27 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:16:27 +0000 Subject: [issue2359] A Py3K warning for array.array.{read,write} is needed In-Reply-To: <1205782883.21.0.134767238935.issue2359@psf.upfronthosting.co.za> Message-ID: <1205784987.95.0.336252287198.issue2359@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:16:36 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:16:36 +0000 Subject: [issue2366] Fixer for new metaclass syntax is needed In-Reply-To: <1205783672.52.0.982802083184.issue2366@psf.upfronthosting.co.za> Message-ID: <1205784996.21.0.112730246529.issue2366@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:16:46 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:16:46 +0000 Subject: [issue2365] Fixer for filter(None, ...) -> filter(bool, ...) In-Reply-To: <1205783595.14.0.905564952624.issue2365@psf.upfronthosting.co.za> Message-ID: <1205785006.88.0.648173652875.issue2365@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:16:56 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:16:56 +0000 Subject: [issue2370] operator.{isCallable,sequenceIncludes} needs a fixer In-Reply-To: <1205784272.93.0.866002228926.issue2370@psf.upfronthosting.co.za> Message-ID: <1205785016.83.0.546907569376.issue2370@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:17:12 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:17:12 +0000 Subject: [issue2339] Backport intern() -> sys.intern() In-Reply-To: <1205776549.43.0.234152621457.issue2339@psf.upfronthosting.co.za> Message-ID: <1205785032.49.0.911634213429.issue2339@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:17:24 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:17:24 +0000 Subject: [issue2369] Fixer for new integer literals are needed In-Reply-To: <1205784031.99.0.585423038669.issue2369@psf.upfronthosting.co.za> Message-ID: <1205785044.47.0.243513315624.issue2369@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:17:41 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:17:41 +0000 Subject: [issue2354] cmp argument to list.sort()/sorted() should raise a Py3K warning In-Reply-To: <1205782211.6.0.934088370296.issue2354@psf.upfronthosting.co.za> Message-ID: <1205785061.2.0.992506834409.issue2354@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:17:58 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:17:58 +0000 Subject: [issue2357] sys.exc_{type, values, traceback} should raise a Py3K warning In-Reply-To: <1205782726.96.0.925182629024.issue2357@psf.upfronthosting.co.za> Message-ID: <1205785078.99.0.406053399304.issue2357@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:18:08 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:18:08 +0000 Subject: [issue2356] sys.exitfunc should raise a Py3K warning In-Reply-To: <1205782652.14.0.516090878435.issue2356@psf.upfronthosting.co.za> Message-ID: <1205785088.35.0.406799960226.issue2356@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:18:18 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:18:18 +0000 Subject: [issue2368] Backport __builtin__ to 'builtins' In-Reply-To: <1205783825.31.0.623855463927.issue2368@psf.upfronthosting.co.za> Message-ID: <1205785098.19.0.0502543380333.issue2368@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:18:30 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:18:30 +0000 Subject: [issue2367] Fixer to handle new places where parentheses are needed In-Reply-To: <1205783754.65.0.365050189029.issue2367@psf.upfronthosting.co.za> Message-ID: <1205785110.63.0.299530639521.issue2367@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:18:40 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:18:40 +0000 Subject: [issue2363] Fixer for itertools.ifilterfalse() -> itertools.filterfalse() In-Reply-To: <1205783415.62.0.638293283176.issue2363@psf.upfronthosting.co.za> Message-ID: <1205785120.09.0.836781547604.issue2363@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: immediate -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:22:13 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 20:22:13 +0000 Subject: [issue2368] Backport __builtin__ to 'builtins' In-Reply-To: <1205783825.31.0.623855463927.issue2368@psf.upfronthosting.co.za> Message-ID: <1205785333.34.0.494848407508.issue2368@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Guido, is this something you really want to do? To me, it just makes 2.6 more confusing to learn and it doesn't do much in the way of simplifying the transition to 3.0. The 2-to-3 tool can take care of this trivially. ---------- assignee: -> gvanrossum nosy: +gvanrossum, rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:25:18 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 17 Mar 2008 20:25:18 +0000 Subject: [issue1202] zlib.crc32() and adler32() return value In-Reply-To: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za> Message-ID: <1205785518.07.0.715620084093.issue1202@psf.upfronthosting.co.za> Gregory P. Smith added the comment: fixed. 3.0 always returns unsigned. 2.6 always returns signed, 2**31...2**31-1 come back as negative integers. trunk r61449 branches/py3k r61459 ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:25:58 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 20:25:58 +0000 Subject: [issue2342] Comparing between disparate types should raise a Py3K warning In-Reply-To: <1205777575.3.0.830443648256.issue2342@psf.upfronthosting.co.za> Message-ID: <1205785558.23.0.0875816862102.issue2342@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Can the be done without making comparisons more expensive across the board. It will be bad news for Py2.6 if every single comparison gets slowed down. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:26:49 2008 From: report at bugs.python.org (Jean Brouwers) Date: Mon, 17 Mar 2008 20:26:49 +0000 Subject: [issue2321] return more memory from unicode objects to system In-Reply-To: <1205768902.73.0.245115475399.issue2321@psf.upfronthosting.co.za> Message-ID: <1205785609.33.0.68007884123.issue2321@psf.upfronthosting.co.za> Jean Brouwers added the comment: Just for the record, the enhanced profiler source files in and do replace calls to malloc and free with PyObject_MALLOC resp. _FREE. ---------- nosy: +MrJean1 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:31:12 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 17 Mar 2008 20:31:12 +0000 Subject: [issue2341] Raise a Py3K warning when raise non-BaseException exceptions In-Reply-To: <1205777456.01.0.538815512793.issue2341@psf.upfronthosting.co.za> Message-ID: <1205785871.97.0.398407372931.issue2341@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: While writing the patch, I noticed that "/* Normalize to raise , */" comment was misplaced. Please consider a minor patch that fixes that. Added file: http://bugs.python.org/file9700/issue2341-minor.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:32:26 2008 From: report at bugs.python.org (David Wolever) Date: Mon, 17 Mar 2008 20:32:26 +0000 Subject: [issue2360] Fixer for itertools.imap() -> map() In-Reply-To: <1205783160.99.0.976261842944.issue2360@psf.upfronthosting.co.za> Message-ID: <1205785946.06.0.969778529226.issue2360@psf.upfronthosting.co.za> David Wolever added the comment: I'll take this one (and the next few dealing with itertools) ---------- nosy: +David Wolever __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:35:49 2008 From: report at bugs.python.org (Taek Joo Kim) Date: Mon, 17 Mar 2008 20:35:49 +0000 Subject: [issue2371] Patch for catching exceptions that do not inherit from BaseException In-Reply-To: <1205786149.24.0.883514368484.issue2371@psf.upfronthosting.co.za> Message-ID: <1205786149.24.0.883514368484.issue2371@psf.upfronthosting.co.za> New submission from Taek Joo Kim : With this patch it prints warning message for catching exceptions that don't inherit from BaseException when -3 flag is used. ---------- components: Interpreter Core files: catchexc.patch keywords: patch messages: 63761 nosy: taicki severity: normal status: open title: Patch for catching exceptions that do not inherit from BaseException versions: Python 2.6 Added file: http://bugs.python.org/file9701/catchexc.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:35:54 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 17 Mar 2008 20:35:54 +0000 Subject: [issue2368] Backport __builtin__ to 'builtins' In-Reply-To: <1205783825.31.0.623855463927.issue2368@psf.upfronthosting.co.za> Message-ID: <1205786154.16.0.484295839625.issue2368@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:35:53 2008 From: report at bugs.python.org (Ka-Ping Yee) Date: Mon, 17 Mar 2008 20:35:53 +0000 Subject: [issue2282] TextIOWrapper.seekable() always returns False In-Reply-To: <1205382751.6.0.0963204550732.issue2282@psf.upfronthosting.co.za> Message-ID: <1205786153.42.0.600660603942.issue2282@psf.upfronthosting.co.za> Ka-Ping Yee added the comment: Patch committed. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:36:01 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 20:36:01 +0000 Subject: [issue2323] Make structseq's API look more like a nametuple. In-Reply-To: <1205771667.83.0.681502782029.issue2323@psf.upfronthosting.co.za> Message-ID: <1205786161.14.0.691393234472.issue2323@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Closing as a duplicate of issue 1820. I had been working on this, but there are limits to it. The constructors are completely different so not all of the API can be synced. The __repr__ method is already synced-up. All that is still needed is _asdict(), _fields, and _replace(). The important parts like the __repr__, matching most of the tuple API, and attribute access are already done. ---------- nosy: +rhettinger resolution: -> duplicate status: open -> closed title: Unify structseq and namedtuple's API -> Make structseq's API look more like a nametuple. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:38:02 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 20:38:02 +0000 Subject: [issue2366] Fixer for new metaclass syntax is needed In-Reply-To: <1205783672.52.0.982802083184.issue2366@psf.upfronthosting.co.za> Message-ID: <1205786282.78.0.648777207034.issue2366@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Does the old way still work in 3.0? If so, I don't think we should have a fixer. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:41:02 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 20:41:02 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205786462.49.0.0421099361299.issue2349@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I would like to review the patch on this one. I think it should limit itself to the True and False in builtin. It would be *very* expensive to check for every assignment in every possible namespace. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:41:35 2008 From: report at bugs.python.org (Ilan Schnell) Date: Mon, 17 Mar 2008 20:41:35 +0000 Subject: [issue1274] doctest fails to run file based tests with 8bit paths In-Reply-To: <1192213919.32.0.843568182453.issue1274@psf.upfronthosting.co.za> Message-ID: <1205786495.82.0.165408347502.issue1274@psf.upfronthosting.co.za> Ilan Schnell added the comment: Bug is most likely platform specific. Can someone suggest how this should be handled on multiple platforms? Mike, can you report on which platform you encountered the bug on? Can you provide a script that reproduces the bug? On Mac OS 10.4, Python 2.5 I could not create a file: >>> f=open('\xed', 'w') Traceback (most recent call last): File "", line 1, in IOError: invalid mode: w I will submit this as a separate bug because the error message sould say 'invalid file name' instead of 'invalid mode'. ---------- assignee: -> tim_one nosy: +ilan, tim_one priority: -> low versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:45:09 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 17 Mar 2008 20:45:09 +0000 Subject: [issue2301] [Py3k] No text shown when SyntaxError (when not UTF8) In-Reply-To: <1205674653.18.0.28557522559.issue2301@psf.upfronthosting.co.za> Message-ID: <1205786709.24.0.932937945473.issue2301@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The original issue is now fixed in r61462. Please open another issue for the case of regular exceptions. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:45:31 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 17 Mar 2008 20:45:31 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205786462.49.0.0421099361299.issue2349@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: On Mon, Mar 17, 2008 at 3:41 PM, Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > I would like to review the patch on this one. > > I think it should limit itself to the True and False in builtin. It > would be *very* expensive to check for every assignment in every > possible namespace. > It shouldn't be expensive when the parser does the check (just like with SyntaxError for None). __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:53:29 2008 From: report at bugs.python.org (Douglas Mayle) Date: Mon, 17 Mar 2008 20:53:29 +0000 Subject: [issue2350] Warn against importing 'exceptions' In-Reply-To: <1205781728.94.0.172904523331.issue2350@psf.upfronthosting.co.za> Message-ID: <1205787209.52.0.969676717832.issue2350@psf.upfronthosting.co.za> Douglas Mayle added the comment: I ran python through a debugger and found that the exceptions module is imported automatically at load time. Because of this, when "import exceptions" is parsed, the module is already loaded, and PyImport_Import is not called. In order to correct this, we'll have to either catch this at the AST, or just handle it in 2to3... ---------- nosy: +douglas __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:58:26 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 17 Mar 2008 20:58:26 +0000 Subject: [issue1747858] chown broken on 64bit Message-ID: <1205787506.18.0.563338530533.issue1747858@psf.upfronthosting.co.za> Gregory P. Smith added the comment: i'll take a look at this during the sprint. ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 17 21:58:36 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 17 Mar 2008 20:58:36 +0000 Subject: [issue1747858] chown broken on 64bit Message-ID: <1205787516.2.0.124526668899.issue1747858@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- versions: +Python 2.6, Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 17 21:58:39 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 17 Mar 2008 20:58:39 +0000 Subject: [issue2371] Patch for catching exceptions that do not inherit from BaseException In-Reply-To: <1205786149.24.0.883514368484.issue2371@psf.upfronthosting.co.za> Message-ID: <1205787519.25.0.201497353918.issue2371@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This belongs to issue2291. ---------- nosy: +belopolsky, brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:59:47 2008 From: report at bugs.python.org (Douglas Mayle) Date: Mon, 17 Mar 2008 20:59:47 +0000 Subject: [issue2353] Use of file.xreadlines() should raise a Py3K warning In-Reply-To: <1205782140.75.0.577448630615.issue2353@psf.upfronthosting.co.za> Message-ID: <1205787587.7.0.574437842607.issue2353@psf.upfronthosting.co.za> Douglas Mayle added the comment: I'm on it... ---------- nosy: +douglas __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:01:46 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 17 Mar 2008 21:01:46 +0000 Subject: [issue2290] [PATCH] Update Lib/distutils/sysconfig.py to handle x64 Windows builds living in pcbuild/amd64. In-Reply-To: <1205532747.41.0.216781617297.issue2290@psf.upfronthosting.co.za> Message-ID: <1205787706.05.0.228672424973.issue2290@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This patch is fine, please apply. ---------- assignee: -> Trent.Nelson resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:02:54 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 17 Mar 2008 21:02:54 +0000 Subject: [issue2360] Fixer for itertools.imap() -> map() In-Reply-To: <1205783160.99.0.976261842944.issue2360@psf.upfronthosting.co.za> Message-ID: <1205787774.51.0.159607937339.issue2360@psf.upfronthosting.co.za> Georg Brandl added the comment: See also #2171. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:03:54 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 21:03:54 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205787834.55.0.598006917737.issue2349@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The parser approach should be fine. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 21:29:45 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 17 Mar 2008 20:29:45 +0000 Subject: [issue2307] Decide what to do with bytes/str when transferring pickles between 2.6 and 3.0 In-Reply-To: <1205702162.93.0.846570819567.issue2307@psf.upfronthosting.co.za> Message-ID: <1205785785.66.0.57818194942.issue2307@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : ---------- nosy: +alexandre.vassalotti __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:05:45 2008 From: report at bugs.python.org (Jeff Balogh) Date: Mon, 17 Mar 2008 21:05:45 +0000 Subject: [issue2359] A Py3K warning for array.array.{read,write} is needed In-Reply-To: <1205782883.21.0.134767238935.issue2359@psf.upfronthosting.co.za> Message-ID: <1205787945.66.0.218135201288.issue2359@psf.upfronthosting.co.za> Jeff Balogh added the comment: Attaching a patch that adds the deprecation warnings. It's a bit dirty because there isn't a read or write function anymore, so I had to make stubs that contain the warnings. ---------- keywords: +patch Added file: http://bugs.python.org/file9702/issue2359.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:06:28 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 17 Mar 2008 21:06:28 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205787988.1.0.274717081928.issue2349@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I'm working on it. ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:17:10 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 17 Mar 2008 21:17:10 +0000 Subject: [issue2296] [PATCH] Tcl/Tk 8.4.16 patches needed to get an x64 Windows build In-Reply-To: <1205620533.13.0.0700129427319.issue2296@psf.upfronthosting.co.za> Message-ID: <1205788630.78.0.161142812495.issue2296@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Sounds good, please apply. ---------- assignee: loewis -> Trent.Nelson resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:18:29 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 21:18:29 +0000 Subject: [issue2368] Fixer needed to change __builtin__ -> builtins In-Reply-To: <1205783825.31.0.623855463927.issue2368@psf.upfronthosting.co.za> Message-ID: <1205788709.46.0.823128821334.issue2368@psf.upfronthosting.co.za> Guido van Rossum added the comment: Brett meant to add 'builtins' as an alias for __builtin__. I don't think we should do that. However we should have a fixer for this. Assigning to Collin and changing the subject to match. ---------- assignee: gvanrossum -> collinwinter nosy: +collinwinter title: Backport __builtin__ to 'builtins' -> Fixer needed to change __builtin__ -> builtins __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:23:48 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 17 Mar 2008 21:23:48 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205789028.33.0.442126524778.issue2349@psf.upfronthosting.co.za> Benjamin Peterson added the comment: This patch alters the parser to warn for assignment to True and False. Enjoy! ---------- keywords: +patch Added file: http://bugs.python.org/file9703/bool_assign.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:25:10 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 17 Mar 2008 21:25:10 +0000 Subject: [issue2291] Raise a Py3K warning for catching non-BaseException exceptions In-Reply-To: <1205533155.39.0.576388305845.issue2291@psf.upfronthosting.co.za> Message-ID: <1205789110.24.0.0425109107763.issue2291@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I am commenting on issue2371 patch here, so that I does not get lost in a non-showstopper issue. Taek, please reattach your patch here when you get a chance. With the additional -3 logic, code duplication between tuple and non-tuple case becomes unbearable. I suggest separating both string and subclass checks in a separate function. ---------- nosy: +taicki __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:27:46 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 21:27:46 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205789266.71.0.703478924053.issue2349@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Looks fine. Please apply. ---------- resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:34:40 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 21:34:40 +0000 Subject: [issue2223] regrtest.py -R not working In-Reply-To: <1204561629.27.0.900195264283.issue2223@psf.upfronthosting.co.za> Message-ID: <1205789680.54.0.154828364729.issue2223@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:37:37 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 21:37:37 +0000 Subject: [issue1170766] weakref.proxy incorrect behaviour Message-ID: <1205789857.83.0.233581662026.issue1170766@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 17 22:40:14 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 17 Mar 2008 21:40:14 +0000 Subject: [issue2291] Raise a Py3K warning for catching non-BaseException exceptions In-Reply-To: <1205533155.39.0.576388305845.issue2291@psf.upfronthosting.co.za> Message-ID: <1205790014.9.0.391001400275.issue2291@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: There is also a subtle bug in the issue2371 patch: $ cat x.py try: raise ValueError except ((ValueError,),): pass $ ./python -3 x.py x.py:3: DeprecationWarning: catching classes that do not inherit from BaseException is not allowed in 3.x. except ((ValueError,),): I am not sure if it would be acceptable to move warnings to PyErr_GivenExceptionMatches, but if not, the checking logic should reproduce PyErr_GivenExceptionMatches' recursive behavior. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:44:49 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 21:44:49 +0000 Subject: [issue2339] Backport intern() -> sys.intern() In-Reply-To: <1205776549.43.0.234152621457.issue2339@psf.upfronthosting.co.za> Message-ID: <1205790289.48.0.405905025716.issue2339@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Guido, do you want this alias in Py2.6? Seems like it should just be a 2-to-3 fixer issue only. Also, I vaguely remembered that we weren't going to expose interning at all. There was a discussion on python-dev a couple years ago where I believe that we concluded that this is primarily an internal optimization and that almost no pure python programs benefitted from calling intern() directly. IOW, I thought this was dead as a public API. ---------- assignee: -> gvanrossum nosy: +gvanrossum, rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:48:28 2008 From: report at bugs.python.org (David Stanek) Date: Mon, 17 Mar 2008 21:48:28 +0000 Subject: [issue1686] string.Template.safe_substitute fail when overriding pattern attribute In-Reply-To: <1198301656.07.0.935231571982.issue1686@psf.upfronthosting.co.za> Message-ID: <1205790508.15.0.846067754569.issue1686@psf.upfronthosting.co.za> David Stanek added the comment: I am uploading a new diff that includes the original fix from Hagai along with some tests. ---------- keywords: +patch nosy: +dstanek Added file: http://bugs.python.org/file9704/braced_override.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:49:24 2008 From: report at bugs.python.org (Wolfgang Langner) Date: Mon, 17 Mar 2008 21:49:24 +0000 Subject: [issue2078] CSV Sniffer does not function properly on single column .csv files In-Reply-To: <1202832132.24.0.528453630912.issue2078@psf.upfronthosting.co.za> Message-ID: <1205790564.16.0.0235679253949.issue2078@psf.upfronthosting.co.za> Wolfgang Langner added the comment: The sniffer returns an dialect that is not really correct. Because the delimiter is set to value and in this case there is no delimiter. See it as, it returns a random delimiter if there is not really one. But your usage of the DictReader is wrong. It have to be called with csv.DictReader(file, dialect=dialect) and then it works in this example. This could be closed. ---------- nosy: +tds333 versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:49:54 2008 From: report at bugs.python.org (David Wolever) Date: Mon, 17 Mar 2008 21:49:54 +0000 Subject: [issue2372] Pubkey In-Reply-To: Message-ID: New submission from David Wolever : ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAvyZUU3zNsAoETLN8kDgTmm6qPeWMqUno3KkxcayPSVzT U2pBLlMet/LVtLpHwqARTo4d5/g9vmjwPluQO7LgyIsH88GlJYRgPwV08rpzBTDR+/ 0ZQWt82J7loB1z6mhxMS+YS0Oe2UOEXxYTCKfwwyTXDKVRk8wjlneyI9JZfB8= wolever at wolever.net ---------- messages: 63789 nosy: David Wolever severity: normal status: open title: Pubkey __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:50:28 2008 From: report at bugs.python.org (Noah Kantrowitz) Date: Mon, 17 Mar 2008 21:50:28 +0000 Subject: [issue2321] return more memory from unicode objects to system In-Reply-To: <1205768902.73.0.245115475399.issue2321@psf.upfronthosting.co.za> Message-ID: <1205790628.72.0.771358760554.issue2321@psf.upfronthosting.co.za> Changes by Noah Kantrowitz : ---------- nosy: +coderanger __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:56:08 2008 From: report at bugs.python.org (Ilan Schnell) Date: Mon, 17 Mar 2008 21:56:08 +0000 Subject: [issue1686] string.Template.safe_substitute fail when overriding pattern attribute In-Reply-To: <1198301656.07.0.935231571982.issue1686@psf.upfronthosting.co.za> Message-ID: <1205790968.36.0.023706866958.issue1686@psf.upfronthosting.co.za> Changes by Ilan Schnell : ---------- assignee: -> barry nosy: +barry priority: -> normal type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:57:08 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 17 Mar 2008 21:57:08 +0000 Subject: [issue2372] Pubkey In-Reply-To: Message-ID: <1205791028.53.0.177631075523.issue2372@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The key is installed now. ---------- nosy: +loewis resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 22:59:27 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 21:59:27 +0000 Subject: [issue1686] string.Template.safe_substitute fail when overriding pattern attribute In-Reply-To: <1198301656.07.0.935231571982.issue1686@psf.upfronthosting.co.za> Message-ID: <1205791167.52.0.407111265527.issue1686@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Barry, I'm -0 on this one. ISTM the cure is worst than the disease and makes the code less modifiable, understandable, or maintainable. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 23:10:34 2008 From: report at bugs.python.org (Steven Bethard) Date: Mon, 17 Mar 2008 22:10:34 +0000 Subject: [issue2373] Raise Py3K warnings for comparisons that changed In-Reply-To: <1205791834.41.0.508035363827.issue2373@psf.upfronthosting.co.za> Message-ID: <1205791834.41.0.508035363827.issue2373@psf.upfronthosting.co.za> New submission from Steven Bethard : Some comparisons were changed or removed in Python 3.0. In 2.6 you could compare types (e.g. ``str < int``) and dicts supported more than just equality. These comparisons should produce Py3K warnings. ---------- assignee: bethard components: Interpreter Core keywords: 26backport messages: 63792 nosy: bethard priority: urgent severity: normal status: open title: Raise Py3K warnings for comparisons that changed versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 23:31:13 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 22:31:13 +0000 Subject: [issue2365] Fixer for filter(None, ...) -> filter(bool, ...) In-Reply-To: <1205783595.14.0.905564952624.issue2365@psf.upfronthosting.co.za> Message-ID: <1205793073.21.0.530529283903.issue2365@psf.upfronthosting.co.za> Raymond Hettinger added the comment: There was no change to filter(). It still accepts None. Hence, there is no need for a fixer. ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 23:35:03 2008 From: report at bugs.python.org (Douglas Mayle) Date: Mon, 17 Mar 2008 22:35:03 +0000 Subject: [issue2353] Use of file.xreadlines() should raise a Py3K warning In-Reply-To: <1205782140.75.0.577448630615.issue2353@psf.upfronthosting.co.za> Message-ID: <1205793303.7.0.519449089482.issue2353@psf.upfronthosting.co.za> Douglas Mayle added the comment: Since file() is removed from 3k, this error message tries to be as generic as possible. We should also warn on any use of file() instead of open() Also, all tests have passed except test_normalization ---------- keywords: +patch Added file: http://bugs.python.org/file9705/issue2353.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 23:36:15 2008 From: report at bugs.python.org (Douglas Mayle) Date: Mon, 17 Mar 2008 22:36:15 +0000 Subject: [issue2353] Use of file.xreadlines() should raise a Py3K warning In-Reply-To: <1205782140.75.0.577448630615.issue2353@psf.upfronthosting.co.za> Message-ID: <1205793375.42.0.912881419102.issue2353@psf.upfronthosting.co.za> Douglas Mayle added the comment: I should note that test_normalization fails with or without the patch, so no change __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 23:37:29 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 17 Mar 2008 22:37:29 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205793449.91.0.428777836983.issue2349@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Sorry, I don't permission. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 23:39:51 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Mar 2008 22:39:51 +0000 Subject: [issue1554] socketmodule cleanups: allow the use of keywords in socket functions In-Reply-To: <1196784173.07.0.425557098914.issue1554@psf.upfronthosting.co.za> Message-ID: <1205793591.02.0.288789108169.issue1554@psf.upfronthosting.co.za> Sean Reifschneider added the comment: There's a new version, can we get it reviewed and tested under Windows? ---------- assignee: -> loewis keywords: +patch nosy: +jafo priority: -> normal title: [patch] socketmodule cleanups: allow the use of keywords in socket functions -> socketmodule cleanups: allow the use of keywords in socket functions __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 23:39:42 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 22:39:42 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205793582.49.0.540302000151.issue2349@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'll apply when I get a chance. ---------- assignee: -> rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 23:53:10 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 17 Mar 2008 22:53:10 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205794390.9.0.944692479834.issue2349@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This is a minor concern, but existing -3 warnings refer to python 3.0 and above as "3.x", not 'Py3K'. It would be nice to preserve consistency. ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 23:54:34 2008 From: report at bugs.python.org (David Wolever) Date: Mon, 17 Mar 2008 22:54:34 +0000 Subject: [issue2171] Add map, filter, zip to future_builtins In-Reply-To: <1203812914.42.0.434541981805.issue2171@psf.upfronthosting.co.za> Message-ID: <1205794474.47.0.982815013137.issue2171@psf.upfronthosting.co.za> David Wolever added the comment: To clarify, 2to3 shouldn't wrap map, filter, zip in list() if they are imported from future_builtins. ---------- nosy: +David Wolever __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 23:58:17 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 22:58:17 +0000 Subject: [issue2307] Decide what to do with bytes/str when transferring pickles between 2.6 and 3.0 In-Reply-To: <1205702162.93.0.846570819567.issue2307@psf.upfronthosting.co.za> Message-ID: <1205794697.85.0.224250647156.issue2307@psf.upfronthosting.co.za> Guido van Rossum added the comment: Checked in as r61467. When pickling a bytes instance in a protocol < 3, it is pickled as a user-defined type (essentially faking a __reduce__ operation) which can be read back correctly in 3.0 but probably not in 2.x. ---------- resolution: accepted -> fixed status: open -> closed versions: -Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 17 23:59:08 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 17 Mar 2008 22:59:08 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205794748.53.0.678314439187.issue2349@psf.upfronthosting.co.za> Benjamin Peterson added the comment: "A Foolish Consistency is the Hobgoblin of Little Minds" This update makes the warnings say 3.x. Added file: http://bugs.python.org/file9706/bool_assign2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 00:05:11 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Mar 2008 23:05:11 +0000 Subject: [issue1471] ioctl doesn't work properly on 64-bit OpenBSD In-Reply-To: <1195518427.96.0.197538707678.issue1471@psf.upfronthosting.co.za> Message-ID: <1205795111.66.0.89598286227.issue1471@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I think this proposed change needs some research into what the standards say about ioctl's return code, and if the change to a long return code is done then test it on Linux to see if it breaks things or if it works. Thoughts? ---------- nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 00:17:10 2008 From: report at bugs.python.org (Jeff Balogh) Date: Mon, 17 Mar 2008 23:17:10 +0000 Subject: [issue2358] Using sys.exc_clear should raise a Py3K warning In-Reply-To: <1205782771.08.0.305016984378.issue2358@psf.upfronthosting.co.za> Message-ID: <1205795830.57.0.914878171521.issue2358@psf.upfronthosting.co.za> Jeff Balogh added the comment: Attaching a patch that raises the warning. Should the method documentation metion the deprecation as well? ---------- keywords: +patch nosy: +jbalogh Added file: http://bugs.python.org/file9707/issue2358.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 00:18:36 2008 From: report at bugs.python.org (Ilan Schnell) Date: Mon, 17 Mar 2008 23:18:36 +0000 Subject: [issue2138] Add a factorial function In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za> Message-ID: <1205795916.84.0.966641331319.issue2138@psf.upfronthosting.co.za> Ilan Schnell added the comment: The factorial function is most likely to be used in context with other combinatorial functions (like binomial coefficients) for these functions an external module seems most appropriate. Most likely people would use a factorial function only for some small toy calculation, for those cases one can always roll a factorial function oneself. Python should therefore not be cluttered with this function. I discussed this with several developers at PyCon08, and have therefore decided to close the discussion for now. ---------- components: +Library (Lib) -Interpreter Core nosy: +ilan priority: -> normal resolution: -> rejected status: open -> closed title: Factorial -> Add a factorial function __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 00:23:39 2008 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 17 Mar 2008 23:23:39 +0000 Subject: [issue2339] Backport intern() -> sys.intern() In-Reply-To: <1205776549.43.0.234152621457.issue2339@psf.upfronthosting.co.za> Message-ID: <1205796219.89.0.943204023285.issue2339@psf.upfronthosting.co.za> Guido van Rossum added the comment: I see no great advantage in having it backported, though I also don't see no great harm. Since we still use interning as an internal speed-up, I believe in exposing the API, past discussions notwithstanding. ---------- priority: urgent -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 00:45:47 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Mar 2008 23:45:47 +0000 Subject: [issue2339] Backport intern() -> sys.intern() In-Reply-To: <1205776549.43.0.234152621457.issue2339@psf.upfronthosting.co.za> Message-ID: <1205797547.91.0.887801952117.issue2339@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Okay thanks. Closing this one as something that isn't really needed. ---------- resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 00:48:18 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Mon, 17 Mar 2008 23:48:18 +0000 Subject: [issue1142] code sample showing errors reading large files with py 2.5/3.0 In-Reply-To: <1189439562.54.0.204300359031.issue1142@psf.upfronthosting.co.za> Message-ID: <1205797698.79.0.986350982621.issue1142@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I have run this under the current py3k SVN version on an 64-bit Linux (Fedora 8), and it runs fine, FYI. ISTR that I had a patch which fixed something that sounds very much like this, but I can't find that other issue. ---------- nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:00:22 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 18 Mar 2008 00:00:22 +0000 Subject: [issue2291] Raise a Py3K warning for catching non-BaseException exceptions In-Reply-To: <1205533155.39.0.576388305845.issue2291@psf.upfronthosting.co.za> Message-ID: <1205798422.52.0.370573170304.issue2291@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Correction for msg63584: the old/new style difference example should read """ class x: pass class y(x): pass try: raise y except y: print "b" except: print "a" """ As written it prints 'b', but with __metaclass__ = type, it prints 'a'. In msg63584 I got 'a' and 'b' mixed up. On python-dev, Guido responded that the result should be the same regardless of the metaclass: http://mail.python.org/pipermail/python-dev/2008-March/077713.html __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:04:20 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 00:04:20 +0000 Subject: [issue1312] doctest EXCEPTION_RE can't handle preceding output In-Reply-To: <1193084346.99.0.810572537289.issue1312@psf.upfronthosting.co.za> Message-ID: <1205798659.99.0.247458597895.issue1312@psf.upfronthosting.co.za> Sean Reifschneider added the comment: The existing tests include a test explicitly for the existing behavior, including the statement: "An example may not generate output before it raises an exception". In order to be able to accept this change, there is going to have to be discussion in python-dev or here about changing the behavior. ---------- nosy: +jafo priority: -> normal resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:05:03 2008 From: report at bugs.python.org (Jeff Balogh) Date: Tue, 18 Mar 2008 00:05:03 +0000 Subject: [issue2358] Using sys.exc_clear should raise a Py3K warning In-Reply-To: <1205782771.08.0.305016984378.issue2358@psf.upfronthosting.co.za> Message-ID: <1205798703.77.0.0133582402521.issue2358@psf.upfronthosting.co.za> Jeff Balogh added the comment: Attaching a fixed patch that follows PEP 7 and updates Misc/NEWS. Added file: http://bugs.python.org/file9708/issue2358-stylefix.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:06:12 2008 From: report at bugs.python.org (Jeff Balogh) Date: Tue, 18 Mar 2008 00:06:12 +0000 Subject: [issue2359] A Py3K warning for array.array.{read,write} is needed In-Reply-To: <1205782883.21.0.134767238935.issue2359@psf.upfronthosting.co.za> Message-ID: <1205798772.8.0.211759514553.issue2359@psf.upfronthosting.co.za> Jeff Balogh added the comment: Attaching a fixed patch that follows PEP 7. Added file: http://bugs.python.org/file9709/issue2359-stylefix.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:10:09 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 00:10:09 +0000 Subject: [issue1516] make _ctypes work with non-gcc compilers In-Reply-To: <1196297579.57.0.775741892495.issue1516@psf.upfronthosting.co.za> Message-ID: <1205799009.22.0.593178502339.issue1516@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:12:44 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 00:12:44 +0000 Subject: [issue1506] func alloca inside ctypes lib needs #include on solaris In-Reply-To: <1196198379.38.0.240170599355.issue1506@psf.upfronthosting.co.za> Message-ID: <1205799164.63.0.353700398217.issue1506@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Fix is inline. ---------- keywords: +patch nosy: +jafo __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:13:53 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 00:13:53 +0000 Subject: [issue2374] Use of builtin file should give Py3k warning In-Reply-To: <1205799233.33.0.666545260865.issue2374@psf.upfronthosting.co.za> Message-ID: <1205799233.33.0.666545260865.issue2374@psf.upfronthosting.co.za> New submission from Benjamin Peterson : This patch causes the use of builtin file to give a Py3k warning. When Python starts up, distutils.text_file gives a warning because it uses a variable named file. I imagine there are places like this all over in the stdlib, which should be renamed fp or something similar. ---------- components: Interpreter Core files: file_warning.patch keywords: patch messages: 63814 nosy: benjamin.peterson severity: normal status: open title: Use of builtin file should give Py3k warning type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9710/file_warning.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:24:21 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 00:24:21 +0000 Subject: [issue1574] Touchpad 2 Finger scroll does not work in IDLE on Mac (But scroll wheel of external mouse does) In-Reply-To: <1205799861.09.0.525919108741.issue1574@psf.upfronthosting.co.za> Message-ID: <1205799861.09.0.525919108741.issue1574@psf.upfronthosting.co.za> New submission from Sean Reifschneider : Assigned. ---------- assignee: -> ronaldoussoren nosy: +jafo, ronaldoussoren priority: -> normal type: behavior -> feature request __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:27:22 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 18 Mar 2008 00:27:22 +0000 Subject: [issue2138] Add a factorial function In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za> Message-ID: <1205800042.36.0.488909235458.issue2138@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I don't agree with the reasoning on the rejection. Hundreds of calculator layouts and school textbooks suggest that you can have a useful factorial function without having to also add binomials and whatnot. The OP requested a simple, widely understood integer method with no arguments. That seems very reasonable to me. A function or method is not clutter if it has widespread uses and a near zero learning curve. This is a re-invented function and it would be ashamed to not offer it because it is a pita every time you need it and it's not already there. My guess is that half of long-term Python programmers have written their own variant at some point but only a small percentage of those went on to write a binomial coeffient function. Eventhough this is re-invented often, it is not often re-invented well (i.e. good error messages for non-integer or negative inputs, a fast implementation with pre-computed values for small inputs, and being attached to a namespace where you can find it when needed). To compare, I checked the somewhat clean SmallTalk Integer API and found it had factorial, gcd, and lcm, but not the other functions mentioned in the thread. See: http://www.csci.csusb.edu/dick/samples/smalltalk.methods.html#Integer%20methods Re-opening for further discussion. If someone still feels that it is a bad idea, then go ahead and re-close; otherwise, I think we ought to accept this guy's request. ---------- resolution: rejected -> status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:30:37 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 00:30:37 +0000 Subject: [issue2355] Using buffer() should raise a Py3K warning In-Reply-To: <1205782256.14.0.33369210051.issue2355@psf.upfronthosting.co.za> Message-ID: <1205800237.45.0.947272175182.issue2355@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Here's a patch. ---------- keywords: +patch nosy: +benjamin.peterson Added file: http://bugs.python.org/file9711/buffer_warning.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:31:25 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 00:31:25 +0000 Subject: [issue2138] Add a factorial function In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za> Message-ID: <1205800285.4.0.419594806551.issue2138@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Raymond: Can you come into the core sprint and discuss it with the table on the right just as you come in the door of the sprint room? Lian said that was who he discussed it with and they came to the conclusion to reject it. ---------- nosy: +jafo __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:32:54 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 00:32:54 +0000 Subject: [issue1581] xmlrpclib.ServerProxy() doesn't use x509 data In-Reply-To: <1197315686.07.0.947605571907.issue1581@psf.upfronthosting.co.za> Message-ID: <1205800374.39.0.375488655054.issue1581@psf.upfronthosting.co.za> Sean Reifschneider added the comment: This patch also needs to include a patch to the documentation. Martin: Do you agree with the discussion on the changes for 2.6? ---------- nosy: +jafo __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:34:55 2008 From: report at bugs.python.org (Glyph Lefkowitz) Date: Tue, 18 Mar 2008 00:34:55 +0000 Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za> Message-ID: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za> New submission from Glyph Lefkowitz : Currently if you have both Python 3 and Python 2 installed, there's no way to indicate that ".py" files in one area are Python 2 syntax and in another area are Python 3 syntax. Being able to distinguish between these would be nice for heterogeneous deployment environments, but is particularly important for developers who are working on Python 3 conversions. It would be good to have a PYTHON3PATH which, if present, would be honored instead of PYTHONPATH. PYTHONPATH could still be honored if PYTHON3PATH was not present, so this is purely a new feature and shouldn't have much impact on compatibility. ---------- components: Interpreter Core messages: 63820 nosy: glyph severity: normal status: open title: PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:34:57 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 00:34:57 +0000 Subject: [issue2374] Use of builtin file should give Py3k warning In-Reply-To: <1205799233.33.0.666545260865.issue2374@psf.upfronthosting.co.za> Message-ID: <1205800496.98.0.42440384501.issue2374@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'll review this. My hunch is that we don't need this -- 2to3 takes care of this so there is no reason to tell people to change their code by hand. (You may notice a pattern -- things that 2to3 can fix easily generally don't deserve -3 warnings or backports, *unless* the backported feature adds significant functionality that's not easily available otherwise in 2.x.) ---------- assignee: -> gvanrossum nosy: +gvanrossum priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:36:10 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 18 Mar 2008 00:36:10 +0000 Subject: [issue2138] Add a factorial function In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za> Message-ID: <1205800570.11.0.673380621451.issue2138@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Wish I could be at the sprint. I'm back in Los Angeles. My little post will have to suffice. I thought it was a reasonable request and would hate to see it killed because other people piled on other requests that were not reasonable. I don't buy the reasoning that you have to reject factorial just because someone else might someday want binomial or a gamma. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:36:41 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 00:36:41 +0000 Subject: [issue1596] Broken pipes should be handled better in 2.x In-Reply-To: <1197410546.31.0.23440598734.issue1596@psf.upfronthosting.co.za> Message-ID: <1205800601.26.0.0391002273474.issue1596@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:37:07 2008 From: report at bugs.python.org (Neal Norwitz) Date: Tue, 18 Mar 2008 00:37:07 +0000 Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za> Message-ID: <1205800627.66.0.36524615561.issue2375@psf.upfronthosting.co.za> Changes by Neal Norwitz : ---------- assignee: -> nnorwitz nosy: +nnorwitz priority: -> urgent __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:38:54 2008 From: report at bugs.python.org (paul rubin) Date: Tue, 18 Mar 2008 00:38:54 +0000 Subject: [issue2138] Add a factorial function In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za> Message-ID: <1205800734.44.0.224612870864.issue2138@psf.upfronthosting.co.za> paul rubin added the comment: Rather than factorial how about a product function, so factorial(n) = product(xrange(1,n+1)). I do like the idea of an imath module whether or not it has factorial, and the topic of this rfe has drifted somewhat towards the desirability of such a module, which is a reasonable question for discussion. I'm more or less indifferent to whether imath has factorial in it or not. I do think it would be useful for it to have functions for things like binomial coefficients that were implemented a little more cleverly than with large factorials, but in this case factorial should be there too. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:39:41 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 18 Mar 2008 00:39:41 +0000 Subject: [issue2355] Using buffer() should raise a Py3K warning In-Reply-To: <1205782256.14.0.33369210051.issue2355@psf.upfronthosting.co.za> Message-ID: <1205800781.33.0.506326406553.issue2355@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Are use cases for buffer() satisfied by the new memoryview() builtin? If so, it would be nice to have an automatic conversion or to have the Py3k warning suggest a possible substitute. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:40:41 2008 From: report at bugs.python.org (Eric Smith) Date: Tue, 18 Mar 2008 00:40:41 +0000 Subject: [issue1633807] from __future__ import print_function Message-ID: <1205800841.26.0.128637337568.issue1633807@psf.upfronthosting.co.za> Changes by Eric Smith : ---------- nosy: +eric.smith _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Mar 18 01:41:43 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 00:41:43 +0000 Subject: [issue1598] unexpected response in imaplib In-Reply-To: <1197427257.83.0.419655228027.issue1598@psf.upfronthosting.co.za> Message-ID: <1205800903.24.0.572469000559.issue1598@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Can you provide the message or messages which cause the problem when they are put in the IMAP server? Can you also provide information on what IMAP server software and version is being used? ---------- assignee: -> pierslauder nosy: +jafo, pierslauder priority: -> normal type: crash -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:44:10 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 00:44:10 +0000 Subject: [issue2374] Use of builtin file should give Py3k warning In-Reply-To: <1205799233.33.0.666545260865.issue2374@psf.upfronthosting.co.za> Message-ID: <1205801050.74.0.577315916295.issue2374@psf.upfronthosting.co.za> Guido van Rossum added the comment: Let's not do this. This approach is not sufficiently backwards compatible; it will break any code that uses isinstance(x, file). Even though that's not forward compatible with 3.0, it works in 2.5 and before, so it should not break in 2.6. Together with my previous remark this means that we should just not mess with this. (PS: I don't understand what you say about distutils.text_file -- from your patch it looks like the only way it can issue this warning is if it actually calls the file() builtin...) ---------- resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:44:48 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 18 Mar 2008 00:44:48 +0000 Subject: [issue2348] Py3K warn using file.softspace In-Reply-To: <1205781454.44.0.267838748773.issue2348@psf.upfronthosting.co.za> Message-ID: <1205801088.48.0.637806707846.issue2348@psf.upfronthosting.co.za> Brett Cannon added the comment: That should read file.softspace. ---------- title: Py3K warn using file.whitespace -> Py3K warn using file.softspace __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:47:25 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 18 Mar 2008 00:47:25 +0000 Subject: [issue2138] Add a factorial function In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za> Message-ID: <1205801245.28.0.862440894203.issue2138@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Problems with product(): It is dreadfully inefficient compared to a good implementation of factorial. It has the same name a new itertool with much different functionality. The hyper-generalization takes us further away from the OP's dirt simple request for a piece of functionality that is widely understood, frequently reimplemented, and has a near zero learning curve. If his request is accepted, it does not preclude you from making some other module with tons of functions of interest to encryption people, number theorists, and statisticians. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:48:28 2008 From: report at bugs.python.org (Eric Smith) Date: Tue, 18 Mar 2008 00:48:28 +0000 Subject: [issue1633807] from __future__ import print_function Message-ID: <1205801308.67.0.105656994584.issue1633807@psf.upfronthosting.co.za> Eric Smith added the comment: I'm going to review Anthony's patch and attempt to get it working in the current trunk. I'm going to start by adding some print tests to 3.0, then backport. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Mar 18 01:59:20 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 00:59:20 +0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes In-Reply-To: <1191970098.04.0.2942232647.issue1251@psf.upfronthosting.co.za> Message-ID: <1205801960.92.0.720867250345.issue1251@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Should this be back-ported to 2.6, or can it be closed? ---------- keywords: +patch nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 01:59:57 2008 From: report at bugs.python.org (Taek Joo Kim) Date: Tue, 18 Mar 2008 00:59:57 +0000 Subject: [issue2344] Using an iteration variable outside a list comprehension needs a Py3K warning In-Reply-To: <1205778004.51.0.0647688258878.issue2344@psf.upfronthosting.co.za> Message-ID: <1205801997.95.0.565279219435.issue2344@psf.upfronthosting.co.za> Taek Joo Kim added the comment: >>> i = 3 >>> [i for i in range(10)] >>> i 9 In 2.6, the original value of a variable is changed by the list comprehension. In 3.0, it is not. To fix this, we need many changes on AST. ---------- nosy: +taicki __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 02:00:29 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Tue, 18 Mar 2008 01:00:29 +0000 Subject: [issue2376] Set up "supported"-only buildbot waterfall view In-Reply-To: <1205802028.97.0.321014582059.issue2376@psf.upfronthosting.co.za> Message-ID: <1205802028.97.0.321014582059.issue2376@psf.upfronthosting.co.za> New submission from Jean-Paul Calderone : The Python buildbot's waterfall view currently shows all builders. Not all of these are expected to work currently. This can be confusing to people trying to understand the current state of Python on various platforms. Buildbot can be configured to present limited views, for example only including builders for platforms where all the tests are expected to be passing (and expected to remain passing). The way to place a builder in a particular category is with the "category" keyword in its dict: builders.append({ 'name': 'foo', 'factory': bar 'category': 'unsupported'}) With 0.7.5, adding a "category" query argument will restrict the view to include only builders from the specified category. With 0.7.6, you can construct a custom buildbot.status.web.waterfall.WaterfallStatusResource and pass a list for the categories initializer argument which will restrict the builders it displays. You can make several of these for different categories and put them at various places in the resource hierarchy. ---------- components: None messages: 63832 nosy: exarkun severity: normal status: open title: Set up "supported"-only buildbot waterfall view __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 02:04:51 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 01:04:51 +0000 Subject: [issue2321] return more memory from unicode objects to system In-Reply-To: <1205768902.73.0.245115475399.issue2321@psf.upfronthosting.co.za> Message-ID: <1205802291.36.0.203742194505.issue2321@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks good, Neal. Are you hesitant to check this in? I ran a little test showing that indeed it gives much more memory back to the system. ---------- nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 02:06:59 2008 From: report at bugs.python.org (Steven Bethard) Date: Tue, 18 Mar 2008 01:06:59 +0000 Subject: [issue2342] Comparing between disparate types should raise a Py3K warning In-Reply-To: <1205777575.3.0.830443648256.issue2342@psf.upfronthosting.co.za> Message-ID: <1205802419.71.0.470273838062.issue2342@psf.upfronthosting.co.za> Steven Bethard added the comment: The code is only invoked when NotImplemented is produced. Take a look at the attached patch to try_3way_to_rich_compare and see if you think it's going to be too expensive. ---------- keywords: +patch Added file: http://bugs.python.org/file9712/object_compare.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 02:07:40 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 01:07:40 +0000 Subject: [issue2374] Use of builtin file should give Py3k warning In-Reply-To: <1205799233.33.0.666545260865.issue2374@psf.upfronthosting.co.za> Message-ID: <1205802460.22.0.0550157105847.issue2374@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Yeah, breaking isinstance(x, file) would be bad and 2to3 can do this automatically. I should probably learn how to write fixers. BTW, the warning culprit was actually site.py which used file. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 02:09:15 2008 From: report at bugs.python.org (Mike Taylor) Date: Tue, 18 Mar 2008 01:09:15 +0000 Subject: [issue1274] doctest fails to run file based tests with 8bit paths In-Reply-To: <1205786495.82.0.165408347502.issue1274@psf.upfronthosting.co.za> Message-ID: Mike Taylor added the comment: Hi, it was running on FC4 with UTF-32 support and was using the Japanese locale. The bug is reproducible using any doctest that is stored in a mixed character path. where it is in the Chandler tree is not easily pulled apart but if you really need it I can work up a small subset. On Mon, Mar 17, 2008 at 4:41 PM, Ilan Schnell wrote: > > Ilan Schnell added the comment: > > Bug is most likely platform specific. Can someone suggest how this > should be handled on multiple platforms? > > Mike, can you report on which platform you encountered the bug on? > Can you provide a script that reproduces the bug? > > On Mac OS 10.4, Python 2.5 I could not create a file: > >>> f=open('\xed', 'w') > Traceback (most recent call last): > File "", line 1, in > IOError: invalid mode: w > > I will submit this as a separate bug because the error > message sould say 'invalid file name' instead of 'invalid mode'. > > ---------- > assignee: -> tim_one > nosy: +ilan, tim_one > priority: -> low > versions: +Python 2.6 > > > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 02:10:22 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Tue, 18 Mar 2008 01:10:22 +0000 Subject: [issue2313] correct int / long object type casts In-Reply-To: <1205709502.77.0.893498330113.issue2313@psf.upfronthosting.co.za> Message-ID: <1205802622.87.0.251975810837.issue2313@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Thanks! Fixed in r61472. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 02:10:50 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 18 Mar 2008 01:10:50 +0000 Subject: [issue2355] Using buffer() should raise a Py3K warning In-Reply-To: <1205782256.14.0.33369210051.issue2355@psf.upfronthosting.co.za> Message-ID: <1205802650.09.0.312708886191.issue2355@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Benjamin, Your recent patches all use 4-space indentation, but Python 2.x recommended style is still to use tabs unless you start a new file. See PEP 7. ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 02:13:53 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 01:13:53 +0000 Subject: [issue2355] Using buffer() should raise a Py3K warning In-Reply-To: <1205782256.14.0.33369210051.issue2355@psf.upfronthosting.co.za> Message-ID: <1205802833.21.0.825019459003.issue2355@psf.upfronthosting.co.za> Benjamin Peterson added the comment: My apologies. I often forget to switch between tabs and spaces for Python and C sometimes. Added file: http://bugs.python.org/file9713/buffer_warning_good_tabbing.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 02:46:20 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 18 Mar 2008 01:46:20 +0000 Subject: [issue1477] UnicodeDecodeError that cannot be caught in narrow unicode builds In-Reply-To: <1195593459.02.0.388666867716.issue1477@psf.upfronthosting.co.za> Message-ID: <1205804780.95.0.0616632611588.issue1477@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The error is not uncatchable; but it is generated while compiling, like a SyntaxError. No bytecode is generated for the input, and the "except" opcode is not run at all. OTOH, there is a bug in PyUnicode_DecodeRawUnicodeEscape(): it should accept code points > 0xffff. It has another problem: >>> ur'\U00010000' u'\x00' I join a patch to make raw-unicode-escape similar to unicode-escape: characters outside the Basic Plane are encoded into a utf-16 surrogate pair; on decoding, utf-16 surrogates are decoded into \U00xxxxxx. ---------- keywords: +patch nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file9714/raw-unicode-escape.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 02:46:55 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 18 Mar 2008 01:46:55 +0000 Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za> Message-ID: <1205804815.8.0.960521634609.issue2375@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: -1 Sites that need this functionality can emulate this feature in site.py by adding sys.path[1:1] = os.getenv("PYTHON3PATH", "").split(os.pathsep) in py3k installation. I could not find any discussion beyond the original post at http://mail.python.org/pipermail/python-3000/2008-February/012008.html ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 02:49:23 2008 From: report at bugs.python.org (Gregor Lingl) Date: Tue, 18 Mar 2008 01:49:23 +0000 Subject: [issue1513695] new turtle module Message-ID: <1205804963.06.0.380594923916.issue1513695@psf.upfronthosting.co.za> Changes by Gregor Lingl : Added file: http://bugs.python.org/file9715/whatsnew.txt _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Mar 18 02:52:02 2008 From: report at bugs.python.org (Gregor Lingl) Date: Tue, 18 Mar 2008 01:52:02 +0000 Subject: [issue1513695] new turtle module Message-ID: <1205805122.07.0.402821782124.issue1513695@psf.upfronthosting.co.za> Gregor Lingl added the comment: Supplementary remark: xturtle has proved to run without problems under Python 2.6. (Not surprisingly) it's behaviour is exactly like under Python 2.5, with the exception, that the tested scripts run 5 to 15% faster. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Mar 18 02:52:11 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 01:52:11 +0000 Subject: [issue2371] Patch for catching exceptions that do not inherit from BaseException In-Reply-To: <1205786149.24.0.883514368484.issue2371@psf.upfronthosting.co.za> Message-ID: <1205805131.03.0.686673207742.issue2371@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'll review this once I address issue2291. ---------- assignee: -> gvanrossum nosy: +gvanrossum priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:09:47 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 02:09:47 +0000 Subject: [issue1544] IDLE installation problems and no message errors In-Reply-To: <1196658687.21.0.152111885524.issue1544@psf.upfronthosting.co.za> Message-ID: <1205806187.31.0.196968154673.issue1544@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Duplicate of #1743 and #1862. Fixed in Python 2.5.2 maint. Fixed in rev 60782 The problem is that the .idlerc file is getting the hidden bit set. ---------- assignee: -> loewis nosy: +jafo, loewis priority: -> normal resolution: -> duplicate status: open -> closed type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:16:19 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 02:16:19 +0000 Subject: [issue1711] socket functions that should return unsigned int return signed int In-Reply-To: <1199050245.75.0.972014457431.issue1711@psf.upfronthosting.co.za> Message-ID: <1205806579.71.0.483241110577.issue1711@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Maarten: Do you have time to try doing a test build as suggested by Guido, to report if this issue is resolved? ---------- nosy: +jafo priority: -> normal type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:18:28 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 02:18:28 +0000 Subject: [issue2291] Raise a Py3K warning for catching non-BaseException exceptions In-Reply-To: <1205533155.39.0.576388305845.issue2291@psf.upfronthosting.co.za> Message-ID: <1205806708.01.0.956427270792.issue2291@psf.upfronthosting.co.za> Guido van Rossum added the comment: I finally figured this out. The try/except statement is a complete red herring; the problem is in the raise statement. The behavior is the same in 2.4, 2.5 and 2.6, even though Exception is a classic class in 2.4 and a new-style class in 2.5 and 2.6. The rules are relatively straightforward, and explain all observations, once you realize that attempting to raise something that is not allowed raises a TypeError: - you can raise strings (except in 2.6 -- see footnote) - you can raise any classic class - you can raise any class that derives from [Base]Exception (That last rule is subtle, due to standard exceptions changing from classic to new-style in 2.5.) I do not believe that there is anything wrong in this set of rules, and would object to a change that would allow raising any new-style class in 2.6, since this would be a temporary relaxation of the rules, whereas in 3.0 we will be significantly *tightening* the rules! PEP 352 states that in Python 2.7 we will deprecate raising exceptions that don't derive from BaseException; in 2.8 we will deprecate catching those; and 2.9 we may deprecate __getitem__ on exceptions. This was written before 3.0 was really planned; IMO we should have "-3" warnings for all these things in 2.6. This implies that "except object:" will get a -3 warning -- but not a deprecation warning. I do recommend that these rules be documented more clearly. (Footnote: if I read PEP 352 carefully, I don't believe raising strings was supposed to be disallowed before 3.0. I'm not sure it's worth reverting this though.) ---------- assignee: -> gvanrossum nosy: +gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:19:29 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 02:19:29 +0000 Subject: [issue1684] CGIHTTPServer does not chdir prior to executing the CGI script In-Reply-To: <1198274242.65.0.204698066624.issue1684@psf.upfronthosting.co.za> Message-ID: <1205806769.05.0.67272134714.issue1684@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Is the reporter correct that it is not thread impacting? ---------- assignee: -> tiran nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:19:43 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 02:19:43 +0000 Subject: [issue1684] CGIHTTPServer does not chdir prior to executing the CGI script In-Reply-To: <1198274242.65.0.204698066624.issue1684@psf.upfronthosting.co.za> Message-ID: <1205806783.27.0.0526509621773.issue1684@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- keywords: +patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:22:16 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 02:22:16 +0000 Subject: [issue1711] socket functions that should return unsigned int return signed int In-Reply-To: <1199050245.75.0.972014457431.issue1711@psf.upfronthosting.co.za> Message-ID: <1205806936.26.0.320154922564.issue1711@psf.upfronthosting.co.za> Guido van Rossum added the comment: This is likely fixed; setting the status to pending and priority to low. I believe this will eventually close it. ---------- priority: normal -> low status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:23:14 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 02:23:14 +0000 Subject: [issue1785] "inspect" gets broken by some descriptors In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za> Message-ID: <1205806994.9.0.479768002434.issue1785@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> facundobatista keywords: +patch nosy: +facundobatista priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:27:04 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 02:27:04 +0000 Subject: [issue1676] Fork/exec issues with Tk 8.5/Python 2.5.1 on OS X In-Reply-To: <1198200328.37.0.27301275997.issue1676@psf.upfronthosting.co.za> Message-ID: <1205807224.53.0.727032199523.issue1676@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Martin: Any response to Kevin's URL reference? ---------- assignee: -> loewis nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:34:20 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Tue, 18 Mar 2008 02:34:20 +0000 Subject: [issue2320] Race condition in subprocess using stdin In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za> Message-ID: <1205807660.32.0.980573823281.issue2320@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Ludwig isn't really proposing that subprocess.Popen be thread-safe. That would imply that you could mess with the same Popen instance concurrently from separate threads, which shouldn't be allowed. But instead, he's asking that it not be thread-hostile: that the constructor can be called from multiple threads. Since every call in a threaded app would need to be protected by the same lock, and there's no good place to put that lock, it's a reasonable request. Most existing python types provide this guarantee too: list() can be called concurrently from lots of threads. So I think it's a real bug. ---------- nosy: +jyasskin __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:40:13 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 18 Mar 2008 02:40:13 +0000 Subject: [issue2377] Replace import.c with a pure Python implementation In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> New submission from Brett Cannon : Python/import.c should be replaced by the implementation under development contained in the py3k-importlib branch. ---------- assignee: brett.cannon components: Interpreter Core messages: 63851 nosy: brett.cannon priority: critical severity: normal status: open title: Replace import.c with a pure Python implementation type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:40:39 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 02:40:39 +0000 Subject: [issue1274] doctest fails to run file based tests with 8bit paths In-Reply-To: <1192213919.32.0.843568182453.issue1274@psf.upfronthosting.co.za> Message-ID: <1205808039.16.0.258000802435.issue1274@psf.upfronthosting.co.za> Sean Reifschneider added the comment: This may be fixed already, or a bug in FC4. Or perhaps you could provide more information on how the bug is invoked. I was able to successfully execute a doctest with "\xee" in the path on an F8 box: Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Also: Please do not quote text in the reply. Type "help", "copyright", "credits" or "license" for more information. >>> import doctest >>> doctest.testfile('foo\xeebar/test.txt') (0, 1) >>> guin:pytest$ cat fo*/test.txt The ``example`` module ====================== Using ``print`` ------------------- This is a test example. >>> print 'Hello world!' Hello world! ---------- nosy: +jafo __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:45:26 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 02:45:26 +0000 Subject: [issue1746] ZIP files with archive comments longer than 4k not recognized as valid by zipfile module In-Reply-To: <1199659217.24.0.18704559865.issue1746@psf.upfronthosting.co.za> Message-ID: <1205808326.82.0.108252414981.issue1746@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- priority: -> normal resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:49:53 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 02:49:53 +0000 Subject: [issue1622] zipfile hangs on certain zip files In-Reply-To: <1197595878.01.0.706002731675.issue1622@psf.upfronthosting.co.za> Message-ID: <1205808592.99.0.293079394702.issue1622@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Eric: Can you review the latest version of this patch? ---------- assignee: -> loewis nosy: +jafo, loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:50:11 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 02:50:11 +0000 Subject: [issue2371] Patch for catching exceptions that do not inherit from BaseException In-Reply-To: <1205786149.24.0.883514368484.issue2371@psf.upfronthosting.co.za> Message-ID: <1205808611.12.0.390919366965.issue2371@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks! Applied as r61475. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:55:45 2008 From: report at bugs.python.org (Jerry Seutter) Date: Tue, 18 Mar 2008 02:55:45 +0000 Subject: [issue2378] UnboundLocalError when trying to raise exceptions inside execfile In-Reply-To: <1205808945.1.0.883835206976.issue2378@psf.upfronthosting.co.za> Message-ID: <1205808945.1.0.883835206976.issue2378@psf.upfronthosting.co.za> New submission from Jerry Seutter : Found a bug when trying to integrate figleaf coverage into trunk. I have ripped the code down to the smallest subset that still causes the behaviour. The code works on the latest release of Python 2.5 but is broken on trunk. It comes in two files. The first is the caller (figleaf): import os import sys def foo(f, e, o): pass sys.settrace(foo) import __main__ execfile('test_broken.py', __main__.__dict__) The second file is the test (test_broken.py): # This code breaks on trunk def test_foo(): class CustomException(Exception): pass class SomeClass: def foo(self): raise CustomException # The error only appears with enough nested blocks. if (True == True): try: raise IOError except CustomException: pass It should raise IOError. When run, it gives the following output: jerry-seutters-computer:~/code/python/core_wierd_bug_minimal jseutter$ ../core/python.exe figleaf Traceback (most recent call last): File "figleaf", line 10, in execfile('test_broken.py', __main__.__dict__) File "test_broken.py", line 18, in test_foo() File "test_broken.py", line 15, in test_foo except CustomException: UnboundLocalError: local variable 'CustomException' referenced before assignment [10019 refs] ---------- files: core_wierd_bug_minimal.zip messages: 63856 nosy: jseutter severity: normal status: open title: UnboundLocalError when trying to raise exceptions inside execfile type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9716/core_wierd_bug_minimal.zip __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:56:49 2008 From: report at bugs.python.org (Jerry Seutter) Date: Tue, 18 Mar 2008 02:56:49 +0000 Subject: [issue2378] UnboundLocalError when trying to raise exceptions inside execfile In-Reply-To: <1205808945.1.0.883835206976.issue2378@psf.upfronthosting.co.za> Message-ID: <1205809009.03.0.735436851118.issue2378@psf.upfronthosting.co.za> Changes by Jerry Seutter : ---------- components: +Interpreter Core __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 03:57:13 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 18 Mar 2008 02:57:13 +0000 Subject: [issue2371] Patch for catching exceptions that do not inherit from BaseException In-Reply-To: <1205786149.24.0.883514368484.issue2371@psf.upfronthosting.co.za> Message-ID: <1205809033.65.0.643926664841.issue2371@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I left the following comment in issue2291 pertaining to this patch: """ There is also a subtle bug in the issue2371 patch: $ cat x.py try: raise ValueError except ((ValueError,),): pass $ ./python -3 x.py x.py:3: DeprecationWarning: catching classes that do not inherit from BaseException is not allowed in 3.x. except ((ValueError,),): I am not sure if it would be acceptable to move warnings to PyErr_GivenExceptionMatches, but if not, the checking logic should reproduce PyErr_GivenExceptionMatches' recursive behavior. """ __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:00:19 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 03:00:19 +0000 Subject: [issue2291] Raise a Py3K warning for catching non-BaseException exceptions In-Reply-To: <1205533155.39.0.576388305845.issue2291@psf.upfronthosting.co.za> Message-ID: <1205809219.83.0.74080685201.issue2291@psf.upfronthosting.co.za> Guido van Rossum added the comment: "except object:" will continue to be a no-op, if only for compatibility. With -3 it will issue a warning (I just checked this in, from issue2371). With -3 -Werror it will be an error. We still need patches to issue -3 warnings for: - raising exceptions that don't derive from BaseException - __getitem__ or __getslice__ on exception instances __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:02:20 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 03:02:20 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1205809340.71.0.977365041217.issue2292@psf.upfronthosting.co.za> Guido van Rossum added the comment: This is fun, but needs more work (see python-3000 thread). I'm setting the priority to low, since I won't hold up a release to get this in (if there's even a rough consensus). ---------- assignee: gvanrossum -> twouters priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:03:31 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Tue, 18 Mar 2008 03:03:31 +0000 Subject: [issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za> Message-ID: <1205809411.13.0.262756400788.issue2262@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Another data point: I just installed gcc-4.3.0, and the second patch gives it a 6% speedup. On the downside, 4.3 is still about 9% slower than 4.0. :-( Neal, do you have your measurements? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:03:40 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Tue, 18 Mar 2008 03:03:40 +0000 Subject: [issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za> Message-ID: <1205809420.69.0.860458153124.issue2262@psf.upfronthosting.co.za> Changes by Jeffrey Yasskin : ---------- type: behavior -> performance __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:04:53 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 03:04:53 +0000 Subject: [issue2226] Small _abcoll Bugs / Oddities In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za> Message-ID: <1205809493.37.0.211735218516.issue2226@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm setting this to critical to ensure that I will at least have a thorough look at this before the release. I'm not sure whether I will decide to address it or leave it alone. ---------- priority: -> critical __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:09:09 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 18 Mar 2008 03:09:09 +0000 Subject: [issue2291] Raise a Py3K warning for catching non-BaseException exceptions In-Reply-To: <1205809219.83.0.74080685201.issue2291@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Mon, Mar 17, 2008 at 11:00 PM, Guido van Rossum wrote: .. > - raising exceptions that don't derive from BaseException See patch at issue2341. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:09:23 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 03:09:23 +0000 Subject: [issue2371] Patch for catching exceptions that do not inherit from BaseException In-Reply-To: <1205786149.24.0.883514368484.issue2371@psf.upfronthosting.co.za> Message-ID: <1205809763.6.0.728850301468.issue2371@psf.upfronthosting.co.za> Guido van Rossum added the comment: Alex, can you please open a separate bug for that? The cross-posting of comments is unhelpful, and the issue was not introduced by this patch. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:15:38 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 18 Mar 2008 03:15:38 +0000 Subject: [issue2379] Raise a Py3K warning for __getitem__ or __getslice__ on exception instances In-Reply-To: <1205810138.46.0.535450979934.issue2379@psf.upfronthosting.co.za> Message-ID: <1205810138.46.0.535450979934.issue2379@psf.upfronthosting.co.za> New submission from Alexander Belopolsky : As requested by Guido at msg63858. Will create a patch. ---------- components: Interpreter Core messages: 63864 nosy: belopolsky severity: normal status: open title: Raise a Py3K warning for __getitem__ or __getslice__ on exception instances type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:15:45 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Tue, 18 Mar 2008 03:15:45 +0000 Subject: [issue2198] code_hash() can be the same for different code objects In-Reply-To: <1204148860.69.0.229152092841.issue2198@psf.upfronthosting.co.za> Message-ID: <1205810145.64.0.301913710615.issue2198@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Given Alexander's comment, and the fact that x==x must imply hash(x)==hash(x) but the reverse need not be true, this seems like intentional behavior. ---------- nosy: +jyasskin resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:16:03 2008 From: report at bugs.python.org (David Wolever) Date: Tue, 18 Mar 2008 03:16:03 +0000 Subject: [issue2171] Add map, filter, zip to future_builtins In-Reply-To: <1203812914.42.0.434541981805.issue2171@psf.upfronthosting.co.za> Message-ID: <1205810163.19.0.307093482111.issue2171@psf.upfronthosting.co.za> David Wolever added the comment: The 2to3 stuff relating to map is added in r61479. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:16:11 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 03:16:11 +0000 Subject: [issue2371] Patch for catching exceptions that do not inherit from BaseException In-Reply-To: <1205786149.24.0.883514368484.issue2371@psf.upfronthosting.co.za> Message-ID: <1205810171.71.0.596363674986.issue2371@psf.upfronthosting.co.za> Guido van Rossum added the comment: I've checked a temporary work-around for that issue and another one in r61478. This now has some false negatives; that's better than false positives IMO. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:18:13 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 18 Mar 2008 03:18:13 +0000 Subject: [issue2291] Raise a Py3K warning for catching non-BaseException exceptions In-Reply-To: <1205809219.83.0.74080685201.issue2291@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Mon, Mar 17, 2008 at 11:00 PM, Guido van Rossum wrote: > We still need patches to issue -3 warnings for: > - __getitem__ or __getslice__ on exception instances > I've opened a separate issue for this (see issue2379). I believe this issue can now be closed. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:19:53 2008 From: report at bugs.python.org (David Wolever) Date: Tue, 18 Mar 2008 03:19:53 +0000 Subject: [issue2363] Fixer for itertools.ifilterfalse() -> itertools.filterfalse() In-Reply-To: <1205783415.62.0.638293283176.issue2363@psf.upfronthosting.co.za> Message-ID: <1205810393.75.0.343229736202.issue2363@psf.upfronthosting.co.za> David Wolever added the comment: Fixed in r61466. ---------- nosy: +David Wolever __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:20:24 2008 From: report at bugs.python.org (David Wolever) Date: Tue, 18 Mar 2008 03:20:24 +0000 Subject: [issue2362] Fixer for itertools.izip() -> zip() In-Reply-To: <1205783287.8.0.394861371785.issue2362@psf.upfronthosting.co.za> Message-ID: <1205810424.62.0.124659173419.issue2362@psf.upfronthosting.co.za> David Wolever added the comment: Fixed in r61466. ---------- nosy: +David Wolever __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:20:45 2008 From: report at bugs.python.org (David Wolever) Date: Tue, 18 Mar 2008 03:20:45 +0000 Subject: [issue2361] Fixer for itertools.ifilter() -> filter() In-Reply-To: <1205783250.41.0.363081316458.issue2361@psf.upfronthosting.co.za> Message-ID: <1205810445.01.0.0863388711625.issue2361@psf.upfronthosting.co.za> David Wolever added the comment: Fixed in r61466. ---------- nosy: +David Wolever __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:21:09 2008 From: report at bugs.python.org (David Wolever) Date: Tue, 18 Mar 2008 03:21:09 +0000 Subject: [issue2360] Fixer for itertools.imap() -> map() In-Reply-To: <1205783160.99.0.976261842944.issue2360@psf.upfronthosting.co.za> Message-ID: <1205810469.73.0.324650105121.issue2360@psf.upfronthosting.co.za> David Wolever added the comment: Fixed in r61466. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:27:41 2008 From: report at bugs.python.org (David Wolever) Date: Tue, 18 Mar 2008 03:27:41 +0000 Subject: [issue2360] Fixer for itertools.imap() -> map() In-Reply-To: <1205783160.99.0.976261842944.issue2360@psf.upfronthosting.co.za> Message-ID: <1205810861.53.0.511998441258.issue2360@psf.upfronthosting.co.za> Changes by David Wolever : ---------- nosy: -brett.cannon, collinwinter, georg.brandl status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:28:12 2008 From: report at bugs.python.org (David Wolever) Date: Tue, 18 Mar 2008 03:28:12 +0000 Subject: [issue2361] Fixer for itertools.ifilter() -> filter() In-Reply-To: <1205783250.41.0.363081316458.issue2361@psf.upfronthosting.co.za> Message-ID: <1205810892.74.0.736608974365.issue2361@psf.upfronthosting.co.za> Changes by David Wolever : ---------- nosy: -brett.cannon, collinwinter status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:28:33 2008 From: report at bugs.python.org (David Wolever) Date: Tue, 18 Mar 2008 03:28:33 +0000 Subject: [issue2362] Fixer for itertools.izip() -> zip() In-Reply-To: <1205783287.8.0.394861371785.issue2362@psf.upfronthosting.co.za> Message-ID: <1205810913.77.0.92931469972.issue2362@psf.upfronthosting.co.za> Changes by David Wolever : ---------- nosy: -brett.cannon, collinwinter status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:28:55 2008 From: report at bugs.python.org (David Wolever) Date: Tue, 18 Mar 2008 03:28:55 +0000 Subject: [issue2363] Fixer for itertools.ifilterfalse() -> itertools.filterfalse() In-Reply-To: <1205783415.62.0.638293283176.issue2363@psf.upfronthosting.co.za> Message-ID: <1205810935.15.0.00232690425958.issue2363@psf.upfronthosting.co.za> Changes by David Wolever : ---------- nosy: -brett.cannon, collinwinter status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:42:40 2008 From: report at bugs.python.org (Jeff Balogh) Date: Tue, 18 Mar 2008 03:42:40 +0000 Subject: [issue2348] Py3K warn using file.softspace In-Reply-To: <1205781454.44.0.267838748773.issue2348@psf.upfronthosting.co.za> Message-ID: <1205811760.44.0.432040357663.issue2348@psf.upfronthosting.co.za> Jeff Balogh added the comment: Attaching a patch that adds {get,set}_attr wrappers for fileobject which warn about softspace usage. ---------- keywords: +patch nosy: +jbalogh Added file: http://bugs.python.org/file9717/issue2348.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:43:00 2008 From: report at bugs.python.org (Mike Taylor) Date: Tue, 18 Mar 2008 03:43:00 +0000 Subject: [issue1274] doctest fails to run file based tests with 8bit paths In-Reply-To: <1205808039.16.0.258000802435.issue1274@psf.upfronthosting.co.za> Message-ID: Mike Taylor added the comment: Not in the system PATH but in the path where the file is stored: Here is the original traceback from the bug report for Chandler: Traceback (most recent call last): File "/Development/osaf/chandler_???????/chandler/release/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/doctest.py", line 2107, in runTest test, out=new.write, clear_globs=False) File "/Development/osaf/chandler_???????/chandler/release/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/doctest.py", line 1345, in run return self.__run(test, compileflags, out) File "/Development/osaf/chandler_???????/chandler/release/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/doctest.py", line 1236, in __run got += _exception_traceback(exc_info) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position 70: ordinal not in range(128) On Mon, Mar 17, 2008 at 10:40 PM, Sean Reifschneider wrote: > > Sean Reifschneider added the comment: > > This may be fixed already, or a bug in FC4. Or perhaps you could > provide more information on how the bug is invoked. I was able to > successfully execute a doctest with "\xee" in the path on an F8 box: > > Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) > [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 > > Also: Please do not quote text in the reply. > Type "help", "copyright", "credits" or "license" for more information. > >>> import doctest > >>> doctest.testfile('foo\xeebar/test.txt') > (0, 1) > >>> > guin:pytest$ cat fo*/test.txt > The ``example`` module > ====================== > > Using ``print`` > ------------------- > > This is a test example. > > >>> print 'Hello world!' > Hello world! > > ---------- > nosy: +jafo > > > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:51:03 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 18 Mar 2008 03:51:03 +0000 Subject: [issue2380] Raise a Py3K warning for catching nested tuples with non-BaseException exceptions In-Reply-To: <1205812263.49.0.840453912449.issue2380@psf.upfronthosting.co.za> Message-ID: <1205812263.49.0.840453912449.issue2380@psf.upfronthosting.co.za> New submission from Alexander Belopolsky : As of r61478, the following code fails to produce a py3k warning: try: raise ValueError except ((ValueError,object),): pass which is an error for in py3k: Traceback (most recent call last): File "x.py", line 3, in except ((ValueError,object),): TypeError: catching classes that do not inherit from BaseException is not allowed ---------- components: Interpreter Core messages: 63875 nosy: belopolsky severity: normal status: open title: Raise a Py3K warning for catching nested tuples with non-BaseException exceptions type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 04:51:41 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 18 Mar 2008 03:51:41 +0000 Subject: [issue2371] Patch for catching exceptions that do not inherit from BaseException In-Reply-To: <1205809763.6.0.728850301468.issue2371@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Mon, Mar 17, 2008 at 11:09 PM, Guido van Rossum wrote: > > Alex, can you please open a separate bug for that? The cross-posting of > comments is unhelpful, and the issue was not introduced by this patch. Please see issue2380. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:00:21 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 18 Mar 2008 04:00:21 +0000 Subject: [issue2379] Raise a Py3K warning for __getitem__ or __getslice__ on exception instances In-Reply-To: <1205810138.46.0.535450979934.issue2379@psf.upfronthosting.co.za> Message-ID: <1205812821.39.0.469652633583.issue2379@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: With the attached patch and -3 option: >>> Exception(1,2,3)[0] __main__:1: DeprecationWarning: In 3.x, __getitem__ is not supported for exception classes, use args attribute 1 >>> Exception(1,2,3)[:] __main__:1: DeprecationWarning: In 3.x, __getslice__ is not supported for exception classes, use args attribute (1, 2, 3) ---------- keywords: +patch Added file: http://bugs.python.org/file9718/issue2379.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:02:19 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 04:02:19 +0000 Subject: [issue2303] isinstance is 4x as slow as in 2.5 because the common case raises In-Reply-To: <1205682342.69.0.872031501346.issue2303@psf.upfronthosting.co.za> Message-ID: <1205812939.22.0.680553964028.issue2303@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'll set this to critical to ensure that I look at it at least once before we release. I'm not sure however that we can do much about it -- nor that it matters much in practice. Perhaps we could speed up certain common isinstance() calls by skipping the lookup for non-heap types; I believe those never override __instancheck__. ---------- priority: -> critical __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:03:24 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 04:03:24 +0000 Subject: [issue2291] Raise a Py3K warning for catching non-BaseException exceptions In-Reply-To: <1205533155.39.0.576388305845.issue2291@psf.upfronthosting.co.za> Message-ID: <1205813004.43.0.248914111396.issue2291@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:04:18 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 04:04:18 +0000 Subject: [issue2379] Raise a Py3K warning for __getitem__ or __getslice__ on exception instances In-Reply-To: <1205810138.46.0.535450979934.issue2379@psf.upfronthosting.co.za> Message-ID: <1205813058.58.0.0658907979175.issue2379@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'll review this soon. ---------- assignee: -> gvanrossum nosy: +gvanrossum priority: -> release blocker __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:04:47 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 04:04:47 +0000 Subject: [issue2341] Raise a Py3K warning when raise non-BaseException exceptions In-Reply-To: <1205777456.01.0.538815512793.issue2341@psf.upfronthosting.co.za> Message-ID: <1205813087.48.0.687527770553.issue2341@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'll review this soon. ---------- assignee: -> gvanrossum nosy: +gvanrossum priority: critical -> release blocker __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:19:10 2008 From: report at bugs.python.org (Neal Norwitz) Date: Tue, 18 Mar 2008 04:19:10 +0000 Subject: [issue2321] return more memory from unicode objects to system In-Reply-To: <1205768902.73.0.245115475399.issue2321@psf.upfronthosting.co.za> Message-ID: <1205813950.33.0.474531795349.issue2321@psf.upfronthosting.co.za> Neal Norwitz added the comment: After discussing this with MvL, I'll check this patch into trunk and 2.5. Alec, if you find other issues, please create a new patch. Committed revision 61458. Committed revision 61485. (2.5) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:19:15 2008 From: report at bugs.python.org (Alan Brooks) Date: Tue, 18 Mar 2008 04:19:15 +0000 Subject: [issue2381] test_subprocess fails if your sys.executable is on a path with a space in it In-Reply-To: <1205813955.12.0.0111122307325.issue2381@psf.upfronthosting.co.za> Message-ID: <1205813955.12.0.0111122307325.issue2381@psf.upfronthosting.co.za> New submission from Alan Brooks : Patch attached that escapes the executable name so this test doesn't fail. ---------- components: Tests files: test_subprocess-r61479.patch keywords: patch messages: 63883 nosy: lanny severity: normal status: open title: test_subprocess fails if your sys.executable is on a path with a space in it versions: Python 2.6 Added file: http://bugs.python.org/file9719/test_subprocess-r61479.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:19:49 2008 From: report at bugs.python.org (Neal Norwitz) Date: Tue, 18 Mar 2008 04:19:49 +0000 Subject: [issue2321] return more memory from unicode objects to system In-Reply-To: <1205768902.73.0.245115475399.issue2321@psf.upfronthosting.co.za> Message-ID: <1205813989.39.0.320929833563.issue2321@psf.upfronthosting.co.za> Changes by Neal Norwitz : ---------- assignee: -> nnorwitz resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:21:44 2008 From: report at bugs.python.org (Neal Norwitz) Date: Tue, 18 Mar 2008 04:21:44 +0000 Subject: [issue2321] return more memory from unicode objects to system In-Reply-To: <1205768902.73.0.245115475399.issue2321@psf.upfronthosting.co.za> Message-ID: <1205814104.67.0.578227285376.issue2321@psf.upfronthosting.co.za> Changes by Neal Norwitz : __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:27:06 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 04:27:06 +0000 Subject: [issue2341] Raise a Py3K warning when raise non-BaseException exceptions In-Reply-To: <1205777456.01.0.538815512793.issue2341@psf.upfronthosting.co.za> Message-ID: <1205814426.19.0.62005762364.issue2341@psf.upfronthosting.co.za> Guido van Rossum added the comment: Checked in as r61486. I tweaked your change slightly to compare the output of PyErr_Warn() with -1. The "minor" patch is incorrect IMO; the code where the comment was originally is indeed normalizing the exception in a specific way, while code where you moved it doesn't need a comment (the function name already says what it does :-). ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:29:28 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 04:29:28 +0000 Subject: [issue2380] Raise a Py3K warning for catching nested tuples with non-BaseException exceptions In-Reply-To: <1205812263.49.0.840453912449.issue2380@psf.upfronthosting.co.za> Message-ID: <1205814568.29.0.0386011770459.issue2380@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- keywords: +26backport, easy priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:43:06 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 04:43:06 +0000 Subject: [issue2379] Raise a Py3K warning for __getitem__ or __getslice__ on exception instances In-Reply-To: <1205810138.46.0.535450979934.issue2379@psf.upfronthosting.co.za> Message-ID: <1205815386.77.0.86730802176.issue2379@psf.upfronthosting.co.za> Guido van Rossum added the comment: Cleaned up and committed as r61489. Thanks!! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:47:03 2008 From: report at bugs.python.org (Neal Norwitz) Date: Tue, 18 Mar 2008 04:47:03 +0000 Subject: [issue2332] Renaming of attributes on functions need to be backported. In-Reply-To: <1205775364.33.0.962245412201.issue2332@psf.upfronthosting.co.za> Message-ID: <1205815623.91.0.0198427701036.issue2332@psf.upfronthosting.co.za> Neal Norwitz added the comment: Committed revision 61492. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:53:54 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 04:53:54 +0000 Subject: [issue1911] webbrowser.open firefox 3 issues In-Reply-To: <1201051771.85.0.184797349871.issue1911@psf.upfronthosting.co.za> Message-ID: <1205816034.28.0.989161596949.issue1911@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sorry, I have lots of other things to do before I get to this. It's too late for 2.5.2; 2.5.3 won't be out until September or October 2008. Please ping before then. ---------- components: +Library (Lib) -Extension Modules priority: high -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:55:59 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 04:55:59 +0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module In-Reply-To: <1190163754.35.0.664170861932.issue1179@psf.upfronthosting.co.za> Message-ID: <1205816159.2.0.574113698043.issue1179@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sorry this missed the 2.5.2 release. I'll try to look again before 2.5.3 is imminent. ---------- components: +Extension Modules -Library (Lib) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:57:46 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 04:57:46 +0000 Subject: [issue1775] filehandle.write() does not return None (Python 3.0a2) In-Reply-To: <1199883149.22.0.23332594805.issue1775@psf.upfronthosting.co.za> Message-ID: <1205816266.31.0.638347467077.issue1775@psf.upfronthosting.co.za> Guido van Rossum added the comment: Georg, can you whip up a bit of documentation for this? (Of course you may find that the docs for io.py are lacking more than just this nit...) ---------- assignee: gvanrossum -> georg.brandl components: +Documentation -Library (Lib) priority: normal -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 05:59:04 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 18 Mar 2008 04:59:04 +0000 Subject: [issue2380] Raise a Py3K warning for catching nested tuples with non-BaseException exceptions In-Reply-To: <1205812263.49.0.840453912449.issue2380@psf.upfronthosting.co.za> Message-ID: <1205816344.55.0.0406225610371.issue2380@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- keywords: +patch Added file: http://bugs.python.org/file9720/issue2380.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 06:01:30 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 05:01:30 +0000 Subject: [issue1762972] 'exec' does not accept what 'open' returns Message-ID: <1205816490.12.0.902918545681.issue1762972@psf.upfronthosting.co.za> Guido van Rossum added the comment: Christian, I still see __file__ point to a .pyc file: guido-macbookpro:~/p3 guido$ ./python.exe Python 3.0a3+ (py3k:61464M, Mar 17 2008, 16:36:53) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> string.__file__ '/Users/guido/p3/Lib/string.pyc' >>> Please assign back to me if you've fixed this... ---------- assignee: gvanrossum -> tiran _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Mar 18 06:03:34 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 05:03:34 +0000 Subject: [issue1337696] Elemental Security contribution - pgen2 package Message-ID: <1205816614.55.0.605375063392.issue1337696@psf.upfronthosting.co.za> Guido van Rossum added the comment: This has now been included in the sandbox code for 2to3 and is slated for inclusion in the Python trunk (and the py3k branch). Closing this patch. ---------- resolution: -> accepted status: open -> closed title: Elemental Security contribution - pgen2 package -> Elemental Security contribution - pgen2 package _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Mar 18 06:04:57 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 05:04:57 +0000 Subject: [issue667770] import C API mess Message-ID: <1205816697.06.0.942642391022.issue667770@psf.upfronthosting.co.za> Guido van Rossum added the comment: Brett, perhaps you can consider this with your integration of import-rewritten-in-Python? I think it's fine to leave this alone for 2.6. ---------- assignee: gvanrossum -> brett.cannon components: +Interpreter Core -None nosy: +brett.cannon versions: +Python 3.0 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Mar 18 06:06:31 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 05:06:31 +0000 Subject: [issue1616] compiler warnings In-Reply-To: <1197577517.45.0.829785777717.issue1616@psf.upfronthosting.co.za> Message-ID: <1205816791.49.0.987381580237.issue1616@psf.upfronthosting.co.za> Guido van Rossum added the comment: Let's make this a catch-all bug to remind us to ensure the build is warning-free on as many platforms as possible. ---------- priority: low -> critical title: compiler warnings (gcc 2.96) -> compiler warnings versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 06:07:22 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 05:07:22 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1205816842.34.0.890054300099.issue1717@psf.upfronthosting.co.za> Guido van Rossum added the comment: __cmp__ is not coming back. ---------- priority: low -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 06:22:32 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Tue, 18 Mar 2008 05:22:32 +0000 Subject: [issue2382] [Py3k] SyntaxError cursor shifted if multibyte character is in line. In-Reply-To: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za> Message-ID: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : Hello. I found another problem related to issue2301. SyntaxError cursor "^" is shifted when multibyte characters are in line (before "^"). I think this is because err->text is stored as UTF-8 which requires 3 bytes for multibyte character, but actually cp932 (my console encoding) requires only 2 bytes for it. So "^" is shited to right 5 bytes because there is 5 multibyte chars. C:\Documents and Settings\WhiteRabbit>py3k x.py push any key.... File "x.py", line 3 print "?????" ^ SyntaxError: invalid syntax [22567 refs] Sorry, I didn't know what PyTokenizer_RestoreEncoding really doing. That function adjusted err_ret->offset for this encoding conversion. So, Python2.5 can output cursor in right place. (Of course, if source encoding is not compatible for console encoding, broken string is printed though. Anyway, cursor is right) C:\Documents and Settings\WhiteRabbit>py a.py File "a.py", line 2 x "??????????" ^ SyntaxError: invalid syntax [8728 refs] I tried to fix this problem, but I'm not sure how to fix this. ---------- components: None messages: 63895 nosy: ocean-city severity: normal status: open title: [Py3k] SyntaxError cursor shifted if multibyte character is in line. versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 06:40:11 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 18 Mar 2008 05:40:11 +0000 Subject: [issue667770] import C API mess Message-ID: <1205818811.51.0.565542961669.issue667770@psf.upfronthosting.co.za> Brett Cannon added the comment: I was planning to do that in order to make my life simpler when I have to re-implement the C API. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Mar 18 07:14:55 2008 From: report at bugs.python.org (Nicholas Marriott) Date: Tue, 18 Mar 2008 06:14:55 +0000 Subject: [issue1471] ioctl doesn't work properly on 64-bit OpenBSD In-Reply-To: <1195518427.96.0.197538707678.issue1471@psf.upfronthosting.co.za> Message-ID: <1205820895.51.0.748529901621.issue1471@psf.upfronthosting.co.za> Nicholas Marriott added the comment: It's not the return value, it's the request argument (second argument). I thought SUSv3 had it as an int, but looking again its ioctl seems to be a) optional and b) all about STREAMS, so I don't think it applies: http://www.opengroup.org/onlinepubs/009695399/functions/ioctl.html -- Nicholas __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 07:34:32 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 18 Mar 2008 06:34:32 +0000 Subject: [issue1471] ioctl doesn't work properly on 64-bit OpenBSD In-Reply-To: <1195518427.96.0.197538707678.issue1471@psf.upfronthosting.co.za> Message-ID: <1205822072.75.0.0862870438834.issue1471@psf.upfronthosting.co.za> Gregory P. Smith added the comment: i'd say the patch is fine. on linux ioctl takes an int. on openbsd it takes an unsigned long. on something else it might even take its own type like an ioctl_t. regardless, treating the parameter as either a long or unsigned long will work properly as that will cast downwards to the actual used parameter type correctly in the C code. ---------- assignee: -> gregory.p.smith keywords: +easy, patch nosy: +gregory.p.smith resolution: invalid -> status: pending -> open versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 07:35:51 2008 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 18 Mar 2008 06:35:51 +0000 Subject: [issue1574] Touchpad 2 Finger scroll does not work in IDLE on Mac (But scroll wheel of external mouse does) In-Reply-To: <1205799861.09.0.525919108741.issue1574@psf.upfronthosting.co.za> Message-ID: <1205822151.62.0.597298107808.issue1574@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Unassigned as I'm unlikely to work on this. BTW. My guess guess would be that this is an issue with Tk, not IDLE. ---------- assignee: ronaldoussoren -> __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 07:35:52 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 18 Mar 2008 06:35:52 +0000 Subject: [issue1471] ioctl request argument broken on 64-bit OpenBSD or OS X In-Reply-To: <1195518427.96.0.197538707678.issue1471@psf.upfronthosting.co.za> Message-ID: <1205822152.08.0.718255447776.issue1471@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- keywords: +64bit title: ioctl doesn't work properly on 64-bit OpenBSD -> ioctl request argument broken on 64-bit OpenBSD or OS X __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 07:40:22 2008 From: report at bugs.python.org (Jerry Seutter) Date: Tue, 18 Mar 2008 06:40:22 +0000 Subject: [issue2383] Remove old XXX comment in stat.py In-Reply-To: <1205822422.49.0.9184745501.issue2383@psf.upfronthosting.co.za> Message-ID: <1205822422.49.0.9184745501.issue2383@psf.upfronthosting.co.za> New submission from Jerry Seutter : The comment about constants has been unmodified since 1994 (14 years) and we have yet to support a system that has non-standard constants for stat(). It can safely be removed. This patch contains changes to comments only. ---------- components: Library (Lib) files: stat_remove_stale_comment.patch keywords: patch messages: 63900 nosy: jseutter severity: normal status: open title: Remove old XXX comment in stat.py versions: Python 2.6 Added file: http://bugs.python.org/file9721/stat_remove_stale_comment.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 07:53:07 2008 From: report at bugs.python.org (Steven Bethard) Date: Tue, 18 Mar 2008 06:53:07 +0000 Subject: [issue2373] Raise Py3K warnings for comparisons that changed In-Reply-To: <1205791834.41.0.508035363827.issue2373@psf.upfronthosting.co.za> Message-ID: <1205823187.65.0.62140243624.issue2373@psf.upfronthosting.co.za> Steven Bethard added the comment: I'm attaching a patch that handles object comparisons, type comparisons, cell comparisons, and dict comparisons. All the tests pass (including the new ones I've added) but I'd appreciate it if someone could take a second look. Other things still remaining to be done: * Someone needs to decide the correct behavior for method-wrappers (descrobject.c), implement that in Python 2.6 and forward port it to 3.0. * The following objects have a good tp_richcompare in Python 3.0: codeobject.c, methodobject.c, sliceobject.c. Those tp_richcompares should be backported to 2.6. Then a warning can be added for LE, LT, GE and GT (with no warning for EQ or NE which won't change). I may have a little time tomorrow to work on the latter task. ---------- keywords: +patch Added file: http://bugs.python.org/file9722/changed_comparisons.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 07:55:45 2008 From: report at bugs.python.org (Trent Nelson) Date: Tue, 18 Mar 2008 06:55:45 +0000 Subject: [issue2297] Patch for fatal stack overflow in Windows caused by -v In-Reply-To: <1205645085.91.0.398085675156.issue2297@psf.upfronthosting.co.za> Message-ID: <1205823345.03.0.0957307479167.issue2297@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- assignee: -> Trent.Nelson priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 08:10:52 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 18 Mar 2008 07:10:52 +0000 Subject: [issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za> Message-ID: <1205824252.06.0.994804723483.issue2262@psf.upfronthosting.co.za> Gregory P. Smith added the comment: We really could use an automated pybench runner on a dedicated machine driven by a buildbot feeding its results into a database so that we had a record of exactly when/what caused performance changes over time. This sounds remarkably like some of the work I was doing at my last job... ;) I'll run some benchmarks using this patch of my own and on the grander scale ponder what I need to make a dedicated automated Python benchmark server happen. ---------- nosy: +gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 08:15:58 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Tue, 18 Mar 2008 07:15:58 +0000 Subject: [issue2382] [Py3k] SyntaxError cursor shifted if multibyte character is in line. In-Reply-To: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za> Message-ID: <1205824558.9.0.758785186516.issue2382@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: > I tried to fix this problem, but I'm not sure how to fix this. Quick observation... /////////////////////////////////// // Possible Solution 1. Convert err->text to console compatible encoding (not to source encoding like in python2.x) where PyTokenizer_RestoreEncoding is there. 2. err->text is UTF-8, actual output is done in Python/pythonrun.c(print_error_text), so adjust offset there. /////////////////////////////////// // Solution requires... 1. - PyUnicode_DecodeUTF8 in Python/pythonrun.c(err_input) should be changed to some kind of "bytes" API. - The way to write "bytes" to File object directly is needed. 2. - The way to know actual byte length of given unicode + encoding. //////////////////////////////////////////////////// // Experimental patch Attached as experimental patch of solution 2. Looks agly, but seems working on my environment. (I assumed get_length_in_bytes(f, " ", 1) == 1 but I'm not sure this is always true in other platforms. Probably nicer and more general solution may exist) ---------- keywords: +patch Added file: http://bugs.python.org/file9723/experimental.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 08:28:39 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Tue, 18 Mar 2008 07:28:39 +0000 Subject: [issue2384] [Py3k] line number is wrong after encoding declaration In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za> Message-ID: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : # This issue inherits from issue2301. If there is "# coding: ????" is in source code and coding is neigher utf-8 nor iso-8859-1, line number (tok->lineno) becomes wrong. Please look into Parser/tokenizer.c. In this case, tok->decoding_state becomes STATE_NORMAL, so fp_setreadl newly opens file but *doesn't* seek to current position. (Or maybe can we reuse already opened file?) So # coding: ascii # 1 # 2 # 3 raise RuntimeError("a") # 4 # 5 # 6 outputs C:\Documents and Settings\WhiteRabbit>py3k ascii.py Traceback (most recent call last): File "ascii.py", line 6, in # 4 RuntimeError: a [22821 refs] One line shifted because line number wrongly +1 And # dummy # coding: ascii # 1 # 2 # 3 raise RuntimeError("a") # 4 # 5 # 6 outputs C:\Documents and Settings\WhiteRabbit>py3k ascii.py Traceback (most recent call last): File "ascii.py", line 8, in # 5 RuntimeError: a [22821 refs] Two lines shifted because line number wrongly +2 ---------- components: None messages: 63905 nosy: ocean-city severity: normal status: open title: [Py3k] line number is wrong after encoding declaration versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 11:24:34 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Tue, 18 Mar 2008 10:24:34 +0000 Subject: [issue2385] run_setup can fail if the setup script uses __file__ In-Reply-To: <1205835874.17.0.090976046813.issue2385@psf.upfronthosting.co.za> Message-ID: <1205835874.17.0.090976046813.issue2385@psf.upfronthosting.co.za> New submission from Tarek Ziad? : When calling run_setup, the execfile does not set the __file__ global variable, that is often used in setup.py modules (for instance to load a text file from the package to be used in the long_description) This patch adds this global variable so it does not fail. No test provided (distutils would need a test_core.py). I could work on some tests, but the previous test_* files I have added are not in yet, so i'd rather wait for that before proposing new tests modules. ---------- components: Distutils files: distutils.core.patch keywords: patch messages: 63906 nosy: tarek severity: normal status: open title: run_setup can fail if the setup script uses __file__ type: crash versions: Python 2.6 Added file: http://bugs.python.org/file9724/distutils.core.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 11:37:20 2008 From: report at bugs.python.org (Tim Golden) Date: Tue, 18 Mar 2008 10:37:20 +0000 Subject: =?utf-8?q?[issue2304]_subprocess_under_windows_fails_to_quote_properly_when=09shell=3DTrue?= In-Reply-To: <1205685138.96.0.183811169845.issue2304@psf.upfronthosting.co.za> Message-ID: <1205836640.05.0.20885826326.issue2304@psf.upfronthosting.co.za> Tim Golden added the comment: Updated patch against r61514. Test code now PEP8-compliant (I hope). New tests cover spaces in command and parameter with and without shell=True, both as simple command string and as list of command/args. Added file: http://bugs.python.org/file9725/subprocess-r61514.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 13:28:04 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 18 Mar 2008 12:28:04 +0000 Subject: [issue2386] os.strerror missing/HAVE_STRERROR not defined In-Reply-To: <1205843284.03.0.546398560804.issue2386@psf.upfronthosting.co.za> Message-ID: <1205843284.03.0.546398560804.issue2386@psf.upfronthosting.co.za> New submission from Ralf Schmitt : os.strerror is missing on my 64 bit linux. HAVE_STRERROR is not defined in pyconfig.h. This has been broken in r61483. ---------- messages: 63908 nosy: brett.cannon, schmir severity: normal status: open title: os.strerror missing/HAVE_STRERROR not defined type: compile error versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 13:33:02 2008 From: report at bugs.python.org (Virgil Dupras) Date: Tue, 18 Mar 2008 12:33:02 +0000 Subject: [issue2162] unittest.findTestCases undocumented In-Reply-To: <1203690921.5.0.9443371245.issue2162@psf.upfronthosting.co.za> Message-ID: <1205843582.26.0.0611094576924.issue2162@psf.upfronthosting.co.za> Virgil Dupras added the comment: Can't we close this ticket? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 13:35:11 2008 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 18 Mar 2008 12:35:11 +0000 Subject: [issue2078] CSV Sniffer does not function properly on single column .csv files In-Reply-To: <1202832132.24.0.528453630912.issue2078@psf.upfronthosting.co.za> Message-ID: <1205843711.65.0.0591716020357.issue2078@psf.upfronthosting.co.za> Skip Montanaro added the comment: What do you think the delimiter should be for this csv file? 43.4e12 147483648 47483648 What about this one? abcdef bcdefg cdefgh And this? abc8def bcd8efg cde8fgh If I force the sniffer to not allow digits or letters as delimiters I can get the sniffer to return comma as the delimiter in all three cases. I'm not certain that's correct in the third case though. ---------- assignee: -> skip.montanaro nosy: +skip.montanaro __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 14:28:00 2008 From: report at bugs.python.org (Virgil Dupras) Date: Tue, 18 Mar 2008 13:28:00 +0000 Subject: [issue2387] cStringIO and unicode In-Reply-To: <1205846879.92.0.0083654313835.issue2387@psf.upfronthosting.co.za> Message-ID: <1205846879.92.0.0083654313835.issue2387@psf.upfronthosting.co.za> New submission from Virgil Dupras : hsoft-dev:python hsoft$ python Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from cStringIO import StringIO >>> StringIO(u'foo').read() 'foo' >>> hsoft-dev:python hsoft$ ./python.exe Python 2.6a1+ (trunk:61515, Mar 18 2008, 13:38:47) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from cStringIO import StringIO >>> StringIO(u'foo').read() 'f\x00o\x00o\x00' >>> The documentation says: Unlike the memory files implemented by the StringIO module, those provided by this module are not able to accept Unicode strings that cannot be encoded as plain ASCII strings. Attached a patch to test_StringIO. ---------- components: Library (Lib) files: cStringIO_unicode_test.diff keywords: patch messages: 63911 nosy: vdupras severity: normal status: open title: cStringIO and unicode type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9726/cStringIO_unicode_test.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 14:32:02 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 13:32:02 +0000 Subject: [issue2320] Race condition in subprocess using stdin In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za> Message-ID: <1205847122.54.0.722129283185.issue2320@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks for clarifying, Jeffrey! I agree the Popen should be reentrant, since it's likey to be used that way. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 15:00:12 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 14:00:12 +0000 Subject: [issue2388] Compiler warnings when using UCS4 In-Reply-To: <1205848812.38.0.436275134314.issue2388@psf.upfronthosting.co.za> Message-ID: <1205848812.38.0.436275134314.issue2388@psf.upfronthosting.co.za> New submission from Benjamin Peterson : Compiling Python with --enable-unicode=ucs4 yields some compiler warnings for unicodeobject.c: In file included from Objects/unicodeobject.c:7807: Objects/stringlib/string_format.h: In function 'do_conversion': Objects/stringlib/string_format.h:745: warning: format '%c' expects type 'int', but argument 3 has type 'Py_UNICODE' In file included from Objects/unicodeobject.c:7807: Objects/stringlib/string_format.h: In function 'do_conversion': Objects/stringlib/string_format.h:745: warning: format '%c' expects type 'int', but argument 3 has type 'Py_UNICODE' Objects/unicodeobject.c: In function 'PyUnicodeUCS4_Format': Objects/unicodeobject.c:8603: warning: format '%c' expects type 'int', but argument 3 has type 'Py_UNICODE' Objects/unicodeobject.c: In function 'PyUnicodeUCS4_Format': Objects/unicodeobject.c:8603: warning: format '%c' expects type 'int', but argument 3 has type 'Py_UNICODE' ---------- components: Unicode messages: 63913 nosy: benjamin.peterson severity: normal status: open title: Compiler warnings when using UCS4 type: compile error versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 15:27:14 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 18 Mar 2008 14:27:14 +0000 Subject: [issue2388] Compiler warnings when using UCS4 In-Reply-To: <1205848812.38.0.436275134314.issue2388@psf.upfronthosting.co.za> Message-ID: <1205850434.58.0.837974869238.issue2388@psf.upfronthosting.co.za> Martin v. L?wis added the comment: What operating system/compiler? Both branches? What precise revisions? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 15:38:12 2008 From: report at bugs.python.org (=?utf-8?q?Hrvoje_Nik=C5=A1i=C4=87?=) Date: Tue, 18 Mar 2008 14:38:12 +0000 Subject: [issue2389] Array pickling exposes internal memory representation of elements In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za> Message-ID: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za> New submission from Hrvoje Nik?i? : It would seem that pickling arrays directly exposes the underlying machine words, making the pickle non-portable to platforms with different layout of array elements. The guts of array.__reduce__ look like this: if (array->ob_size > 0) { result = Py_BuildValue("O(cs#)O", array->ob_type, array->ob_descr->typecode, array->ob_item, array->ob_size * array->ob_descr->itemsize, dict); } The byte string that is pickled is directly created from the array's contents. Unpickling calls array_new which in turn calls array_fromstring, which ends up memcpying the string data to the new array. As far as I can tell, array pickles created on one platform cannot be unpickled on a platform with different endianness (in case of integer arrays), wchar_t size (in case of unicode arrays) or floating-point representation (rare in practice, but possible). If pickles are supposed to be platform-independent, this should be fixed. Maybe the "typecode" field when used with the constructor could be augmented to include information about the elements, such as endianness and floating-point format. Or we should simply punt and pickle the array as a list of Python objects that comprise it...? ---------- components: Extension Modules messages: 63915 nosy: hniksic severity: normal status: open title: Array pickling exposes internal memory representation of elements type: behavior versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 15:39:07 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 14:39:07 +0000 Subject: [issue2388] Compiler warnings when using UCS4 In-Reply-To: <1205848812.38.0.436275134314.issue2388@psf.upfronthosting.co.za> Message-ID: <1205851147.12.0.764640666718.issue2388@psf.upfronthosting.co.za> Benjamin Peterson added the comment: This is MacOS 10.4, Apple gcc 4.0.1, and revision 61518. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 15:41:33 2008 From: report at bugs.python.org (Virgil Dupras) Date: Tue, 18 Mar 2008 14:41:33 +0000 Subject: [issue984219] hotspot.stats.load is very slow Message-ID: <1205851293.47.0.212450428582.issue984219@psf.upfronthosting.co.za> Virgil Dupras added the comment: I had a 54 mb hotshot profile lying around, and it is indeed very long to load, so I ran a profiling session of hotshot.stats.load(MY_BIG_FILE) with python and stdlib of r61515, and here are the results (the resulting prof file is 27 mb): 96541166 function calls in 299.936 CPU seconds Ordered by: cumulative time List reduced from 30 to 15 due to restriction <15> ncalls tottime percall cumtime percall filename:lineno(function) 1 0.000 0.000 299.936 299.936 stats.py:11(load) 1 95.089 95.089 299.936 299.936 stats.py:22(load) 27583167 51.183 0.000 61.815 0.000 log.py:95(next) 13791583 59.314 0.000 59.314 0.000 profile.py:328(trace_dispatch_return) 13791583 35.014 0.000 42.910 0.000 stats.py:54(new_frame) 13791584 40.807 0.000 40.807 0.000 profile.py:295(trace_dispatch_call) 13791583 10.632 0.000 10.632 0.000 log.py:138(_decode_location) 13791583 7.897 0.000 7.897 0.000 stats.py:87(__init__) 1 0.000 0.000 0.000 0.000 pstats.py:73(__init__) 1 0.000 0.000 0.000 0.000 pstats.py:95(init) 1 0.000 0.000 0.000 0.000 pstats.py:138(get_top_level_stats) 1 0.000 0.000 0.000 0.000 log.py:24(__init__) 1 0.000 0.000 0.000 0.000 pstats.py:117(load_stats) 1 0.000 0.000 0.000 0.000 profile.py:436(create_stats) 1 0.000 0.000 0.000 0.000 profile.py:440(snapshot_stats) 96541166 function calls in 299.936 CPU seconds Ordered by: internal time List reduced from 30 to 20 due to restriction <20> ncalls tottime percall cumtime percall filename:lineno(function) 1 95.089 95.089 299.936 299.936 stats.py:22(load) 13791583 59.314 0.000 59.314 0.000 profile.py:328(trace_dispatch_return) 27583167 51.183 0.000 61.815 0.000 log.py:95(next) 13791584 40.807 0.000 40.807 0.000 profile.py:295(trace_dispatch_call) 13791583 35.014 0.000 42.910 0.000 stats.py:54(new_frame) 13791583 10.632 0.000 10.632 0.000 log.py:138(_decode_location) 13791583 7.897 0.000 7.897 0.000 stats.py:87(__init__) 1 0.000 0.000 0.000 0.000 log.py:24(__init__) 1 0.000 0.000 0.000 0.000 profile.py:440(snapshot_stats) 1 0.000 0.000 0.000 0.000 pstats.py:138(get_top_level_stats) 30 0.000 0.000 0.000 0.000 pstats.py:484(func_std_string) 5 0.000 0.000 0.000 0.000 posixpath.py:306(normpath) 1 0.000 0.000 299.936 299.936 stats.py:11(load) 24 0.000 0.000 0.000 0.000 stats.py:80(__init__) 1 0.000 0.000 0.000 0.000 pstats.py:117(load_stats) 1 0.000 0.000 0.000 0.000 profile.py:402(simulate_call) 1 0.000 0.000 0.000 0.000 profile.py:118(_get_time_resource) 1 0.000 0.000 0.000 0.000 pstats.py:73(__init__) 1 0.000 0.000 0.000 0.000 pstats.py:95(init) 1 0.000 0.000 0.000 0.000 profile.py:166(__init__) So the bulk of the time seems to be taken by the sheer number of trace_dispatch_return and trace_dispatch_call calls. I took a quick look, but I'm not sure I can do anything to make it faster. If no one else has any idea, I suggest just closing the ticket. ---------- nosy: +vdupras ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Mar 18 15:48:52 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 14:48:52 +0000 Subject: [issue2388] Compiler warnings when using UCS4 In-Reply-To: <1205848812.38.0.436275134314.issue2388@psf.upfronthosting.co.za> Message-ID: <1205851732.4.0.198950240717.issue2388@psf.upfronthosting.co.za> Benjamin Peterson added the comment: There are similar warnings in formater_unicode.c: In file included from Python/formatter_unicode.c:13: Python/../Objects/stringlib/formatter.h: In function 'unicode__format__': Python/../Objects/stringlib/formatter.h:789: warning: format '%c' expects type 'int', but argument 3 has type 'Py_UNICODE' In file included from Python/formatter_unicode.c:13: Python/../Objects/stringlib/formatter.h: In function 'unicode__format__': Python/../Objects/stringlib/formatter.h:789: warning: format '%c' expects type 'int', but argument 3 has type 'Py_UNICODE' __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 16:04:33 2008 From: report at bugs.python.org (Thomas Heller) Date: Tue, 18 Mar 2008 15:04:33 +0000 Subject: [issue1506] func alloca inside ctypes lib needs #include on solaris In-Reply-To: <1196198379.38.0.240170599355.issue1506@psf.upfronthosting.co.za> Message-ID: <1205852673.63.0.424083505899.issue1506@psf.upfronthosting.co.za> Thomas Heller added the comment: I applied the patch to SVN trunk as rev 61520. It would probably be better to have a configure test for alloca.h. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 16:14:31 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 15:14:31 +0000 Subject: [issue1399] XML codec In-Reply-To: <1194457938.94.0.302802489446.issue1399@psf.upfronthosting.co.za> Message-ID: <1205853271.66.0.873370742246.issue1399@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 16:36:47 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 18 Mar 2008 15:36:47 +0000 Subject: [issue2386] os.strerror missing/HAVE_STRERROR not defined In-Reply-To: <1205843284.03.0.546398560804.issue2386@psf.upfronthosting.co.za> Message-ID: <1205854607.79.0.0684626767659.issue2386@psf.upfronthosting.co.za> Brett Cannon added the comment: Fixed in revision 61523. Thanks for reminding me to remove those references, Ralf. ---------- assignee: -> brett.cannon resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 16:38:27 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 15:38:27 +0000 Subject: [issue2390] Merge 2.6 ACKS with 3.0 ACKS In-Reply-To: <1205854707.75.0.657591820184.issue2390@psf.upfronthosting.co.za> Message-ID: <1205854707.75.0.657591820184.issue2390@psf.upfronthosting.co.za> New submission from Guido van Rossum : Due to blocked merges etc. I expect that some names appearing in the 2.6 ACKS file aren't in the 3.0 ACKS file. And possible the other way around where backports are involved. I like this file to be as inclusive as possible (hey, my dad is in it :-) so perhaps the best approach is to just make them both the union of what they currently are. ---------- keywords: easy messages: 63921 nosy: gvanrossum severity: normal status: open title: Merge 2.6 ACKS with 3.0 ACKS __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 16:52:00 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 15:52:00 +0000 Subject: [issue2392] Sean is testing tracker bug. In-Reply-To: <1205855520.08.0.383762884514.issue2392@psf.upfronthosting.co.za> Message-ID: <1205855520.08.0.383762884514.issue2392@psf.upfronthosting.co.za> New submission from Sean Reifschneider : Foo ---------- components: Demos and Tools messages: 63922 nosy: jafo severity: normal status: open title: Sean is testing tracker bug. versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 16:54:58 2008 From: report at bugs.python.org (Travis Oliphant) Date: Tue, 18 Mar 2008 15:54:58 +0000 Subject: [issue2393] Backport buffer interface in Python 3.0 to Python 2.6 In-Reply-To: <1205855698.81.0.786586368885.issue2393@psf.upfronthosting.co.za> Message-ID: <1205855698.81.0.786586368885.issue2393@psf.upfronthosting.co.za> New submission from Travis Oliphant : Some (or all) of PEP 3118 should be backported to Python 2.6 because it does not require backward-incompatible changes and can assist in the transition to 3.0. This issue is to be sure that the buffer-interface portion of PEP 3118 is backported. This does not mean that any objects in Python will necessarily use the new buffer interface. Any such changes would be entered as separate issues. ---------- components: Interpreter Core messages: 63923 nosy: teoliphant severity: normal status: open title: Backport buffer interface in Python 3.0 to Python 2.6 type: feature request versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 16:56:30 2008 From: report at bugs.python.org (Scott Moser) Date: Tue, 18 Mar 2008 15:56:30 +0000 Subject: [issue1598] unexpected response in imaplib In-Reply-To: <1197427257.83.0.419655228027.issue1598@psf.upfronthosting.co.za> Message-ID: <1205855790.73.0.32251822017.issue1598@psf.upfronthosting.co.za> Scott Moser added the comment: I can recreate this at the moment with the attached mail. I downloaded the mail using alpine's "Export". I don't know what other way I would have to get it. I have replaced many company names with XYZ and such, simply to anonymize the message somewhat. Added file: http://bugs.python.org/file9727/failed-mail.txt __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 16:57:35 2008 From: report at bugs.python.org (Scott Moser) Date: Tue, 18 Mar 2008 15:57:35 +0000 Subject: [issue1598] unexpected response in imaplib In-Reply-To: <1197427257.83.0.419655228027.issue1598@psf.upfronthosting.co.za> Message-ID: <1205855855.55.0.927393796935.issue1598@psf.upfronthosting.co.za> Scott Moser added the comment: This is the stderr from the test case above. Only modification is the mailbox is 'my-test'. Added file: http://bugs.python.org/file9728/failed-errorlog.txt __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 16:58:08 2008 From: report at bugs.python.org (Travis Oliphant) Date: Tue, 18 Mar 2008 15:58:08 +0000 Subject: [issue2393] Backport buffer interface in Python 3.0 to Python 2.6 In-Reply-To: <1205855698.81.0.786586368885.issue2393@psf.upfronthosting.co.za> Message-ID: <1205855888.75.0.267894757927.issue2393@psf.upfronthosting.co.za> Travis Oliphant added the comment: Back-porting of the new buffer interface was done in r61491. This issue can be closed. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 16:59:45 2008 From: report at bugs.python.org (Scott Moser) Date: Tue, 18 Mar 2008 15:59:45 +0000 Subject: [issue1598] unexpected response in imaplib In-Reply-To: <1197427257.83.0.419655228027.issue1598@psf.upfronthosting.co.za> Message-ID: <1205855985.06.0.0167304490629.issue1598@psf.upfronthosting.co.za> Scott Moser added the comment: > Can you provide the message or messages which cause the problem > when they are put in the IMAP server? See attached above > Can you also provide information on what IMAP server software > and version is being used? Its a lotus notes server. Just those 2 words are quite likely to make you think "server bug". The only reason I have to not think that is that the only other imap client i've tested (alpine and pine) works fine. So if indeed it is a server bug, its one that alpine has worked around. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 16:59:48 2008 From: report at bugs.python.org (Travis Oliphant) Date: Tue, 18 Mar 2008 15:59:48 +0000 Subject: [issue2394] Finish the memoryview object implementation In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za> Message-ID: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za> New submission from Travis Oliphant : The memoryview object in Python 3.0 needs to be finished. There are a few methods that are not complete. In particular, the __getitem__ and __setitem__ functionality needs to be finished as well as the tolist() method. ---------- components: Interpreter Core messages: 63928 nosy: teoliphant severity: normal status: open title: Finish the memoryview object implementation type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:01:00 2008 From: report at bugs.python.org (Travis Oliphant) Date: Tue, 18 Mar 2008 16:01:00 +0000 Subject: [issue2395] struct module changes of PEP 3118 In-Reply-To: <1205856060.67.0.357097820084.issue2395@psf.upfronthosting.co.za> Message-ID: <1205856060.67.0.357097820084.issue2395@psf.upfronthosting.co.za> New submission from Travis Oliphant : The additions to the struct module spelled out in PEP 3118 need to be implemented for Python 3.0 ---------- components: Library (Lib) messages: 63929 nosy: teoliphant severity: normal status: open title: struct module changes of PEP 3118 versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:01:12 2008 From: report at bugs.python.org (Travis Oliphant) Date: Tue, 18 Mar 2008 16:01:12 +0000 Subject: [issue2395] struct module changes of PEP 3118 In-Reply-To: <1205856060.67.0.357097820084.issue2395@psf.upfronthosting.co.za> Message-ID: <1205856072.28.0.48976218279.issue2395@psf.upfronthosting.co.za> Changes by Travis Oliphant : ---------- type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:02:43 2008 From: report at bugs.python.org (Travis Oliphant) Date: Tue, 18 Mar 2008 16:02:43 +0000 Subject: [issue2396] Backport memoryview object to Python 2.6 In-Reply-To: <1205856163.49.0.847674946563.issue2396@psf.upfronthosting.co.za> Message-ID: <1205856163.49.0.847674946563.issue2396@psf.upfronthosting.co.za> New submission from Travis Oliphant : The memoryview object in Python 2.6 would help in the transition to Python 3.0. It is a lower-priority and could wait until 2.7 if it doesn't get finished. ---------- components: Interpreter Core messages: 63930 nosy: teoliphant severity: normal status: open title: Backport memoryview object to Python 2.6 type: feature request versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:04:58 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 18 Mar 2008 16:04:58 +0000 Subject: [issue2386] os.strerror missing/HAVE_STRERROR not defined In-Reply-To: <1205843284.03.0.546398560804.issue2386@psf.upfronthosting.co.za> Message-ID: <1205856298.66.0.000515606933235.issue2386@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Attached patch fixes the problem. Note that the original os.strerror code was not standard compliant. See e.g. http://www.opengroup.org/onlinepubs/000095399/functions/strerror.html ---------- keywords: +patch nosy: +belopolsky Added file: http://bugs.python.org/file9729/issue2386.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:04:59 2008 From: report at bugs.python.org (Travis Oliphant) Date: Tue, 18 Mar 2008 16:04:59 +0000 Subject: [issue2397] Backport 3.0 struct module changes to 2.6 In-Reply-To: <1205856299.38.0.249134952512.issue2397@psf.upfronthosting.co.za> Message-ID: <1205856299.38.0.249134952512.issue2397@psf.upfronthosting.co.za> New submission from Travis Oliphant : The changes to the struct module in PEP 3118 should be backported to 2.6 as it is backward compatible and would smooth the transition to 3.0. It is lower priority and could wait until 2.7 ---------- components: Library (Lib) messages: 63931 nosy: teoliphant severity: normal status: open title: Backport 3.0 struct module changes to 2.6 versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:05:35 2008 From: report at bugs.python.org (Travis Oliphant) Date: Tue, 18 Mar 2008 16:05:35 +0000 Subject: [issue2394] [Py3k] Finish the memoryview object implementation In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za> Message-ID: <1205856336.0.0.740853186242.issue2394@psf.upfronthosting.co.za> Changes by Travis Oliphant : ---------- title: Finish the memoryview object implementation -> [Py3k] Finish the memoryview object implementation __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:05:57 2008 From: report at bugs.python.org (Travis Oliphant) Date: Tue, 18 Mar 2008 16:05:57 +0000 Subject: [issue2395] [Py3k] struct module changes of PEP 3118 In-Reply-To: <1205856060.67.0.357097820084.issue2395@psf.upfronthosting.co.za> Message-ID: <1205856357.13.0.138458138616.issue2395@psf.upfronthosting.co.za> Changes by Travis Oliphant : ---------- title: struct module changes of PEP 3118 -> [Py3k] struct module changes of PEP 3118 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:06:37 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 16:06:37 +0000 Subject: [issue1518] Fast globals/builtins access (patch) In-Reply-To: <1196329437.66.0.0945045609125.issue1518@psf.upfronthosting.co.za> Message-ID: <1205856397.39.0.0477593420752.issue1518@psf.upfronthosting.co.za> Guido van Rossum added the comment: Making sure I look at this at least once carefully before releasing. ---------- assignee: -> gvanrossum priority: -> critical __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:16:40 2008 From: report at bugs.python.org (Andy Balaam) Date: Tue, 18 Mar 2008 16:16:40 +0000 Subject: [issue2398] test_errno fails with unexpected error value EREMOTEIO In-Reply-To: <1205857000.67.0.280910583762.issue2398@psf.upfronthosting.co.za> Message-ID: <1205857000.67.0.280910583762.issue2398@psf.upfronthosting.co.za> New submission from Andy Balaam : Running test_errno on my 32-bit Ubuntu Gutsy machine gives me this: $ ./python Lib/test/test_errno.py test_for_improper_attributes (__main__.ErrnoAttributeTests) ... FAIL test_using_errorcode (__main__.ErrnoAttributeTests) ... ok test_attributes_in_errorcode (__main__.ErrorcodeTests) ... ok ====================================================================== FAIL: test_for_improper_attributes (__main__.ErrnoAttributeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_errno.py", line 46, in test_for_improper_attributes "%s is an unexpected error value" % attribute) AssertionError: EREMOTEIO is an unexpected error value ---------------------------------------------------------------------- Ran 3 tests in 0.001s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_errno.py", line 68, in test_main() File "Lib/test/test_errno.py", line 64, in test_main test_support.run_unittest(ErrnoAttributeTests, ErrorcodeTests) File "/home/andy/cvs/python/Lib/test/test_support.py", line 573, in run_unittest _run_suite(suite) File "/home/andy/cvs/python/Lib/test/test_support.py", line 556, in _run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_errno.py", line 46, in test_for_improper_attributes "%s is an unexpected error value" % attribute) AssertionError: EREMOTEIO is an unexpected error value I've attached a patch which changes test_errno.py so that its list of expected errors exactly matches the possible errors listed in Modules/errnomodule.c in the latest SVN trunk. I don't know whether this is the right solution, but the patch is there if it is :) Apologies if I've misunderstood something, or formatted the patch wrong etc. This is my first Python patch. ---------- components: Tests files: add_more_error_values_to_test_errno.patch keywords: patch messages: 63934 nosy: andybalaam severity: normal status: open title: test_errno fails with unexpected error value EREMOTEIO type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file9730/add_more_error_values_to_test_errno.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:21:47 2008 From: report at bugs.python.org (Thomas Heller) Date: Tue, 18 Mar 2008 16:21:47 +0000 Subject: [issue2303] isinstance is 4x as slow as in 2.5 because the common case raises In-Reply-To: <1205682342.69.0.872031501346.issue2303@psf.upfronthosting.co.za> Message-ID: <1205857307.48.0.527644622888.issue2303@psf.upfronthosting.co.za> Thomas Heller added the comment: Would it help to implement a default __instancecheck__ and __subclasscheck__ for object (or for type), that subclasses can override? ---------- nosy: +theller __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:26:28 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 18 Mar 2008 16:26:28 +0000 Subject: [issue2398] test_errno fails with unexpected error value EREMOTEIO In-Reply-To: <1205857000.67.0.280910583762.issue2398@psf.upfronthosting.co.za> Message-ID: <1205857588.02.0.235293799866.issue2398@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the patch, Andy, but I went ahead and fixed test_errno to only explicitly test errno values from Standard C. That way we are not constantly chasing our tail to support every errno value on every platform that Python runs on. ---------- nosy: +brett.cannon resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:29:24 2008 From: report at bugs.python.org (Andy Balaam) Date: Tue, 18 Mar 2008 16:29:24 +0000 Subject: [issue2398] test_errno fails with unexpected error value EREMOTEIO In-Reply-To: <1205857000.67.0.280910583762.issue2398@psf.upfronthosting.co.za> Message-ID: <1205857764.52.0.783420962794.issue2398@psf.upfronthosting.co.za> Andy Balaam added the comment: Adding Brett Cannon since it looks like his checkin created the test which fails on my machine. Apologies if this is very bad etiquette. I couldn't find any guidelines about this in the developers' docs, but probably that's because I am incompetent. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:35:59 2008 From: report at bugs.python.org (Andy Balaam) Date: Tue, 18 Mar 2008 16:35:59 +0000 Subject: [issue2398] test_errno fails with unexpected error value EREMOTEIO In-Reply-To: <1205857000.67.0.280910583762.issue2398@psf.upfronthosting.co.za> Message-ID: <1205858159.73.0.119623650636.issue2398@psf.upfronthosting.co.za> Andy Balaam added the comment: Woah! fast response, and what looks like a much more sensible fix. Thanks Brett. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:38:23 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 16:38:23 +0000 Subject: [issue2390] Merge 2.6 ACKS with 3.0 ACKS In-Reply-To: <1205854707.75.0.657591820184.issue2390@psf.upfronthosting.co.za> Message-ID: <1205858303.9.0.0893291895754.issue2390@psf.upfronthosting.co.za> Changes by Benjamin Peterson : Added file: http://bugs.python.org/file9732/merge_acks.py __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:45:38 2008 From: report at bugs.python.org (Travis Oliphant) Date: Tue, 18 Mar 2008 16:45:38 +0000 Subject: [issue2399] Patches for Tools/msi In-Reply-To: <1205858738.04.0.681248681608.issue2399@psf.upfronthosting.co.za> Message-ID: <1205858738.04.0.681248681608.issue2399@psf.upfronthosting.co.za> New submission from Travis Oliphant : The attached patches add the following features to MSI building: * allow splitting into multiple CABs * prevent problem when data-base commits grow beyond a certain number * fix to handle all file names * change the way unique keys are created in the File and Directory tables by adding a globally-incrementing number to the file name (unless it is a keyfile. This prevents the repeated searching of a large set (important when you are packaing 47k files...) * fix so that the file id that goes into the HashFileTable is never larger than 72 characters. ---------- components: Windows files: msilib_patch.diff keywords: patch messages: 63940 nosy: teoliphant severity: normal status: open title: Patches for Tools/msi type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9733/msilib_patch.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:45:48 2008 From: report at bugs.python.org (Paul Winkler) Date: Tue, 18 Mar 2008 16:45:48 +0000 Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za> Message-ID: <1205858748.81.0.136364031589.issue1180@psf.upfronthosting.co.za> Changes by Paul Winkler : ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:46:27 2008 From: report at bugs.python.org (Travis Oliphant) Date: Tue, 18 Mar 2008 16:46:27 +0000 Subject: [issue2399] Patches for Tools/msi In-Reply-To: <1205858738.04.0.681248681608.issue2399@psf.upfronthosting.co.za> Message-ID: <1205858787.26.0.519654749445.issue2399@psf.upfronthosting.co.za> Changes by Travis Oliphant : Added file: http://bugs.python.org/file9734/msi.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:50:07 2008 From: report at bugs.python.org (Travis Oliphant) Date: Tue, 18 Mar 2008 16:50:07 +0000 Subject: [issue2399] Patches for Tools/msi In-Reply-To: <1205858738.04.0.681248681608.issue2399@psf.upfronthosting.co.za> Message-ID: <1205859007.02.0.996496787745.issue2399@psf.upfronthosting.co.za> Changes by Travis Oliphant : ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:53:03 2008 From: report at bugs.python.org (Bill Janssen) Date: Tue, 18 Mar 2008 16:53:03 +0000 Subject: [issue1581] xmlrpclib.ServerProxy() doesn't use x509 data In-Reply-To: <1197315686.07.0.947605571907.issue1581@psf.upfronthosting.co.za> Message-ID: <1205859183.44.0.260777930693.issue1581@psf.upfronthosting.co.za> Bill Janssen added the comment: Looking at this patch, I definitely agree with the need for documentation. And a test case which uses the SafeTransport class. But the patch itself also needs a bit more work. (It uses httplib.HTTPS underneath, and that needs more work, too.) At a minimum, the caller should be able to optionally specify somehow, either as a contructor arg, or otherwise (a module-global variable, perhaps), a set of certificate-authority root certs, which, if specified, would cause client-side validation of the server's certificate. I think this should be added as an optional constructor arg to the HTTPS class. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:53:45 2008 From: report at bugs.python.org (Neal Norwitz) Date: Tue, 18 Mar 2008 16:53:45 +0000 Subject: [issue2400] from .foo import * should work In-Reply-To: <1205859225.17.0.832455218755.issue2400@psf.upfronthosting.co.za> Message-ID: <1205859225.17.0.832455218755.issue2400@psf.upfronthosting.co.za> New submission from Neal Norwitz : Explicit relative imports using from .foo import * should work. http://mail.python.org/pipermail/python-3000/2008-March/012564.html ---------- components: Interpreter Core messages: 63942 nosy: nnorwitz priority: critical severity: normal status: open title: from .foo import * should work versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:55:02 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 16:55:02 +0000 Subject: [issue1625] bz2.BZ2File doesn't support multiple streams In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za> Message-ID: <1205859302.54.0.295814223237.issue1625@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> niemeyer nosy: +niemeyer priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:55:11 2008 From: report at bugs.python.org (Bill Janssen) Date: Tue, 18 Mar 2008 16:55:11 +0000 Subject: [issue1251] ssl module doesn't support non-blocking handshakes In-Reply-To: <1191970098.04.0.2942232647.issue1251@psf.upfronthosting.co.za> Message-ID: <1205859311.42.0.00476655713156.issue1251@psf.upfronthosting.co.za> Bill Janssen added the comment: I'm working on it. I'll close it when it's finished. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 17:56:57 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 16:56:57 +0000 Subject: [issue1909] Backport: Mixing default keyword arguments with *args In-Reply-To: <1201032273.11.0.991902181918.issue1909@psf.upfronthosting.co.za> Message-ID: <1205859417.29.0.974366686411.issue1909@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- keywords: +26backport priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 18:03:18 2008 From: report at bugs.python.org (Jeff Balogh) Date: Tue, 18 Mar 2008 17:03:18 +0000 Subject: [issue2370] operator.{isCallable,sequenceIncludes} needs a fixer In-Reply-To: <1205784272.93.0.866002228926.issue2370@psf.upfronthosting.co.za> Message-ID: <1205859798.42.0.525031056429.issue2370@psf.upfronthosting.co.za> Jeff Balogh added the comment: I'll get this one. ---------- nosy: +jeff.balogh __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 18:21:22 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 18 Mar 2008 17:21:22 +0000 Subject: [issue2387] cStringIO and unicode In-Reply-To: <1205846879.92.0.0083654313835.issue2387@psf.upfronthosting.co.za> Message-ID: <1205860882.3.0.0724732274674.issue2387@psf.upfronthosting.co.za> Georg Brandl added the comment: The 2.5.1 "fix" was determined to be too backwards-incompatible and since rolled back. The trunk behavior is "correct". Closing as rejected. ---------- nosy: +georg.brandl resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 18:23:47 2008 From: report at bugs.python.org (Eric Smith) Date: Tue, 18 Mar 2008 17:23:47 +0000 Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6 In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za> Message-ID: <1205861027.59.0.983083029926.issue1745@psf.upfronthosting.co.za> Changes by Eric Smith : ---------- nosy: +eric.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 18:24:38 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 17:24:38 +0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1197242604.93.0.919654384861.issue1577@psf.upfronthosting.co.za> Message-ID: <1205861078.71.0.753209915732.issue1577@psf.upfronthosting.co.za> Sean Reifschneider added the comment: After reviewing the discussion I'm going to accept this because: Guido seemed to me to say "figure it out among yourselves". We're talking about shutil, so mimicing the shell move (mv) semantics is not entirely unreasonable. The current semantics are the same as what this patch implements, this just optimizes it from a copy to a rename if possible. Committed into trunk as rev61527. ---------- assignee: -> jafo keywords: +patch nosy: +jafo priority: -> normal resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 18:27:04 2008 From: report at bugs.python.org (Steven Bethard) Date: Tue, 18 Mar 2008 17:27:04 +0000 Subject: [issue2342] Comparing between disparate types should raise a Py3K warning In-Reply-To: <1205777575.3.0.830443648256.issue2342@psf.upfronthosting.co.za> Message-ID: <1205861224.57.0.510525152113.issue2342@psf.upfronthosting.co.za> Steven Bethard added the comment: Resolved in revision 61529. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 18:27:51 2008 From: report at bugs.python.org (Steven Bethard) Date: Tue, 18 Mar 2008 17:27:51 +0000 Subject: [issue2373] Raise Py3K warnings for comparisons that changed In-Reply-To: <1205791834.41.0.508035363827.issue2373@psf.upfronthosting.co.za> Message-ID: <1205861271.37.0.0439898517369.issue2373@psf.upfronthosting.co.za> Steven Bethard added the comment: Revision 61529 adds warnings for object, type, cell and dict comparisons. The code, method and slice warnings are still needed. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 18:29:48 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 17:29:48 +0000 Subject: [issue1975] signals in thread problem In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za> Message-ID: <1205861388.73.0.49964712469.issue1975@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 18:34:40 2008 From: report at bugs.python.org (Michael Foord) Date: Tue, 18 Mar 2008 17:34:40 +0000 Subject: [issue719888] tokenize module w/ coding cookie Message-ID: <1205861680.52.0.261336535531.issue719888@psf.upfronthosting.co.za> Michael Foord added the comment: Made quite extensive changes to tokenize.py (with tests) for Py3k. This migrates it to a 'bytes' API so that it can correctly decode Python source files following PEP-0263. ---------- nosy: +fuzzyman Added file: http://bugs.python.org/file9735/tokenize.zip ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Mar 18 18:37:55 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 17:37:55 +0000 Subject: [issue2008] cookielib lacks FileCookieJar class for Safari In-Reply-To: <1202153846.32.0.869416159529.issue2008@psf.upfronthosting.co.za> Message-ID: <1205861875.72.0.470979160257.issue2008@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> loewis nosy: +loewis priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 18:46:56 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 17:46:56 +0000 Subject: [issue2400] from .foo import * should work In-Reply-To: <1205859225.17.0.832455218755.issue2400@psf.upfronthosting.co.za> Message-ID: <1205862415.98.0.668829978866.issue2400@psf.upfronthosting.co.za> Benjamin Peterson added the comment: More verbosely: The restriction should be removed; a SyntaxError shouldn't be raised, and import should handle it correctly. ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 18:47:28 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 18 Mar 2008 17:47:28 +0000 Subject: [issue719888] tokenize module w/ coding cookie Message-ID: <1205862448.6.0.2218149476.issue719888@psf.upfronthosting.co.za> Mark Dickinson added the comment: Michael, is the disappearance of the generate_tokens function in the new version of tokenize.py intentional? ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Mar 18 18:49:40 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 17:49:40 +0000 Subject: [issue2303] isinstance is 4x as slow as in 2.5 because the common case raises In-Reply-To: <1205682342.69.0.872031501346.issue2303@psf.upfronthosting.co.za> Message-ID: <1205862580.92.0.185646528545.issue2303@psf.upfronthosting.co.za> Guido van Rossum added the comment: Perhaps, though I'm not sure if that doesn't slow things down further due to the complicated protocol for calling it. Also, there's a recursion check in the built-in implementation. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 18:53:00 2008 From: report at bugs.python.org (Michael Foord) Date: Tue, 18 Mar 2008 17:53:00 +0000 Subject: [issue719888] tokenize module w/ coding cookie Message-ID: <1205862780.25.0.381904856154.issue719888@psf.upfronthosting.co.za> Michael Foord added the comment: That was 'by discussion with wiser heads than I'. The existing module has an old backwards compatibility interface called 'tokenize'. That can be deprecated in 2.6. As 'tokenize' is really the ideal name for the main entry point for the module, 'generate_tokens' became tokenize for Py3. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Mar 18 18:57:42 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 17:57:42 +0000 Subject: [issue2373] Raise Py3K warnings for comparisons that changed In-Reply-To: <1205791834.41.0.508035363827.issue2373@psf.upfronthosting.co.za> Message-ID: <1205863062.28.0.210442704216.issue2373@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Your patch kicks up warnings in Objects/cellobject.c because cell_compare returns an int, your patch may return NULL. ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 19:01:23 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 18 Mar 2008 18:01:23 +0000 Subject: [issue719888] tokenize module w/ coding cookie Message-ID: <1205863283.23.0.195193084381.issue719888@psf.upfronthosting.co.za> Mark Dickinson added the comment: Is it worth keeping generate_tokens as an alias for tokenize, just to avoid gratuitous 2-to-3 breakage? Maybe not---I guess they're different beasts, in that one wants a string-valued iterator and the other wants a bytes-valued iterator. So if I understand correctly, the readline argument to tokenize would have to return bytes instances. Would it be worth adding a check for this, to catch possible misuse? You could put the check in detect_encoding, so that just checks that the first one or two yields from readline have the correct type, and assumes that the rest is okay. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Mar 18 19:02:23 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 18 Mar 2008 18:02:23 +0000 Subject: [issue2381] test_subprocess fails if your sys.executable is on a path with a space in it In-Reply-To: <1205813955.12.0.0111122307325.issue2381@psf.upfronthosting.co.za> Message-ID: <1205863343.74.0.193457135175.issue2381@psf.upfronthosting.co.za> Ralf Schmitt added the comment: I can confirm this issue. 2 tests fail without this patch. please apply. here are the failing tests: ====================================================================== FAIL: test_args_string (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/ralf/tt tt/trunk/Lib/test/test_subprocess.py", line 544, in test_args_string self.assertEqual(p.returncode, 47) AssertionError: 126 != 47 ====================================================================== FAIL: test_call_string (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/ralf/tt tt/trunk/Lib/test/test_subprocess.py", line 585, in test_call_string self.assertEqual(rc, 47) AssertionError: 126 != 47 ---------- nosy: +schmir __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 19:05:50 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 18 Mar 2008 18:05:50 +0000 Subject: [issue719888] tokenize module w/ coding cookie Message-ID: <1205863550.72.0.720782365591.issue719888@psf.upfronthosting.co.za> Mark Dickinson added the comment: Sorry---ignore the last comment; if readline() doesn't supply bytes then the line.decode('ascii') will fail with an AttributeError. So there won't be silent failure. I'll try thinking first and posting later next time. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Mar 18 19:06:37 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 18 Mar 2008 18:06:37 +0000 Subject: [issue2303] isinstance is 4x as slow as in 2.5 because the common case raises In-Reply-To: <1205682342.69.0.872031501346.issue2303@psf.upfronthosting.co.za> Message-ID: <1205863597.19.0.794812039058.issue2303@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The attribute lookup cost can mostly be eliminated if __instancecheck__ were given a tp slot. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 19:24:02 2008 From: report at bugs.python.org (Trent Nelson) Date: Tue, 18 Mar 2008 18:24:02 +0000 Subject: [issue719888] tokenize module w/ coding cookie Message-ID: <1205864642.3.0.783534057512.issue719888@psf.upfronthosting.co.za> Trent Nelson added the comment: Tested patch on Win x86/x64 2k8, XP & FreeBSD 6.2, +1. ---------- assignee: -> Trent.Nelson keywords: +patch ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Mar 18 19:33:42 2008 From: report at bugs.python.org (Steven Bethard) Date: Tue, 18 Mar 2008 18:33:42 +0000 Subject: [issue2373] Raise Py3K warnings for comparisons that changed In-Reply-To: <1205863062.28.0.210442704216.issue2373@psf.upfronthosting.co.za> Message-ID: Steven Bethard added the comment: On Tue, Mar 18, 2008 at 11:57 AM, Benjamin Peterson wrote: > Benjamin Peterson added the comment: > > Your patch kicks up warnings in Objects/cellobject.c because > cell_compare returns an int, your patch may return NULL. Thanks. I'll fix that. Steve __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 19:38:01 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 18 Mar 2008 18:38:01 +0000 Subject: [issue2138] Add a factorial function In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za> Message-ID: <1205865481.44.0.764539068725.issue2138@psf.upfronthosting.co.za> Mark Dickinson added the comment: I'm not opposed to adding factorial somewhere, and it doesn't seem as though anyone else is actively opposed to factorial either. The problem is working out where best to put it. To my inexperienced eyes, it feels wrong to add it as an int/long method, though I'm having trouble figuring out exactly why it feels wrong. It doesn't fit well with the stuff in the math module either, as Raymond has pointed out. There are other integer -> integer functions that I'd consider just as fundamental and useful as factorial, for a programming language that has arbitrary-precision integers. Examples are the integer square root (i.e. int(floor(sqrt(n)))), or the number of bits in an integer (int(floor(log(n, 2))). I've needed both of these much more often than factorial. If the powers that be accepted a request to add such functions, would they also naturally become integer methods? And supposing that gcd were added some day, shouldn't it be in the same place as factorial? As to implementation, I'd probably avoid PrimeSwing on the basis that the added complexity, and cost for future maintainers, just isn't worth it. The usual recursive algorithm (writing n! as (n*(n-2)*(n-4)*...) * ((n-1)*(n-3)*...), and then applying similar breakdowns to the subproducts) is probably good enough, together with some caching of small results. I can volunteer to try to implement this sometime before the 2.6/3.0 betas. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 19:38:57 2008 From: report at bugs.python.org (Steven Bethard) Date: Tue, 18 Mar 2008 18:38:57 +0000 Subject: [issue2373] Raise Py3K warnings for comparisons that changed In-Reply-To: <1205791834.41.0.508035363827.issue2373@psf.upfronthosting.co.za> Message-ID: <1205865536.99.0.251951167797.issue2373@psf.upfronthosting.co.za> Steven Bethard added the comment: So I believe it should be returning -2 instead of NULL. Can someone verify that -2 means raise an exception for tp_compare? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 19:58:29 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 18:58:29 +0000 Subject: [issue2029] "python -m pydoc -g" fails In-Reply-To: <1202387094.14.0.198769715828.issue2029@psf.upfronthosting.co.za> Message-ID: <1205866709.2.0.443080097904.issue2029@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> ping nosy: +ping priority: -> normal type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:03:06 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 19:03:06 +0000 Subject: [issue2052] Allow changing difflib._file_template character encoding. In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za> Message-ID: <1205866986.8.0.0350245518044.issue2052@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> tim_one nosy: +tim_one priority: -> normal title: Lack of difflib.HtmlDiff unicode support -> Allow changing difflib._file_template character encoding. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:04:49 2008 From: report at bugs.python.org (Steven Bethard) Date: Tue, 18 Mar 2008 19:04:49 +0000 Subject: [issue2373] Raise Py3K warnings for comparisons that changed In-Reply-To: <1205791834.41.0.508035363827.issue2373@psf.upfronthosting.co.za> Message-ID: <1205867089.68.0.0941407587182.issue2373@psf.upfronthosting.co.za> Steven Bethard added the comment: Ok, that warning should be gone now in trunk. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:06:47 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 18 Mar 2008 19:06:47 +0000 Subject: [issue1747858] chown broken on 64bit Message-ID: <1205867207.02.0.521244232618.issue1747858@psf.upfronthosting.co.za> Gregory P. Smith added the comment: fixed in trunk r61540. I'm leaving this open until i backport it to release25-maint. ---------- resolution: -> remind versions: -Python 2.6 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Mar 18 20:08:49 2008 From: report at bugs.python.org (Michael Bishop) Date: Tue, 18 Mar 2008 19:08:49 +0000 Subject: [issue1911] webbrowser.open firefox 3 issues In-Reply-To: <1201051771.85.0.184797349871.issue1911@psf.upfronthosting.co.za> Message-ID: <1205867329.86.0.11184911629.issue1911@psf.upfronthosting.co.za> Changes by Michael Bishop : ---------- type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:11:31 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 19:11:31 +0000 Subject: [issue2401] Solaris: ctypes tests being skipped despite following #1516 In-Reply-To: <1205867491.87.0.489555231909.issue2401@psf.upfronthosting.co.za> Message-ID: <1205867491.87.0.489555231909.issue2401@psf.upfronthosting.co.za> New submission from Sean Reifschneider : This is a break-out of the multi-issue #2048. Original poster Atro Tossavainen (atossava) reports:Building and testing on Solaris 8 on SPARC with Sun compilers: cc: Sun C 5.8 2005/10/13 CC: Sun C++ 5.8 2005/10/13 281 tests OK. 40 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_ctypes test_curses test_gdbm test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_startfile test_sunaudiodev test_tcl test_timeout test_unicode_file test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 4 skips unexpected on sunos5: test_tcl test_sunaudiodev test_ctypes test_nis ... test_tcl skipped -- No module named _tkinter ... I have applied the _ctypes patch in #1516, however. What gives? ---------- assignee: loewis components: Build messages: 63965 nosy: atossava, jafo, loewis priority: normal severity: normal status: open title: Solaris: ctypes tests being skipped despite following #1516 type: compile error versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:12:20 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 19:12:20 +0000 Subject: [issue2401] Solaris: ctypes tests being skipped despite following #1516 In-Reply-To: <1205867491.87.0.489555231909.issue2401@psf.upfronthosting.co.za> Message-ID: <1205867540.32.0.124847008076.issue2401@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Martin v. L?wis (loewis) replies: What is the specific problem that you are reporting? I.e. what behavior did you expect instead? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:16:53 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 19:16:53 +0000 Subject: [issue2401] Solaris: ctypes tests being skipped despite following #1516 In-Reply-To: <1205867491.87.0.489555231909.issue2401@psf.upfronthosting.co.za> Message-ID: <1205867813.39.0.0118316688816.issue2401@psf.upfronthosting.co.za> Sean Reifschneider added the comment: This is me: Martin: I believe the report is that the user followed #1516 but ctypes was not built, or at least the test was skipped. Assigning to theller, because that's whom #1516 is assigned to. ---------- assignee: loewis -> theller nosy: +theller __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:18:37 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 18 Mar 2008 19:18:37 +0000 Subject: [issue2138] Add a factorial function In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za> Message-ID: <1205867917.79.0.0651427773833.issue2138@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I prefer factorial as a method (like Ruby and Smalltalk). Given the usual notation (n!) or pronounciation (n factorial), it is natural to write this as: n.factorial(). Compared to numbits() and isqrt(), a factorial() method is more basic in that it is self explanatory and everyone knows what it means by the time they are in middle school. FWIW, if separate RFEs were opened for numbits() and isqrt(), I would support their being int methods too. Their implementations are helped by access to the underlying representation, and a case could be made that these no argument calls are just properties of the number (just like the sign bit). __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:21:55 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 19:21:55 +0000 Subject: [issue2048] IRIX: Seg-fault while building tests with gmake on test_xml_etree. In-Reply-To: <1202465958.71.0.917319505775.issue2048@psf.upfronthosting.co.za> Message-ID: <1205868115.16.0.177251900734.issue2048@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Created issue #2401 for the Solaris problem. Repurposing this issue to just be the IRIX issue. ---------- nosy: +jafo priority: -> normal title: Python 2.5.1 woes on IRIX, Solaris -> IRIX: Seg-fault while building tests with gmake on test_xml_etree. type: -> compile error __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:23:33 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 18 Mar 2008 19:23:33 +0000 Subject: [issue2392] Sean is testing tracker bug. Message-ID: <1205868213.15.0.467615407575.issue2392@psf.upfronthosting.co.za> Changes by Martin v. L?wis : __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:23:50 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 18 Mar 2008 19:23:50 +0000 Subject: [issue2392] Sean is testing tracker bug. Message-ID: <1205868230.94.0.640137106295.issue2392@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:26:33 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 18 Mar 2008 19:26:33 +0000 Subject: [issue1747858] chown broken on 64bit Message-ID: <1205868393.1.0.8062606591.issue1747858@psf.upfronthosting.co.za> Gregory P. Smith added the comment: backported to 2.5 in r61542 and r61544. it'll go into py3k via the regular merges from trunk. The fix just changed the int -> long and 'ii' -> 'll' and added unit test coverage. The patch attached to this bug was rejected as too complex: If conditional treatment of the types is ever needed it should be done at build time via autoconf and not at runtime. ---------- keywords: -patch resolution: remind -> fixed status: open -> closed versions: -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Mar 18 20:28:11 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 19:28:11 +0000 Subject: [issue2074] pprint._safe_repr() unsafe on ordering differently types objects with same str represenation In-Reply-To: <1202784439.48.0.0759142195952.issue2074@psf.upfronthosting.co.za> Message-ID: <1205868491.19.0.171652025955.issue2074@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I don't know if this is still relevent, if it is please provide a test that demonstrates it. I've checked the code and found that the code to be patched no longer exists. To me, it looks like it might be resolved. ---------- keywords: +patch nosy: +jafo priority: -> normal resolution: -> out of date status: open -> closed type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:28:22 2008 From: report at bugs.python.org (David Wolever) Date: Tue, 18 Mar 2008 19:28:22 +0000 Subject: [issue2171] Add map, filter, zip to future_builtins In-Reply-To: <1203812914.42.0.434541981805.issue2171@psf.upfronthosting.co.za> Message-ID: <1205868501.95.0.741756290602.issue2171@psf.upfronthosting.co.za> David Wolever added the comment: Filter has been fixed in r61546. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:39:37 2008 From: report at bugs.python.org (Jeff Balogh) Date: Tue, 18 Mar 2008 19:39:37 +0000 Subject: [issue2370] operator.{isCallable,sequenceIncludes} needs a fixer In-Reply-To: <1205784272.93.0.866002228926.issue2370@psf.upfronthosting.co.za> Message-ID: <1205869177.64.0.689796128122.issue2370@psf.upfronthosting.co.za> Jeff Balogh added the comment: Attaching a patch that operator.{isCallable,sequenceIncludes}, including tests. ---------- keywords: +patch Added file: http://bugs.python.org/file9736/issue2370.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:42:51 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 19:42:51 +0000 Subject: [issue2076] xmlrpclib closes connection after each call In-Reply-To: <1202814252.95.0.393197834217.issue2076@psf.upfronthosting.co.za> Message-ID: <1205869371.23.0.501173237151.issue2076@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> effbot nosy: +effbot priority: -> normal type: -> feature request __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:42:58 2008 From: report at bugs.python.org (Jerry Seutter) Date: Tue, 18 Mar 2008 19:42:58 +0000 Subject: [issue2403] Add figleaf coverage metrics In-Reply-To: <1205869378.43.0.216108511876.issue2403@psf.upfronthosting.co.za> Message-ID: <1205869378.43.0.216108511876.issue2403@psf.upfronthosting.co.za> New submission from Jerry Seutter : This issue adds support for figleaf unit test coverage information. The diffs apply against trunk ---------- components: Tests files: README.patch keywords: patch, patch messages: 63975 nosy: jseutter priority: low severity: normal status: open title: Add figleaf coverage metrics versions: Python 2.6 Added file: http://bugs.python.org/file9737/README.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:45:37 2008 From: report at bugs.python.org (Jerry Seutter) Date: Tue, 18 Mar 2008 19:45:37 +0000 Subject: [issue2403] Add figleaf coverage metrics In-Reply-To: <1205869378.43.0.216108511876.issue2403@psf.upfronthosting.co.za> Message-ID: <1205869537.85.0.0957276779381.issue2403@psf.upfronthosting.co.za> Changes by Jerry Seutter : Added file: http://bugs.python.org/file9738/coverage.zip __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:47:13 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 19:47:13 +0000 Subject: [issue2077] Interpreter crash on shutdown In-Reply-To: <1202817025.41.0.0817912479052.issue2077@psf.upfronthosting.co.za> Message-ID: <1205869633.77.0.628354424856.issue2077@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:51:38 2008 From: report at bugs.python.org (Jerry Seutter) Date: Tue, 18 Mar 2008 19:51:38 +0000 Subject: [issue2403] Add figleaf coverage metrics In-Reply-To: <1205869378.43.0.216108511876.issue2403@psf.upfronthosting.co.za> Message-ID: <1205869898.58.0.566421902495.issue2403@psf.upfronthosting.co.za> Jerry Seutter added the comment: To test: 1. Unzip the zipfile in the base python directory. The zipfile will create Tools/coverage*. 2. cd Tools; patch -p0 README.patch 3. cd coverage 4. ../../python.exe coverage.py The script will download figleaf, then run regrtest.py. Any extra stuff on the command line will be supplied to regrtest. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:52:28 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 19:52:28 +0000 Subject: [issue2090] __import__ with fromlist=[''] causes double initialization of modules In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za> Message-ID: <1205869948.35.0.767818661608.issue2090@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> brett.cannon nosy: +brett.cannon priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:53:07 2008 From: report at bugs.python.org (Travis Oliphant) Date: Tue, 18 Mar 2008 19:53:07 +0000 Subject: [issue2404] Backport ctypes support for buffer protocol to Python 2.6 (ref issue1971) In-Reply-To: <1205869987.72.0.778621175658.issue2404@psf.upfronthosting.co.za> Message-ID: <1205869987.72.0.778621175658.issue2404@psf.upfronthosting.co.za> New submission from Travis Oliphant : The ctypes object will support the PEP 3118 buffer protocol. This support can be back-ported to Python 2.6 ---------- messages: 63977 nosy: teoliphant severity: normal status: open title: Backport ctypes support for buffer protocol to Python 2.6 (ref issue1971) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:53:20 2008 From: report at bugs.python.org (Travis Oliphant) Date: Tue, 18 Mar 2008 19:53:20 +0000 Subject: [issue2404] Backport ctypes support for buffer protocol to Python 2.6 (ref issue1971) In-Reply-To: <1205869987.72.0.778621175658.issue2404@psf.upfronthosting.co.za> Message-ID: <1205870000.6.0.0670362886675.issue2404@psf.upfronthosting.co.za> Changes by Travis Oliphant : ---------- assignee: -> theller components: +ctypes nosy: +theller type: -> behavior versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 20:55:17 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 19:55:17 +0000 Subject: [issue2100] unit test UnicodeWarning In-Reply-To: <1202912464.45.0.11566210495.issue2100@psf.upfronthosting.co.za> Message-ID: <1205870117.02.0.140683032477.issue2100@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> mhammond nosy: +mhammond priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 21:00:19 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Tue, 18 Mar 2008 20:00:19 +0000 Subject: [issue2073] asynchat push always sends 512 bytes (ignoring ac_out_buffer_size) In-Reply-To: <1202768252.75.0.386707250967.issue2073@psf.upfronthosting.co.za> Message-ID: <1205870419.04.0.653936051328.issue2073@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> gvanrossum nosy: +gvanrossum priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 21:09:29 2008 From: report at bugs.python.org (Trent Nelson) Date: Tue, 18 Mar 2008 20:09:29 +0000 Subject: [issue2405] Drop w9xpopen and all dependencies In-Reply-To: <1205870969.55.0.774025556957.issue2405@psf.upfronthosting.co.za> Message-ID: <1205870969.55.0.774025556957.issue2405@psf.upfronthosting.co.za> New submission from Trent Nelson : Python 2.6+ drops support for Windows 95/98, which removes the need for w9xpopen. Get rid of the module and all dependencies (such as in the .msi). ---------- assignee: Trent.Nelson components: Build messages: 63978 nosy: Trent.Nelson severity: normal status: open title: Drop w9xpopen and all dependencies type: feature request versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 21:19:43 2008 From: report at bugs.python.org (Neal Norwitz) Date: Tue, 18 Mar 2008 20:19:43 +0000 Subject: [issue2403] Add figleaf coverage metrics In-Reply-To: <1205869378.43.0.216108511876.issue2403@psf.upfronthosting.co.za> Message-ID: <1205871583.07.0.735810072102.issue2403@psf.upfronthosting.co.za> Neal Norwitz added the comment: Thanks for the patch. It would be nice to get more instrumentation like coverage, performance, etc. Here are some things I noticed while reviewing the patch: * This won't work on unix other than OSX. Can you change ../../python.exe to sys.executable? * How big is figleaf? Should you try to read/write the file in chunks? * optparse doesn't seem to be used. * Can you change `cat file` to read the file and pass those as arguments so this could work on windows? BTW, does figleaf work on Windows? ---------- nosy: +nnorwitz __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 21:27:37 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 18 Mar 2008 20:27:37 +0000 Subject: [issue719888] tokenize module w/ coding cookie Message-ID: <1205872057.28.0.856591105304.issue719888@psf.upfronthosting.co.za> Mark Dickinson added the comment: With the patch, ./python.exe Lib/test/regrtest.py test_tokenize fails for me with the following output: Macintosh-2:py3k dickinsm$ ./python.exe Lib/test/regrtest.py test_tokenize test_tokenize test test_tokenize produced unexpected output: ********************************************************************** *** lines 2-5 of actual output doesn't appear in expected output after line 1: + testing: /Users/dickinsm/python_source/py3k/Lib/test/tokenize_tests-latin1-coding-cookie-and-utf8-bom-sig.txt + testing: /Users/dickinsm/python_source/py3k/Lib/test/tokenize_tests-no-coding-cookie-and-utf8-bom-sig-only.txt + testing: /Users/dickinsm/python_source/py3k/Lib/test/tokenize_tests-utf8-coding-cookie-and-utf8-bom-sig.txt + testing: /Users/dickinsm/python_source/py3k/Lib/test/tokenize_tests-utf8-coding-cookie-and-utf8-bom-sig.txt ********************************************************************** 1 test failed: test_tokenize [65880 refs] I get something similar on Linux. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Mar 18 21:29:43 2008 From: report at bugs.python.org (M.-A. DARCHE) Date: Tue, 18 Mar 2008 20:29:43 +0000 Subject: [issue2406] Improvement suggestions for the gzip module documentation In-Reply-To: <1205872183.57.0.209526870399.issue2406@psf.upfronthosting.co.za> Message-ID: <1205872183.57.0.209526870399.issue2406@psf.upfronthosting.co.za> New submission from M.-A. DARCHE : The documentation for the gzip python module as found at http://docs.python.org/lib/module-gzip.html could be improved by code examples. Those examples are really lacking. Here below are the code snippets I propose. This is inspired by http://xahlee.org/perl-python/python_doc_gzip.html but done with respect and with another useful (I think) example. # Example of how to decompress a file import gzip file_obj = gzip.GzipFile('/home/joe/file.txt.gz', 'rb'); file_content = file_obj.read() file_obj.close() # Example of how to create a compressed GZIP file import gzip file_content = "Lots of content here" file_obj = gzip.GzipFile('/home/joe/file.txt.gz', 'wb'); file_obj.write(file_content) file_content.close() # Example of how to compress an existing file import shutil import gzip file_obj_in = file('/home/joe/file.txt', 'rb') file_obj_out = gzip.GzipFile('/home/joe/file.txt.gz', 'wb'); shutil.copyfileobj(file_obj_in, file_obj_out) file_obj_out.close() Best regards. ---------- assignee: georg.brandl components: Documentation messages: 63981 nosy: georg.brandl, madarche severity: normal status: open title: Improvement suggestions for the gzip module documentation __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 21:32:25 2008 From: report at bugs.python.org (Michael Foord) Date: Tue, 18 Mar 2008 20:32:25 +0000 Subject: [issue719888] tokenize module w/ coding cookie Message-ID: <1205872345.31.0.219306990314.issue719888@psf.upfronthosting.co.za> Michael Foord added the comment: If you remove the following line from the tests (which generates spurious additional output on stdout) then the problem goes away: print('testing: %s' % path, end='\n') ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Mar 18 21:55:14 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 20:55:14 +0000 Subject: [issue2073] asynchat push always sends 512 bytes (ignoring ac_out_buffer_size) In-Reply-To: <1202768252.75.0.386707250967.issue2073@psf.upfronthosting.co.za> Message-ID: <1205873714.33.0.744680444918.issue2073@psf.upfronthosting.co.za> Guido van Rossum added the comment: I know nothing about asyncore. Does this problem still exist in the trunk (2.6)? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 21:56:44 2008 From: report at bugs.python.org (Jerry Seutter) Date: Tue, 18 Mar 2008 20:56:44 +0000 Subject: [issue2407] warnings.filterwarnings() not isolated between tests In-Reply-To: <1205873804.14.0.137963727485.issue2407@psf.upfronthosting.co.za> Message-ID: <1205873804.14.0.137963727485.issue2407@psf.upfronthosting.co.za> New submission from Jerry Seutter : Some tests were not cleaning up warning filters. Fixed the problem by making regrtest.py restore default filters before each module is executed. This exposed other errors which are also fixed in the patch. The patch only affects test files. ---------- components: Tests files: warnings_fix.patch keywords: patch, patch messages: 63984 nosy: jseutter priority: low severity: normal status: open title: warnings.filterwarnings() not isolated between tests versions: Python 2.6 Added file: http://bugs.python.org/file9739/warnings_fix.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 21:57:50 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 20:57:50 +0000 Subject: [issue2402] get rid of warnings in regrtest with -3 Message-ID: <1205873870.57.0.750050800191.issue2402@psf.upfronthosting.co.za> Benjamin Peterson added the comment: No, *correct usage* of the stdlib should not result in Py3k warnings. Old APIs should still be tested, which I suppose is part of the reason that there are so many warnings from testing. ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 21:59:32 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 20:59:32 +0000 Subject: [issue2303] isinstance is 4x as slow as in 2.5 because the common case raises In-Reply-To: <1205682342.69.0.872031501346.issue2303@psf.upfronthosting.co.za> Message-ID: <1205873972.63.0.711524048159.issue2303@psf.upfronthosting.co.za> Guido van Rossum added the comment: Yeah, but tp_ slots are expensive themselves (mostly in the amount of code that needs to be changed -- see typeobject.c). __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 22:02:18 2008 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 18 Mar 2008 21:02:18 +0000 Subject: [issue1581] xmlrpclib.ServerProxy() doesn't use x509 data In-Reply-To: <1197315686.07.0.947605571907.issue1581@psf.upfronthosting.co.za> Message-ID: <1205874138.71.0.0636793519688.issue1581@psf.upfronthosting.co.za> Guido van Rossum added the comment: Let's tentatively say this needs to go into 2.6. Bill, if in the end you decide against it, just reject the patch. ---------- priority: -> critical versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 22:09:30 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 21:09:30 +0000 Subject: [issue2408] types should expose cell object In-Reply-To: <1205874570.2.0.410256172712.issue2408@psf.upfronthosting.co.za> Message-ID: <1205874570.2.0.410256172712.issue2408@psf.upfronthosting.co.za> New submission from Benjamin Peterson : types currently exposes all types used by the interpreter except cell objects. This patch adds support for that and adds to the docs. I couldn't find a way to access the cell type through Python, so I added it to the _types module. ---------- components: Interpreter Core, Library (Lib) files: expose_cell.patch keywords: patch messages: 63988 nosy: benjamin.peterson severity: normal status: open title: types should expose cell object type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file9740/expose_cell.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 22:15:12 2008 From: report at bugs.python.org (Steven Bethard) Date: Tue, 18 Mar 2008 21:15:12 +0000 Subject: [issue2402] get rid of warnings in regrtest with -3 Message-ID: <1205874912.34.0.0448524738909.issue2402@psf.upfronthosting.co.za> Steven Bethard added the comment: Fair enough. I agree that the deprecated APIs should still be tested. But there are a lot of other warnings, e.g. where the standard lib uses ``has_key`` instead of ``in``. These should be removed. The only warnings should be those that are actively testing deprecated APIs. Testing of deprecated APIs should probably temporarily suppress the Py3K warnings while they're executing, though that's not really crucial. Reducing the flood of warnings is really worthwhile -- I just fixed a bug in test_atexit which only appeared when -3 was supplied. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 22:16:06 2008 From: report at bugs.python.org (Michael Foord) Date: Tue, 18 Mar 2008 21:16:06 +0000 Subject: [issue719888] tokenize module w/ coding cookie Message-ID: <1205874966.51.0.249675765208.issue719888@psf.upfronthosting.co.za> Michael Foord added the comment: *Full* patch (excluding the new dependent test text files) for Python 3. Includes fixes for standard library and tools usage of tokenize. If it breaks anything blame Trent... ;-) ---------- versions: -Python 2.6 Added file: http://bugs.python.org/file9741/tokenize_patch.diff ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Mar 18 22:20:28 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 18 Mar 2008 21:20:28 +0000 Subject: [issue2303] isinstance is 4x as slow as in 2.5 because the common case raises In-Reply-To: <1205682342.69.0.872031501346.issue2303@psf.upfronthosting.co.za> Message-ID: <1205875228.42.0.266337205916.issue2303@psf.upfronthosting.co.za> Raymond Hettinger added the comment: No doubt it would take some work. IMO, code for a slot is worth it; otherwise, many apps will have to pay the price for ABCs even if they don't use the feature. For my company, that would deter an upgrade to 2.6. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 22:22:28 2008 From: report at bugs.python.org (Neal Norwitz) Date: Tue, 18 Mar 2008 21:22:28 +0000 Subject: [issue2409] regrtest should not just skip imports that fail In-Reply-To: <1205875348.54.0.487257679211.issue2409@psf.upfronthosting.co.za> Message-ID: <1205875348.54.0.487257679211.issue2409@psf.upfronthosting.co.za> New submission from Neal Norwitz : Guido mentioned this in python-3000-checkins. I agree the problem should be fixed. """ I think the automatic skip on ImportError is harmful. We should add a helper function to test_support so that you can write foobar = test_support.import_optional('foobar') and it will skip the test if foobar cannot be imported; all other failing imports should cause the test to *fail*. This should be an easy two-part task. """ ---------- components: Tests messages: 63992 nosy: nnorwitz priority: high severity: normal status: open title: regrtest should not just skip imports that fail versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 22:27:56 2008 From: report at bugs.python.org (Bruce Frederiksen) Date: Tue, 18 Mar 2008 21:27:56 +0000 Subject: [issue2410] absolute import doesn't work for standard python modules In-Reply-To: <1205875676.38.0.76467063797.issue2410@psf.upfronthosting.co.za> Message-ID: <1205875676.38.0.76467063797.issue2410@psf.upfronthosting.co.za> New submission from Bruce Frederiksen : Try this to reproduce error: $ mkdir -p test/email $ cd test $ touch __init__.py email/__init__.py $ cat < foo.py from __future__ import absolute_import import smtplib ! $ python >>> import foo ... File "/usr/lib/python2.6/smtplib.py", line 46, in import email.utils ImportError: No module named utils If you rename the email subdirectory, it will find email.utils where it should find it. Strangely, this doesn't happen if you have an 'os' subdirectory and try to import shlex, which does: import os.path ?? ---------- components: Interpreter Core messages: 63993 nosy: dangyogi severity: normal status: open title: absolute import doesn't work for standard python modules type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 22:35:52 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 21:35:52 +0000 Subject: [issue2402] get rid of warnings in regrtest with -3 Message-ID: <1205876152.35.0.262285693253.issue2402@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I made a little decorator which silences py3k warnings. It could be useful for test.test_support. def silence_py3k(func): def decorator(*args, **kwargs): warnings.simplefilter("ignore", warnings.DeprecationWarning) func(*args, **kwargs) warnings.simplefilter("default", warnings.DeprecationWarning) if sys.flags_py3kwarning: return decorator else: return func __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 22:45:08 2008 From: report at bugs.python.org (Mike Coleman) Date: Tue, 18 Mar 2008 21:45:08 +0000 Subject: [issue2073] asynchat push always sends 512 bytes (ignoring ac_out_buffer_size) In-Reply-To: <3c6c07c20803181432n7858b883t1a13bd3946776323@mail.gmail.com> Message-ID: <3c6c07c20803181445q5584c067sff91fa955f851e12@mail.gmail.com> Mike Coleman added the comment: [Tracker bounced this the first time...] > I haven't run it, but just browsing the trunk source, it appears to > still be present. In fact, asynchat.py and asyncore.py have > apparently not been changed in two years. Andrew Kuchling would seem > to be the closest to this code (?), since medusa is apparently dead. > > (More broadly, if these modules are going to stay, they really need to > be preened and better documented. It's not at all obvious, for > example, how the handle_error, handle_expt, and handle_close functions > all fit together. Is handle_error supposed to call handle_close, or > will the modules make that happen internally? etc.) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 22:48:02 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 21:48:02 +0000 Subject: [issue2196] Fix hasattr's exception problems In-Reply-To: <1204066315.71.0.0794011213674.issue2196@psf.upfronthosting.co.za> Message-ID: <1205876882.2.0.400821992691.issue2196@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Further comments? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 22:48:12 2008 From: report at bugs.python.org (Steven Bethard) Date: Tue, 18 Mar 2008 21:48:12 +0000 Subject: [issue2373] Raise Py3K warnings for comparisons that changed In-Reply-To: <1205791834.41.0.508035363827.issue2373@psf.upfronthosting.co.za> Message-ID: <1205876892.44.0.163708428792.issue2373@psf.upfronthosting.co.za> Steven Bethard added the comment: I took a closer look at sliceobject.c and it looks like both 2.6 and 3.0 compare them basically as tuples. So there don't need to be any warnings about using < and > since these are still well defined. I'll have a patch for codeobject.c and methodobject.c soon. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 22:50:40 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 18 Mar 2008 21:50:40 +0000 Subject: [issue719888] tokenize module w/ coding cookie Message-ID: <1205877040.36.0.0539110005909.issue719888@psf.upfronthosting.co.za> Mark Dickinson added the comment: All tests pass for me on OS X 10.5.2 and SuSE Linux 10.2 (32-bit)! ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Mar 18 22:51:54 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 18 Mar 2008 21:51:54 +0000 Subject: [issue2196] Fix hasattr's exception problems In-Reply-To: <1205876882.2.0.400821992691.issue2196@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: On Tue, Mar 18, 2008 at 4:48 PM, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > Further comments? I have not looked at the patch yet (and I don't know when I will get to it). __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 23:04:44 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 22:04:44 +0000 Subject: [issue2171] Add map, filter, zip to future_builtins In-Reply-To: <1203812914.42.0.434541981805.issue2171@psf.upfronthosting.co.za> Message-ID: <1205877884.08.0.748892676078.issue2171@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 23:19:38 2008 From: report at bugs.python.org (Steven Bethard) Date: Tue, 18 Mar 2008 22:19:38 +0000 Subject: [issue2373] Raise Py3K warnings for comparisons that changed In-Reply-To: <1205791834.41.0.508035363827.issue2373@psf.upfronthosting.co.za> Message-ID: <1205878778.17.0.460332624895.issue2373@psf.upfronthosting.co.za> Steven Bethard added the comment: Resolved in revision 61570. I can't get svnmerge block to work though. Since the code and method changes are just backports of Python 3, someone needs to run ``svnmerge.py block -r 61570``. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 23:23:50 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 18 Mar 2008 22:23:50 +0000 Subject: [issue2408] types should expose cell object In-Reply-To: <1205874570.2.0.410256172712.issue2408@psf.upfronthosting.co.za> Message-ID: <1205879030.22.0.170883911746.issue2408@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The following python code retrieves the cell type, and could be added to types.py: def _f(x=None): def g(): x return g CellType = type(_f().func_closure[0]) OTOH, you are unlikely to need it. Do you have a use case, or is it just to have the full list of types? ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 23:25:16 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 18 Mar 2008 22:25:16 +0000 Subject: [issue2303] isinstance is 4x as slow as in 2.5 because the common case raises In-Reply-To: <1205682342.69.0.872031501346.issue2303@psf.upfronthosting.co.za> Message-ID: <1205879116.16.0.770919512757.issue2303@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Attaching a small patch to speed-up one easy case. ---------- keywords: +patch Added file: http://bugs.python.org/file9742/isinst.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 23:29:42 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 18 Mar 2008 22:29:42 +0000 Subject: [issue2408] types should expose cell object In-Reply-To: <1205874570.2.0.410256172712.issue2408@psf.upfronthosting.co.za> Message-ID: <1205879382.09.0.714340703232.issue2408@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: While I'm at it, the _types module could be removed, because its exports can easily be replaced by: GetSetDescriptorType = type(Exception.args) MemberDescriptorType = type(EnvironmentError.errno) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 23:30:22 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 22:30:22 +0000 Subject: [issue2408] types should expose cell object In-Reply-To: <1205874570.2.0.410256172712.issue2408@psf.upfronthosting.co.za> Message-ID: <1205879422.9.0.491271026086.issue2408@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I've attached a patch which uses the Amaury's implementation. >OTOH, you are unlikely to need it. Do you have a use case, or is it just >to have the full list of types? Mostly, I want a full list of types. Added file: http://bugs.python.org/file9743/expose_cell_python.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 23:39:53 2008 From: report at bugs.python.org (Jerry Seutter) Date: Tue, 18 Mar 2008 22:39:53 +0000 Subject: [issue2403] Add figleaf coverage metrics In-Reply-To: <1205869378.43.0.216108511876.issue2403@psf.upfronthosting.co.za> Message-ID: <1205879993.33.0.049766214913.issue2403@psf.upfronthosting.co.za> Jerry Seutter added the comment: Thanks for the input. * ../../python.exe changed to sys.executable. * Figleaf is 69kb. It seems to work fine doing it all in one read() call. Should it be chunked? * Optparse isn't used, partially because I'm lazy and partly because I'm not actually parsing the command line, just chopping the first element off and then passing it off to regrtest.py. It is the job of regrtest.py to parse the command line. <-- My opinion * traceless. I think I should remove the file. Having tests that fail don't hurt figleaf, as far as I know, so there isn't much point to avoiding failing tests. Uploading a new version of the .zip file that uses sys.executable and does not use traceless. I don't know if figleaf works on windows and I don't have a system to test with. Added file: http://bugs.python.org/file9744/coverage.zip __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 23:41:18 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 18 Mar 2008 22:41:18 +0000 Subject: [issue719888] tokenize module w/ coding cookie In-Reply-To: <1205863283.23.0.195193084381.issue719888@psf.upfronthosting.co.za> Message-ID: <47E0450C.1070603@v.loewis.de> Martin v. L?wis added the comment: > Is it worth keeping generate_tokens as an alias for tokenize, just > to avoid gratuitous 2-to-3 breakage? Maybe not---I guess they're > different beasts, in that one wants a string-valued iterator and the > other wants a bytes-valued iterator. Exactly so - that was the primary rationale for renaming it. It shouldn't "silently" return something else, but there should be an explicit clue that you need to port actively. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Mar 18 23:43:19 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 18 Mar 2008 22:43:19 +0000 Subject: [issue2408] types module can be implemented only in Python In-Reply-To: <1205874570.2.0.410256172712.issue2408@psf.upfronthosting.co.za> Message-ID: <1205880199.25.0.687341963866.issue2408@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Okay, I removed the _types module in favor of your Python implementation. Here's the patch. ---------- title: types should expose cell object -> types module can be implemented only in Python Added file: http://bugs.python.org/file9745/types_in_python.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 23:43:41 2008 From: report at bugs.python.org (Neal Norwitz) Date: Tue, 18 Mar 2008 22:43:41 +0000 Subject: [issue2403] Add figleaf coverage metrics In-Reply-To: <1205879993.33.0.049766214913.issue2403@psf.upfronthosting.co.za> Message-ID: Neal Norwitz added the comment: > * ../../python.exe changed to sys.executable. > * Figleaf is 69kb. It seems to work fine doing it all in one read() > call. Should it be chunked? At 69kb, nah. It should be good enough for the first cut. > * Optparse isn't used, partially because I'm lazy and partly because > I'm not actually parsing the command line, just chopping the first > element off and then passing it off to regrtest.py. It is the job of > regrtest.py to parse the command line. <-- My opinion Oh sorry, I only meant to remove the import since it wasn't used. I wasn't secretly trying to get you to do more work (at least not yet). :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 23:51:01 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 18 Mar 2008 22:51:01 +0000 Subject: [issue2405] Drop w9xpopen and all dependencies In-Reply-To: <1205870969.55.0.774025556957.issue2405@psf.upfronthosting.co.za> Message-ID: <1205880661.07.0.389493270238.issue2405@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Tim Peters once commented that w9xpopen cannot go away as long as people still use alternative shells (through COMSPEC) that still have the original issue that command.com had. I don't know how relevant that still is, and whether perhaps breakage is acceptable if people install odd shells that are not fully compatible with cmd.exe. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 23:56:50 2008 From: report at bugs.python.org (Simon Percivall) Date: Tue, 18 Mar 2008 22:56:50 +0000 Subject: [issue2074] pprint._safe_repr() unsafe on ordering differently types objects with same str represenation In-Reply-To: <1202784439.48.0.0759142195952.issue2074@psf.upfronthosting.co.za> Message-ID: <1205881010.22.0.245476339446.issue2074@psf.upfronthosting.co.za> Changes by Simon Percivall : Added file: http://bugs.python.org/file9746/test_pprint30_bug.py __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 18 23:58:40 2008 From: report at bugs.python.org (Taek Joo Kim) Date: Tue, 18 Mar 2008 22:58:40 +0000 Subject: [issue2367] Fixer to handle new places where parentheses are needed In-Reply-To: <1205783754.65.0.365050189029.issue2367@psf.upfronthosting.co.za> Message-ID: <1205881120.34.0.52944759834.issue2367@psf.upfronthosting.co.za> Taek Joo Kim added the comment: This patch handles the conversion. ---------- keywords: +patch nosy: +taicki Added file: http://bugs.python.org/file9747/i2367.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 00:00:11 2008 From: report at bugs.python.org (Simon Percivall) Date: Tue, 18 Mar 2008 23:00:11 +0000 Subject: [issue2074] pprint._safe_repr() unsafe on ordering differently types objects with same str represenation In-Reply-To: <1202784439.48.0.0759142195952.issue2074@psf.upfronthosting.co.za> Message-ID: <1205881211.78.0.186046844397.issue2074@psf.upfronthosting.co.za> Simon Percivall added the comment: It's still a problem, as the test case demonstrates. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 00:14:18 2008 From: report at bugs.python.org (Jeff Balogh) Date: Tue, 18 Mar 2008 23:14:18 +0000 Subject: [issue2357] sys.exc_{type, values, traceback} should raise a Py3K warning In-Reply-To: <1205782726.96.0.925182629024.issue2357@psf.upfronthosting.co.za> Message-ID: <1205882058.64.0.737128860539.issue2357@psf.upfronthosting.co.za> Jeff Balogh added the comment: Attaching a patch that provides fixers for sys.exc_ {type,value,traceback} Added file: http://bugs.python.org/file9749/issue2357.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 00:33:47 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 18 Mar 2008 23:33:47 +0000 Subject: [issue2354] cmp argument to list.sort()/sorted() should raise a Py3K warning In-Reply-To: <1205782211.6.0.934088370296.issue2354@psf.upfronthosting.co.za> Message-ID: <1205883227.74.0.937099288875.issue2354@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Checked-in r61576 ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 00:35:16 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 18 Mar 2008 23:35:16 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205883316.17.0.28673028807.issue2349@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Back to Brett for application. ---------- assignee: rhettinger -> brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 00:40:20 2008 From: report at bugs.python.org (Michael Bishop) Date: Tue, 18 Mar 2008 23:40:20 +0000 Subject: [issue2411] test_nis.py fails if NIS is not configured or used In-Reply-To: <1205883619.98.0.282650884339.issue2411@psf.upfronthosting.co.za> Message-ID: <1205883619.98.0.282650884339.issue2411@psf.upfronthosting.co.za> New submission from Michael Bishop : Instead of failing the test which is inaccurate, the test will return that it was skipped and what the msg is. ---------- components: Tests files: test_nis.patch keywords: patch messages: 64016 nosy: MichaelBishop severity: normal status: open title: test_nis.py fails if NIS is not configured or used type: behavior versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9750/test_nis.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 00:42:18 2008 From: report at bugs.python.org (Eric Smith) Date: Tue, 18 Mar 2008 23:42:18 +0000 Subject: [issue2412] Check 2to3 for support of print function. In-Reply-To: <1205883738.38.0.0352891857591.issue2412@psf.upfronthosting.co.za> Message-ID: <1205883738.38.0.0352891857591.issue2412@psf.upfronthosting.co.za> New submission from Eric Smith : Issue 1633807 is a backport of the print function to 2.6, using a __future__ import. Once it is committed, we need to ensure that 2to3 does the right thing (namely, nothing) with print functions in modules that have the __future__ import. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 64017 nosy: collinwinter, eric.smith priority: normal severity: normal status: open title: Check 2to3 for support of print function. type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 00:47:20 2008 From: report at bugs.python.org (Eric Smith) Date: Tue, 18 Mar 2008 23:47:20 +0000 Subject: [issue1633807] from __future__ import print_function Message-ID: <1205884040.59.0.171643302098.issue1633807@psf.upfronthosting.co.za> Eric Smith added the comment: Checked in as r61577. ---------- resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Mar 19 00:58:50 2008 From: report at bugs.python.org (Jerry Seutter) Date: Tue, 18 Mar 2008 23:58:50 +0000 Subject: [issue2407] warnings.filterwarnings() not isolated between tests In-Reply-To: <1205873804.14.0.137963727485.issue2407@psf.upfronthosting.co.za> Message-ID: <1205884730.16.0.398705813001.issue2407@psf.upfronthosting.co.za> Jerry Seutter added the comment: Improved version of the patch that uses context manager to restore old warning state Added file: http://bugs.python.org/file9751/warnings_fix_v2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 01:08:25 2008 From: report at bugs.python.org (Brett Cannon) Date: Wed, 19 Mar 2008 00:08:25 +0000 Subject: [issue2411] test_nis.py fails if NIS is not configured or used In-Reply-To: <1205883619.98.0.282650884339.issue2411@psf.upfronthosting.co.za> Message-ID: <1205885305.78.0.279413324971.issue2411@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 01:08:26 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Wed, 19 Mar 2008 00:08:26 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1205885306.27.0.00401345292062.issue1751@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Here is a patch against the latest trunk (r61578) that includes the accelerator module of io.BytesIO with its test suite. The patch also changes the behavior of the truncate method to imply a seek(). Please review! Added file: http://bugs.python.org/file9752/bytesio+misc-fixes-3.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 01:35:14 2008 From: report at bugs.python.org (Bill Janssen) Date: Wed, 19 Mar 2008 00:35:14 +0000 Subject: [issue1581] xmlrpclib.ServerProxy() doesn't use x509 data In-Reply-To: <1197315686.07.0.947605571907.issue1581@psf.upfronthosting.co.za> Message-ID: <1205886914.28.0.370132632491.issue1581@psf.upfronthosting.co.za> Bill Janssen added the comment: No test case. No provision for client validation of server certificate. ---------- resolution: -> rejected __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 02:17:26 2008 From: report at bugs.python.org (Christopher Li) Date: Wed, 19 Mar 2008 01:17:26 +0000 Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails Message-ID: <1205889446.32.0.0325104841519.issue1424152@psf.upfronthosting.co.za> Christopher Li added the comment: Hi, I am working on a patch to implement the https proxy support for urllib2. It works fine for me, but feel free to change the patch. Can any one take a look please? Thanks ---------- nosy: +chrisl Added file: http://bugs.python.org/file9753/http-tunnel-urllib _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Mar 19 02:25:22 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Mar 2008 01:25:22 +0000 Subject: [issue2413] os.strerror does not check for out of range argument In-Reply-To: <1205889895.08.0.168690164912.issue2413@psf.upfronthosting.co.za> Message-ID: <1205889922.5.0.814398434458.issue2413@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- components: +Extension Modules __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 02:28:56 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Mar 2008 01:28:56 +0000 Subject: [issue2413] os.strerror does not check for out of range argument In-Reply-To: <1205889895.08.0.168690164912.issue2413@psf.upfronthosting.co.za> Message-ID: <1205890136.79.0.08266450568.issue2413@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file9755/posix-strerror.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 02:30:18 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Mar 2008 01:30:18 +0000 Subject: [issue2413] os.strerror does not check for out of range argument In-Reply-To: <1205889895.08.0.168690164912.issue2413@psf.upfronthosting.co.za> Message-ID: <1205890218.34.0.630476855256.issue2413@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Please ignore the first patch. I don't have enough permissions to remove it. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 02:24:55 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Mar 2008 01:24:55 +0000 Subject: [issue2413] os.strerror does not check for out of range argument In-Reply-To: <1205889895.08.0.168690164912.issue2413@psf.upfronthosting.co.za> Message-ID: <1205889895.08.0.168690164912.issue2413@psf.upfronthosting.co.za> New submission from Alexander Belopolsky : ISO/ANSI C strerror indicates out of range error by setting errno, but existing code incorrectly checks for NULL return value. Attached patch (tested n Mac OS X) makes os.strerror raise ValueError for out of range argument. ---------- files: posix-strerror.diff keywords: patch messages: 64023 nosy: belopolsky severity: normal status: open title: os.strerror does not check for out of range argument type: behavior versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9754/posix-strerror.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 03:16:24 2008 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 19 Mar 2008 02:16:24 +0000 Subject: [issue2403] Add figleaf coverage metrics In-Reply-To: <1205869378.43.0.216108511876.issue2403@psf.upfronthosting.co.za> Message-ID: <1205892984.51.0.830296803464.issue2403@psf.upfronthosting.co.za> Skip Montanaro added the comment: How will this work if I use a build directory? For example, my source is in ~/src/python/trunk. In there I create a build directory. When I run it I get % pwd /Users/skip/src/python/trunk/build % ./python.exe ../Tools/coverage/coverage.py Running tests... Traceback (most recent call last): File "figleaf-latest/bin/figleaf", line 4, in figleaf.main() File "/Users/skip/src/python/trunk/build/figleaf-latest/figleaf/__init__.py", line 302, in main execfile(sys.argv[0], __main__.__dict__) IOError: [Errno 2] No such file or directory: '../../Lib/test/regrtest.py' Generating html... CANNOT OPEN: @test figleaf: HTML output written to ../../coverage I think this mode should work. I prefer not to pollute my source tree with build information. Skip ---------- nosy: +skip.montanaro __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 03:22:32 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 19 Mar 2008 02:22:32 +0000 Subject: [issue2414] Fix implicit relative imports In-Reply-To: <1205893352.87.0.586984604405.issue2414@psf.upfronthosting.co.za> Message-ID: <1205893352.87.0.586984604405.issue2414@psf.upfronthosting.co.za> New submission from Martin v. L?wis : There should be a fixer that changes from foo import bar into from .foo import bar if the import occurs in a package and foo is in the very same package. Likewise, it should change import foo to from . import foo ---------- assignee: David Wolever components: 2to3 (2.x to 3.0 conversion tool) messages: 64026 nosy: David Wolever, loewis severity: normal status: open title: Fix implicit relative imports __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 04:04:15 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 19 Mar 2008 03:04:15 +0000 Subject: [issue2415] bytes() should respect __bytes__ In-Reply-To: <1205895854.9.0.402459814747.issue2415@psf.upfronthosting.co.za> Message-ID: <1205895854.9.0.402459814747.issue2415@psf.upfronthosting.co.za> New submission from Barry A. Warsaw : The bytes() builtin should respect an __bytes__() converter if it exists. E.g. instead of >>> class Foo: ... def __bytes__(self): return b'foo' ... >>> bytes(Foo()) Traceback (most recent call last): File "", line 1, in TypeError: 'Foo' object is not iterable >>> bytes(Foo()) should return b'foo' Here's one use case. email.header.Header instances represent email headers (naturally) that conceptually are bytes, but also have a string representation. Say for example, a Subject header comes across the wire in RFC 2033 encoded utf-8. The unicode representation would be the value of the header decoded according to the RFC. The bytes representation would be the raw bytes seen on the wire. The most natural way to retrieve each representation would be >>> header = msg['subject'] >>> str(header) 'some string with non-ascii' >>> bytes(header) b'the rfc 2033 encoded raw header value' ---------- components: Interpreter Core messages: 64027 nosy: barry priority: normal severity: normal status: open title: bytes() should respect __bytes__ type: feature request versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 04:04:17 2008 From: report at bugs.python.org (Jeff Balogh) Date: Wed, 19 Mar 2008 03:04:17 +0000 Subject: [issue2409] regrtest should not just skip imports that fail In-Reply-To: <1205875348.54.0.487257679211.issue2409@psf.upfronthosting.co.za> Message-ID: <1205895857.66.0.803107594882.issue2409@psf.upfronthosting.co.za> Jeff Balogh added the comment: Attaching a patch that implements optional_import(). The only arg included from __import__ is fromfile, as it's the only one I needed to fix up the stdlib. ---------- keywords: +patch nosy: +jeff.balogh Added file: http://bugs.python.org/file9756/optional_import.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 04:26:52 2008 From: report at bugs.python.org (Jeff Balogh) Date: Wed, 19 Mar 2008 03:26:52 +0000 Subject: [issue2409] regrtest should not just skip imports that fail In-Reply-To: <1205875348.54.0.487257679211.issue2409@psf.upfronthosting.co.za> Message-ID: <1205897212.63.0.274995713079.issue2409@psf.upfronthosting.co.za> Jeff Balogh added the comment: Attaching a patch that removes ``from _winreg import *`` in test_winreg.py, which will allow usage of optional_import. Added file: http://bugs.python.org/file9757/winreg-refactor.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 04:28:46 2008 From: report at bugs.python.org (Jeff Balogh) Date: Wed, 19 Mar 2008 03:28:46 +0000 Subject: [issue2409] regrtest should not just skip imports that fail In-Reply-To: <1205875348.54.0.487257679211.issue2409@psf.upfronthosting.co.za> Message-ID: <1205897326.43.0.0389606090596.issue2409@psf.upfronthosting.co.za> Jeff Balogh added the comment: Attaching a patch that refactors the test_sunaudiodev.py imports. Added file: http://bugs.python.org/file9758/sunaudiodev-refactor.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 04:53:30 2008 From: report at bugs.python.org (Eric Smith) Date: Wed, 19 Mar 2008 03:53:30 +0000 Subject: [issue2416] % string formatting does not support %b In-Reply-To: <1205898810.27.0.827801711663.issue2416@psf.upfronthosting.co.za> Message-ID: <1205898810.27.0.827801711663.issue2416@psf.upfronthosting.co.za> New submission from Eric Smith : PEP 3127 "Integer Literal Support and Syntax" says that % string formatting should support %b. This needs to be added to both 2.6 and 3.0. It needs to support the forms %b and %#b. ---------- assignee: eric.smith components: Interpreter Core messages: 64031 nosy: eric.smith priority: normal severity: normal status: open title: % string formatting does not support %b type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 04:57:08 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 19 Mar 2008 03:57:08 +0000 Subject: [issue2409] regrtest should not just skip imports that fail In-Reply-To: <1205875348.54.0.487257679211.issue2409@psf.upfronthosting.co.za> Message-ID: <1205899028.65.0.711779875326.issue2409@psf.upfronthosting.co.za> Changes by Martin v. L?wis : Removed file: http://bugs.python.org/file9757/winreg-refactor.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 04:59:57 2008 From: report at bugs.python.org (Jeff Balogh) Date: Wed, 19 Mar 2008 03:59:57 +0000 Subject: [issue2409] regrtest should not just skip imports that fail In-Reply-To: <1205875348.54.0.487257679211.issue2409@psf.upfronthosting.co.za> Message-ID: <1205899197.55.0.856489434334.issue2409@psf.upfronthosting.co.za> Jeff Balogh added the comment: The previous winreg refactor patch didn't catch all the changes; attaching a new patch that fixes everything, with help from Trent Nelson. Added file: http://bugs.python.org/file9759/winreg-refactor.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 05:15:21 2008 From: report at bugs.python.org (David Wolever) Date: Wed, 19 Mar 2008 04:15:21 +0000 Subject: [issue2171] Add map, filter, zip to future_builtins In-Reply-To: <1203812914.42.0.434541981805.issue2171@psf.upfronthosting.co.za> Message-ID: <1205900121.07.0.772331716508.issue2171@psf.upfronthosting.co.za> David Wolever added the comment: Added to future_builtins in r61587. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 05:28:41 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 19 Mar 2008 04:28:41 +0000 Subject: [issue1811] True division of integers could be more accurate In-Reply-To: <1200115229.68.0.232140016038.issue1811@psf.upfronthosting.co.za> Message-ID: <1205900921.32.0.467265438496.issue1811@psf.upfronthosting.co.za> Terry J. Reedy added the comment: To my mind, the inaccurate result is a bug that should be fixed. Note: (3.0a3) >>> 10e40/10e39 10.0 The rationale for the division change is that (as far as reasonably possible) arithmetic operations with same values should give same result regardless of types. I have not looked at either algorithm, but if long/long started by finding divmod(), but added fractional value when remainer is non-zero instead of tossing it, exact quotients would easily be exact (unless too large). ---------- nosy: +tjreedy __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 05:30:40 2008 From: report at bugs.python.org (Jeff Balogh) Date: Wed, 19 Mar 2008 04:30:40 +0000 Subject: [issue2409] regrtest should not just skip imports that fail In-Reply-To: <1205875348.54.0.487257679211.issue2409@psf.upfronthosting.co.za> Message-ID: <1205901040.4.0.216348216906.issue2409@psf.upfronthosting.co.za> Jeff Balogh added the comment: Attaching a patch, based on the previous patches, that fixes the stdlib to use optional_import where ImportError was raised. These need testing on various platforms to make sure all the ImportErrors are caught. I'm on x86 Linux. Added file: http://bugs.python.org/file9760/issue2409.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 05:39:40 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 19 Mar 2008 04:39:40 +0000 Subject: [issue2400] from .foo import * should work In-Reply-To: <1205859225.17.0.832455218755.issue2400@psf.upfronthosting.co.za> Message-ID: <1205901580.16.0.715833561989.issue2400@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is now fixed in r61595. ---------- nosy: +loewis resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 05:45:57 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 19 Mar 2008 04:45:57 +0000 Subject: [issue2417] Integer floor division (//): small int check omitted In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za> Message-ID: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za> New submission from Terry J. Reedy : Python 3.0a3 (r30a3:61161, Mar 1 2008, 22:51:17) [MSC v.1500 32 bit (Intel)] on win32 >>> a,b=1,1//1 >>> a is b False IDLE 3.0a3 >>> a,b=1,1//1 >>> a is b True ditto for 2.5.2 interpreter On c.l.p, Duncan Booth wrote I've had a look to see why this happens: long division (and in Python 3 all integers are longs) allocates a new long to hold the result of the division so it will never use one of the preallocated 'small int' values. That maybe explains the change from 2.5 but not the difference from IDLE. More important, the small int checks are present with the other operations: >>> 1*1 is 1 True >>> 1+1 is 2 True >>> 1-1 is 0 True >>> 1**1 is 1 True so the omission with // is plausibly a bug. ---------- components: Interpreter Core messages: 64037 nosy: tjreedy severity: normal status: open title: Integer floor division (//): small int check omitted type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 05:54:53 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 19 Mar 2008 04:54:53 +0000 Subject: [issue2417] [py3k] Integer floor division (//): small int check omitted In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za> Message-ID: <1205902493.98.0.93766028587.issue2417@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: Integer floor division (//): small int check omitted -> [py3k] Integer floor division (//): small int check omitted __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 05:59:28 2008 From: report at bugs.python.org (David Wolever) Date: Wed, 19 Mar 2008 04:59:28 +0000 Subject: [issue2171] Add map, filter, zip to future_builtins In-Reply-To: <1203812914.42.0.434541981805.issue2171@psf.upfronthosting.co.za> Message-ID: <1205902768.77.0.540568717344.issue2171@psf.upfronthosting.co.za> David Wolever added the comment: Ok, checked in the last piece -- fixer for filter -- in r61598. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 06:01:30 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 19 Mar 2008 05:01:30 +0000 Subject: [issue2413] os.strerror does not check for out of range argument In-Reply-To: <1205889895.08.0.168690164912.issue2413@psf.upfronthosting.co.za> Message-ID: <1205902890.55.0.632110780201.issue2413@psf.upfronthosting.co.za> Changes by Terry J. Reedy : Removed file: http://bugs.python.org/file9754/posix-strerror.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 06:02:25 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 19 Mar 2008 05:02:25 +0000 Subject: [issue2413] os.strerror does not check for out of range argument In-Reply-To: <1205889895.08.0.168690164912.issue2413@psf.upfronthosting.co.za> Message-ID: <1205902945.96.0.288485392356.issue2413@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Removed earlier version ---------- nosy: +tjreedy __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 06:08:39 2008 From: report at bugs.python.org (Brett Cannon) Date: Wed, 19 Mar 2008 05:08:39 +0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1205903319.93.0.0068898150082.issue1631171@psf.upfronthosting.co.za> Changes by Brett Cannon : Removed file: http://bugs.python.org/file9490/c_warnings.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Mar 19 06:08:43 2008 From: report at bugs.python.org (Brett Cannon) Date: Wed, 19 Mar 2008 05:08:43 +0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1205903323.21.0.8535267528.issue1631171@psf.upfronthosting.co.za> Changes by Brett Cannon : Removed file: http://bugs.python.org/file9667/c_warnings.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Mar 19 06:14:47 2008 From: report at bugs.python.org (Brett Cannon) Date: Wed, 19 Mar 2008 05:14:47 +0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1205903687.09.0.826222688845.issue1631171@psf.upfronthosting.co.za> Brett Cannon added the comment: Attached is what I think is a completely working version of warnings implemented in a mixture of C and Python. I am not worrying about documenting the new C APIs I had to add since they are pretty specific to internal stuff. Probably should add a leading '_', but I'm tired. =) I think the fleshed out tests do a pretty good job of testing new code. Even if this patch gets held up the tests should definitely get backported as is reasonable. Assigning to Neal to review (hopefully soon). ---------- assignee: brett.cannon -> nnorwitz Added file: http://bugs.python.org/file9761/c_warnings.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Mar 19 06:16:37 2008 From: report at bugs.python.org (Paul Winkler) Date: Wed, 19 Mar 2008 05:16:37 +0000 Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za> Message-ID: <1205903797.37.0.997118223537.issue1180@psf.upfronthosting.co.za> Paul Winkler added the comment: The attached patch implements a command-line option to disable loading of $HOME/.pydistutils.cfg. After talking to Martin Loewis, I decided not to implement the override part, because if it's a one-time thing you can just pass the settings on the command line; and if you have two configurations you want to use frequently, you can just use two user accounts. The hard part was writing tests, since the existing code was untested and is environment-sensitive. See the comments in the patch re. what I still don't like about it. I would like to have a less evil test setup and teardown, but I'm going on vacation tomorrow so I won't be able to look at this again until April. ---------- keywords: +patch Added file: http://bugs.python.org/file9762/python_distutils_1180.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 06:19:28 2008 From: report at bugs.python.org (Paul Winkler) Date: Wed, 19 Mar 2008 05:19:28 +0000 Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za> Message-ID: <1205903968.54.0.356376786796.issue1180@psf.upfronthosting.co.za> Changes by Paul Winkler : Removed file: http://bugs.python.org/file9762/python_distutils_1180.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 06:20:09 2008 From: report at bugs.python.org (Paul Winkler) Date: Wed, 19 Mar 2008 05:20:09 +0000 Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za> Message-ID: <1205904009.56.0.551564324908.issue1180@psf.upfronthosting.co.za> Changes by Paul Winkler : Added file: http://bugs.python.org/file9763/python_distutils_1180.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 07:26:23 2008 From: report at bugs.python.org (Vincent Manis) Date: Wed, 19 Mar 2008 06:26:23 +0000 Subject: [issue2418] Incorrect LaTeX generated (Python 2.6a1) Message-ID: <1205907983.57.0.995961213991.issue2418@psf.upfronthosting.co.za> Changes by Vincent Manis : ---------- assignee: georg.brandl components: Documentation tools (Sphinx) nosy: georg.brandl, vmanis1 severity: normal status: open title: Incorrect LaTeX generated (Python 2.6a1) type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 07:32:54 2008 From: report at bugs.python.org (Trent Nelson) Date: Wed, 19 Mar 2008 06:32:54 +0000 Subject: [issue2290] [PATCH] Update Lib/distutils/sysconfig.py to handle x64 Windows builds living in pcbuild/amd64. In-Reply-To: <1205532747.41.0.216781617297.issue2290@psf.upfronthosting.co.za> Message-ID: <1205908374.6.0.277449716518.issue2290@psf.upfronthosting.co.za> Trent Nelson added the comment: Fixed in r61606. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 07:39:47 2008 From: report at bugs.python.org (Vincent Manis) Date: Wed, 19 Mar 2008 06:39:47 +0000 Subject: [issue2418] Incorrect LaTeX generated (Python 2.6a1) In-Reply-To: <1205908787.56.0.928957900144.issue2418@psf.upfronthosting.co.za> Message-ID: <1205908787.56.0.928957900144.issue2418@psf.upfronthosting.co.za> New submission from Vincent Manis : The LaTeX code generated by Sphinx in 2.6a1 is incorrect. Some, but not all, of the \end{Verbatim}'s come at the ends of lines, rather than on lines of their own. Here is an example, at line 435 of reference.tex. return r # error: inconsistent dedent\end{Verbatim} Each occurrence of this construction results in the `make all-pdf' failing. Also, at approximately line 42051 of library.tex, the environment classdescni is undefined. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 07:53:28 2008 From: report at bugs.python.org (Trent Nelson) Date: Wed, 19 Mar 2008 06:53:28 +0000 Subject: [issue2297] Patch for fatal stack overflow in Windows caused by -v In-Reply-To: <1205645085.91.0.398085675156.issue2297@psf.upfronthosting.co.za> Message-ID: <1205909607.94.0.697648610097.issue2297@psf.upfronthosting.co.za> Trent Nelson added the comment: Fixed in r61607, thanks for the report + patch. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 08:20:54 2008 From: report at bugs.python.org (Michael Bishop) Date: Wed, 19 Mar 2008 07:20:54 +0000 Subject: [issue2419] Remove all IRIX dependant modules from aifc module In-Reply-To: <1205911254.5.0.0435748947591.issue2419@psf.upfronthosting.co.za> Message-ID: <1205911254.5.0.0435748947591.issue2419@psf.upfronthosting.co.za> New submission from Michael Bishop : Docs say that there are IRIX only modules which are dependant on the cl module which has been removed from Py3K. ---------- components: Library (Lib) messages: 64045 nosy: MichaelBishop severity: normal status: open title: Remove all IRIX dependant modules from aifc module versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 08:21:13 2008 From: report at bugs.python.org (Michael Bishop) Date: Wed, 19 Mar 2008 07:21:13 +0000 Subject: [issue2419] Remove all IRIX dependant modules from aifc module In-Reply-To: <1205911254.5.0.0435748947591.issue2419@psf.upfronthosting.co.za> Message-ID: <1205911273.5.0.910412914103.issue2419@psf.upfronthosting.co.za> Changes by Michael Bishop : ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 08:38:54 2008 From: report at bugs.python.org (Glyph Lefkowitz) Date: Wed, 19 Mar 2008 07:38:54 +0000 Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za> Message-ID: <1205912334.16.0.15222432284.issue2375@psf.upfronthosting.co.za> Glyph Lefkowitz added the comment: I don't understand your objection. It sounds like you're objecting, but then suggesting an implementation? The line you suggest might just as easily be present in py3k's default site.py and it would work fine. As I understand it, "sites" don't need this feature, developers do. Let's say I'm working on a typical system with stock python2 and python3 packages installed. Maybe it's a multi-user system, I don't have control over site.py. Normally what I'd do to manipulate sys.path dynamically between different versions would be to install a sitecustomize.py on my one PYTHONPATH entry that detected the version and reacted appropriately. However, writing a program that is both valid python 2 and python 3 is, as I understand it, both tricky and unsupported. Will this specific case be supported so that developers don't need to have root and modify the system python in order to do 2->3 migrations? __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 08:39:32 2008 From: report at bugs.python.org (Michael Hoffman) Date: Wed, 19 Mar 2008 07:39:32 +0000 Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za> Message-ID: <1205912372.82.0.737597386505.issue1180@psf.upfronthosting.co.za> Michael Hoffman added the comment: That is up to you of course, and being able to ignore is better than nothing. But creating a new account is not really an option for everyone. On the system I would like to use this feature the most, I am not a system administrator, so I cannot create new user accounts. I maintain a directory for production use of people in my workgroup. I also maintain my own for testing and development. Thanks for your work on this patch. At least being able to use --no-user-cfg will be very helpful. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 09:00:44 2008 From: report at bugs.python.org (Georg Brandl) Date: Wed, 19 Mar 2008 08:00:44 +0000 Subject: [issue2418] Incorrect LaTeX generated (Python 2.6a1) In-Reply-To: <1205908787.56.0.928957900144.issue2418@psf.upfronthosting.co.za> Message-ID: <1205913644.77.0.676521472745.issue2418@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r61617. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 09:04:55 2008 From: report at bugs.python.org (Vincent Manis) Date: Wed, 19 Mar 2008 08:04:55 +0000 Subject: [issue2418] Incorrect LaTeX generated (Python 2.6a1) In-Reply-To: <1205913644.77.0.676521472745.issue2418@psf.upfronthosting.co.za> Message-ID: <0EE92179-4467-4EA6-BF24-8C90C4465654@telus.net> Vincent Manis added the comment: On 2008 Mar 19, at 01:00, Georg Brandl wrote: > > > Georg Brandl added the comment: > > Thanks, fixed in r61617. Wow, that was fast :-) -- v __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 09:50:47 2008 From: report at bugs.python.org (Leszek Dubiel) Date: Wed, 19 Mar 2008 08:50:47 +0000 Subject: [issue2420] Faq 4.28 -- Trailing comas In-Reply-To: <1205916647.4.0.701365283019.issue2420@psf.upfronthosting.co.za> Message-ID: <1205916647.4.0.701365283019.issue2420@psf.upfronthosting.co.za> New submission from Leszek Dubiel : This is after discussion on python-ideas: http://mail.python.org/pipermail/python-ideas/2008-March/001488.html I would suggest to add question 4.28 to faq. Everybody who learns Python reads that and will not ask questions about "one-element tuples". I have compiled answer from responses to my last question about one-element tuple. Question: Why python allows to put comma at the end of list? This looks ugly and seems to break common rules... Answer: There are may reasons that follow. 1. If you defined multiline dictionary d = { "A": [1, 5], "B": [6, 7], # last trailing comma is optional but good style } it would be easier to add more elements, because you don't have to care about colons -- you always put colon at the end of line and don't have to reedit other lines. It eases sorting of such lines too -- just cut line and paste above. 2. Missing comma can lead to errors that are hard to diagnose. For example: x = [ "fee", "fie" "foo", "fum" ] contains tree elements "fee", "fiefoo" and "fum". So if programmer puts comma always at the end of line he saves lots of trouble in a future. 2. Nearly all reasonable programming languages (C, C++, Java) allow for an extra trailing comma in a comma-delimited list, for consistency and to make programmatic code generation easier. So for example [1,2,3,] is intentionally correct. 3. Creating one-element tuples using tuple(['hello']) syntax is much much slower (a factor of 20x here) then writing just ('hello', ). Trailing commas when you only have one item are how python tuple syntax is defined allowing them to use commas instead of needing other tokens. If python didn't allow comma at the end of tuple, you will have to use such slow syntax. 4. The same rule applies to other type of lists, where delimiter can occur at the end. For example both strings "alfa\nbeta\n" and "alfa\nbeta" contain two lines. Sources: -- http://mail.python.org/pipermail/python-list/2003-October/231419.html -- http://mail.python.org/pipermail/python-ideas/2008-March/001478.html -- http://mail.python.org/pipermail/python-ideas/2008-March/001475.html ---------- assignee: georg.brandl components: Documentation messages: 64050 nosy: dubiel, georg.brandl severity: normal status: open title: Faq 4.28 -- Trailing comas __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 10:31:19 2008 From: report at bugs.python.org (Duncan Booth) Date: Wed, 19 Mar 2008 09:31:19 +0000 Subject: [issue2417] [py3k] Integer floor division (//): small int check omitted In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za> Message-ID: <1205919079.72.0.395180610681.issue2417@psf.upfronthosting.co.za> Changes by Duncan Booth : ---------- nosy: +duncanb __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 11:11:49 2008 From: report at bugs.python.org (Tim Golden) Date: Wed, 19 Mar 2008 10:11:49 +0000 Subject: [issue2421] doc\make.bat fails for htmlhelp because of hardcoded filename In-Reply-To: <1205921508.97.0.101247618577.issue2421@psf.upfronthosting.co.za> Message-ID: <1205921508.97.0.101247618577.issue2421@psf.upfronthosting.co.za> New submission from Tim Golden : doc\make.bat, used to build the docs under Windows, retains the hardcoded pydoc.hhp name when building htmlhelp. Now that the help files are built as .chm this file no longer exists and the build fails. The attached patch to make.bat builds the htmlhelp from within a temporary Python session which picks the correct filename up from conf.py. ---------- assignee: georg.brandl components: Documentation tools (Sphinx) files: doc-make-r61620.patch keywords: patch messages: 64051 nosy: georg.brandl, tim.golden severity: normal status: open title: doc\make.bat fails for htmlhelp because of hardcoded filename type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9764/doc-make-r61620.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 12:11:09 2008 From: report at bugs.python.org (James Henstridge) Date: Wed, 19 Mar 2008 11:11:09 +0000 Subject: [issue2422] Automatically disable pymalloc when running under valgrind In-Reply-To: <1205925069.41.0.603933745456.issue2422@psf.upfronthosting.co.za> Message-ID: <1205925069.41.0.603933745456.issue2422@psf.upfronthosting.co.za> New submission from James Henstridge : When I want to use valgrind to check for leaks in a Python program (or test suite), I generally want pymalloc disabled. When not running valgrind I generally want it enabled. Attached is a patch that automatically bypasses the pymalloc code when running under valgrind but leaves it enabled overwise. It is controlled by a WITH_VALGRIND #define, but I haven't updated the configure script to allow turning it on. I also haven't done much in the way of profiling to see what the overhead is when not running under valgrind. ---------- components: Interpreter Core files: disable-pymalloc-on-valgrind.patch keywords: patch messages: 64052 nosy: jamesh severity: normal status: open title: Automatically disable pymalloc when running under valgrind type: feature request versions: Python 2.5 Added file: http://bugs.python.org/file9765/disable-pymalloc-on-valgrind.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 12:26:46 2008 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 19 Mar 2008 11:26:46 +0000 Subject: [issue2403] Add figleaf coverage metrics In-Reply-To: <1205869378.43.0.216108511876.issue2403@psf.upfronthosting.co.za> Message-ID: <18400.61909.727564.114013@montanaro-dyndns-org.local> Skip Montanaro added the comment: I gave this a try. It seems to not report on many files. For example, test_csv was run and passed, but there is no html file in the coverage directory with "csv" in its name after figleaf2html is run. Nor is there a key in the pickled dictionary in the .figleaf file which includes the string "csv". Skip __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 14:12:29 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 19 Mar 2008 13:12:29 +0000 Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za> Message-ID: <1205932349.64.0.67605620481.issue1180@psf.upfronthosting.co.za> Martin v. L?wis added the comment: We thought that the added value for specifying another configuration file is relatively minor: if you have to set command line options anyway, just put anything you want to specify on the command line, rather than into the other configuration file. Out of curiosity: what kinds of settings do you put into the configuration file? __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 14:38:58 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 19 Mar 2008 13:38:58 +0000 Subject: [issue2073] asynchat push always sends 512 bytes (ignoring ac_out_buffer_size) In-Reply-To: <1202768252.75.0.386707250967.issue2073@psf.upfronthosting.co.za> Message-ID: <1205933938.03.0.975872293215.issue2073@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: As discussed on python-dev patch #1736190 should be committed before doing anything against asyncore or asynchat. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 14:58:30 2008 From: report at bugs.python.org (Chris Morgan) Date: Wed, 19 Mar 2008 13:58:30 +0000 Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails Message-ID: <1205935110.1.0.232056930052.issue1424152@psf.upfronthosting.co.za> Changes by Chris Morgan : ---------- nosy: +mihalis68 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Mar 19 15:06:56 2008 From: report at bugs.python.org (Michael Hoffman) Date: Wed, 19 Mar 2008 14:06:56 +0000 Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za> Message-ID: <1205935616.45.0.818487593722.issue1180@psf.upfronthosting.co.za> Michael Hoffman added the comment: Here's an example of a configuration file I use: ==== [build_ext] include_dirs = /nfs/acari/mh5/include/python2.5:/nfs/acari/mh5/include [install] prefix = ~ exec_prefix = ~/arch/$ARCH install_platlib = $platbase/lib/python$py_version_short install_purelib = $base/lib/python$py_version_short install_scripts = $platbase/bin [easy_install] install_dir = $platbase/lib/python$py_version_short script_dir = $platbase/bin ==== I am installing software on a filesystem that is shared between different architectures (i386 and x86_64), so I must have separate directories for extensions on each platform. Because of this, using --home=~ doesn't cut it. I don't want to be a pain, if the --no-user-cfg can go in sooner, that would be very helpful. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 15:47:25 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Mar 2008 14:47:25 +0000 Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za> Message-ID: <1205938045.8.0.378349133471.issue2375@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > I don't understand your objection. > It sounds like you're objecting, but > then suggesting an implementation? This sounds like a kludge addressing a transient problem. It also feels like a solution catering to developers at the expense of user confusion: 1. Why is there PYTHON3PATH, but not PYTHON2PATH? 2. Is PYTHONPATH effectively PYTHON2PATH or PYTHON1PATH? 3. Will PYTHON3PATH be supported forever or deprecated once 2.8 and 3.2 are close enough to support a large common code base? There are many ways to address multi-python site issues. PYTHONPATH is too indiscriminate for some uses. When more fine-grained differentiation between 3.x and 2.x files is needed, a better approach would be a custom loader in metapath that can look for version specific file extensions. I would suggest to wait until there are enough reports from the field on different solutions in actual use before selecting one to standardize on. [I have to mention that perl 5 uses PERL5PATH, but I am not sure whether it is an argument for or against PYTHON3PATH. Can anyone report on pros and cons of PERL5PATH from actual experience?] __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 15:50:50 2008 From: report at bugs.python.org (Jerry Seutter) Date: Wed, 19 Mar 2008 14:50:50 +0000 Subject: [issue2423] test_smtplib.py no longer butt slow In-Reply-To: <1205938249.95.0.187788140387.issue2423@psf.upfronthosting.co.za> Message-ID: <1205938249.95.0.187788140387.issue2423@psf.upfronthosting.co.za> New submission from Jerry Seutter : Changes only affect test files. test_smtplib.py before: 39.7s test_smtplib.py after: 0.8s socket.getfqdn() calls were causing all the slowness. Added a mock_socket.py file to handle some tests. For other tests that tested both server side and client side of the smtp libraries, mocked out socket.getfqdn() only. ---------- components: Tests files: test_smtplib_speedup.patch keywords: patch, patch messages: 64058 nosy: jseutter priority: low severity: normal status: open title: test_smtplib.py no longer butt slow type: performance versions: Python 2.6 Added file: http://bugs.python.org/file9766/test_smtplib_speedup.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 15:51:50 2008 From: report at bugs.python.org (Jerry Seutter) Date: Wed, 19 Mar 2008 14:51:50 +0000 Subject: [issue2423] test_smtplib.py no longer butt slow In-Reply-To: <1205938249.95.0.187788140387.issue2423@psf.upfronthosting.co.za> Message-ID: <1205938310.07.0.253442276144.issue2423@psf.upfronthosting.co.za> Changes by Jerry Seutter : Added file: http://bugs.python.org/file9767/mock_socket.py __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 15:52:38 2008 From: report at bugs.python.org (Wolfgang Langner) Date: Wed, 19 Mar 2008 14:52:38 +0000 Subject: [issue2078] CSV Sniffer does not function properly on single column .csv files In-Reply-To: <1202832132.24.0.528453630912.issue2078@psf.upfronthosting.co.za> Message-ID: <1205938358.28.0.444647812564.issue2078@psf.upfronthosting.co.za> Wolfgang Langner added the comment: In this cases it is not really possible to sniff the right delimiter. To not allow digits or letters is not a good solution. I think the behavior as now is ok, and at this time I see now way to improve it. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 16:13:37 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Mar 2008 15:13:37 +0000 Subject: [issue2417] [py3k] Integer floor division (//): small int check omitted In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za> Message-ID: <1205939617.83.0.198938392711.issue2417@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I agree this is a bug. Here is a related problem: >>> 1 is divmod(1,1)[0] False ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 16:32:56 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 19 Mar 2008 15:32:56 +0000 Subject: [issue2415] bytes() should respect __bytes__ In-Reply-To: <1205895854.9.0.402459814747.issue2415@psf.upfronthosting.co.za> Message-ID: <1205940776.15.0.322911945723.issue2415@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I took a quick glance at this. It hinges on how the C-API is going to look. Currently, bytes is known in C as PyString and gets it's representation from __str__. Although we could just change it to __bytes__, Christian has said that he is going to rename it to PyBytes (and what is now PyBytes -> PyByteArray). [1] Further muddying the waters is the fact that PyObject_Str generates the unicode representation of an object and should really be called PyObject_Unicode. [1] http://mail.python.org/pipermail/python-3000/2008-March/012477.html ---------- nosy: +benjamin.peterson, tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 16:33:20 2008 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 19 Mar 2008 15:33:20 +0000 Subject: [issue2078] CSV Sniffer does not function properly on single column .csv files In-Reply-To: <1205938358.28.0.444647812564.issue2078@psf.upfronthosting.co.za> Message-ID: <18401.12828.469239.657721@montanaro-dyndns-org.local> Skip Montanaro added the comment: Wolfgang> In this cases it is not really possible to sniff the right Wolfgang> delimiter. To not allow digits or letters is not a good Wolfgang> solution. I think the behavior as now is ok, and at this time Wolfgang> I see now way to improve it. I mostly agree. I'm waiting for the original submitter to chime in though. Skip __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 16:49:49 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Mar 2008 15:49:49 +0000 Subject: [issue2417] [py3k] Integer floor division (//): small int check omitted In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za> Message-ID: <1205941789.87.0.931124406551.issue2417@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: >>> int('1') is 1 False >>> 1 is int('0b1', 2) False >>> 1 is 0b10000 >> 4 False there are probably more ... __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 16:57:46 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Mar 2008 15:57:46 +0000 Subject: [issue2417] [py3k] Integer floor division (//): small int check omitted In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za> Message-ID: <1205942266.14.0.0428201213737.issue2417@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: >>> 1 is 1|1 False >>> 1 is 1&1 False >>> 0 is 1^1 False >>> 2 is 1<<1 False __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 17:06:27 2008 From: report at bugs.python.org (Facundo Batista) Date: Wed, 19 Mar 2008 16:06:27 +0000 Subject: [issue2417] [py3k] Integer floor division (//): small int check omitted In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za> Message-ID: <1205942787.07.0.863478943157.issue2417@psf.upfronthosting.co.za> Facundo Batista added the comment: I really don't understand *why* it's a bug. Is anywhere in the Language Reference that says that 1 should be the same object that another 1? Or do you mean that they *should* be the same object for speed and/or memory reasons? In this case... is this a bug? Or a request for improvement or something? ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 17:19:50 2008 From: report at bugs.python.org (Adam Olsen) Date: Wed, 19 Mar 2008 16:19:50 +0000 Subject: [issue2417] [py3k] Integer floor division (//): small int check omitted In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za> Message-ID: <1205943590.53.0.531357089518.issue2417@psf.upfronthosting.co.za> Adam Olsen added the comment: The original bug is not whether or not python reuses int objects, but rather that an existing optimization disappears under certain circumstances. Something is breaking our optimization. The later cases where the optimization is simply gone in 3.0a3 are more difficult. We don't *have* to keep them.. but we probably want them. The small int reuse happens for a reason. ---------- nosy: +Rhamphoryncus __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 17:20:25 2008 From: report at bugs.python.org (David Wolever) Date: Wed, 19 Mar 2008 16:20:25 +0000 Subject: [issue2414] Fix implicit relative imports In-Reply-To: <1205893352.87.0.586984604405.issue2414@psf.upfronthosting.co.za> Message-ID: <1205943625.01.0.204492602284.issue2414@psf.upfronthosting.co.za> David Wolever added the comment: Added in r61626. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 17:30:39 2008 From: report at bugs.python.org (David Wolever) Date: Wed, 19 Mar 2008 16:30:39 +0000 Subject: [issue2412] Check 2to3 for support of print function. In-Reply-To: <1205883738.38.0.0352891857591.issue2412@psf.upfronthosting.co.za> Message-ID: <1205944239.26.0.0442094927695.issue2412@psf.upfronthosting.co.za> Changes by David Wolever : ---------- assignee: collinwinter -> David Wolever nosy: +David Wolever __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 17:50:28 2008 From: report at bugs.python.org (Brett Cannon) Date: Wed, 19 Mar 2008 16:50:28 +0000 Subject: [issue2411] test_nis.py fails if NIS is not configured or used In-Reply-To: <1205883619.98.0.282650884339.issue2411@psf.upfronthosting.co.za> Message-ID: <1205945428.57.0.301576745359.issue2411@psf.upfronthosting.co.za> Brett Cannon added the comment: Applied in revision 61627. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 17:55:28 2008 From: report at bugs.python.org (Brad Allen) Date: Wed, 19 Mar 2008 16:55:28 +0000 Subject: [issue2424] Logging module hides user code errors (bare except) In-Reply-To: <1205945727.95.0.106408430921.issue2424@psf.upfronthosting.co.za> Message-ID: <1205945727.95.0.106408430921.issue2424@psf.upfronthosting.co.za> New submission from Brad Allen : The logging module contains several bare except statements. It's understandable that the logging module should be completely silent, but in the case of logging.config, the bare except can make it very difficult to identify when there is a problem with a customer handler or even with configuration. These are the offending lines (lines 133-134): except: #if an error occurs when instantiating a handler, too bad pass #this could happen e.g. because of lack of privileges Maybe this should only catch OSError, so that other problems will generate a failure at this point and show the correct traceback. My experience is that there is usually a failure anyway when there is a configuration problem, but the error is usually misleading. By the way, exceptions generated here seem to mainly occur when a Python script is first starting up, as it involves the initial configuration. I am not convinced that the logging module should be silent at that stage. ---------- components: Library (Lib) messages: 64069 nosy: bradallen severity: normal status: open title: Logging module hides user code errors (bare except) type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 17:56:34 2008 From: report at bugs.python.org (Brad Allen) Date: Wed, 19 Mar 2008 16:56:34 +0000 Subject: [issue2424] Logging module hides user code errors (bare except) In-Reply-To: <1205945727.95.0.106408430921.issue2424@psf.upfronthosting.co.za> Message-ID: <1205945794.31.0.207683969218.issue2424@psf.upfronthosting.co.za> Brad Allen added the comment: in the previous post, please replace the word 'customer' with the word 'user' __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 18:04:43 2008 From: report at bugs.python.org (Jack Diederich) Date: Wed, 19 Mar 2008 17:04:43 +0000 Subject: [issue2346] Py3K warn against using __members__ In-Reply-To: <1205781355.97.0.143101300316.issue2346@psf.upfronthosting.co.za> Message-ID: <1205946283.7.0.848666480072.issue2346@psf.upfronthosting.co.za> Jack Diederich added the comment: This patch raises a py3k warning from inside the dir() machinery so it will only warn when dir() is called on an object with an old style __members__ or __methods__ attribute. It does not warn if there is an old style __members__ attribute that is not used. ---------- assignee: -> jackdied keywords: +patch nosy: +jackdied Added file: http://bugs.python.org/file9768/methods_members.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 18:14:44 2008 From: report at bugs.python.org (Jeff Balogh) Date: Wed, 19 Mar 2008 17:14:44 +0000 Subject: [issue2354] cmp argument to list.sort()/sorted() should raise a Py3K warning In-Reply-To: <1205782211.6.0.934088370296.issue2354@psf.upfronthosting.co.za> Message-ID: <1205946884.71.0.64477150705.issue2354@psf.upfronthosting.co.za> Jeff Balogh added the comment: Fixing the compare to raise the warning when cmp != NULL, and adding a test ---------- keywords: +patch nosy: +jeff.balogh Added file: http://bugs.python.org/file9769/sort-cmp.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 18:18:33 2008 From: report at bugs.python.org (Jeff Balogh) Date: Wed, 19 Mar 2008 17:18:33 +0000 Subject: [issue2425] test_py3kwarn doesn't use sys.py3kwarning In-Reply-To: <1205947113.11.0.403203872341.issue2425@psf.upfronthosting.co.za> Message-ID: <1205947113.11.0.403203872341.issue2425@psf.upfronthosting.co.za> New submission from Jeff Balogh : This patch fixes the TODO in test_py3kwarn ---------- components: Tests files: py3kwarn-refactor.diff keywords: patch messages: 64073 nosy: brett.cannon, jeff.balogh severity: normal status: open title: test_py3kwarn doesn't use sys.py3kwarning versions: Python 2.6 Added file: http://bugs.python.org/file9770/py3kwarn-refactor.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 18:26:21 2008 From: report at bugs.python.org (Paul Kippes) Date: Wed, 19 Mar 2008 17:26:21 +0000 Subject: [issue2426] pysqlite provides no interface for database SQL dump In-Reply-To: <1205947581.08.0.648809036566.issue2426@psf.upfronthosting.co.za> Message-ID: <1205947581.08.0.648809036566.issue2426@psf.upfronthosting.co.za> New submission from Paul Kippes : Without the command line interface to sqlite3, there is no easy method of extracting a database into an SQL dump file. This creates a problem should a user want to create an in-memory database (which is useful for a performance boost) and then save the data for later use. It also would be useful should the sqlite3 command not be installed. The attached patch implements this feature as a method of the Connection class. ---------- components: Extension Modules, Library (Lib) files: sqlite_dump_addition.r61630.patch keywords: patch messages: 64074 nosy: kippesp severity: normal status: open title: pysqlite provides no interface for database SQL dump type: feature request versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9771/sqlite_dump_addition.r61630.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 18:34:01 2008 From: report at bugs.python.org (Brett Cannon) Date: Wed, 19 Mar 2008 17:34:01 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205948041.64.0.270055410767.issue2349@psf.upfronthosting.co.za> Brett Cannon added the comment: Actually, the patch is incomplete. You can still do assignment through things such as ``def True(): pass``. If you go through ast.c and find the various places None is protected (search for \"None\" and note the places where an ast_error() call is made) you should put the warnings there. ---------- resolution: accepted -> __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 18:38:07 2008 From: report at bugs.python.org (Brett Cannon) Date: Wed, 19 Mar 2008 17:38:07 +0000 Subject: [issue2425] test_py3kwarn doesn't use sys.py3kwarning In-Reply-To: <1205947113.11.0.403203872341.issue2425@psf.upfronthosting.co.za> Message-ID: <1205948287.21.0.664783995241.issue2425@psf.upfronthosting.co.za> Brett Cannon added the comment: Fixed in revision 61631. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 18:39:10 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 19 Mar 2008 17:39:10 +0000 Subject: [issue2348] Py3K warn using file.softspace In-Reply-To: <1205781454.44.0.267838748773.issue2348@psf.upfronthosting.co.za> Message-ID: <1205948350.52.0.385917216661.issue2348@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I have a few comments: 1) Please use PyErr_WarnEx. 2) Please add tests to Lib/test/test_py3kwarn.py ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 18:45:42 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 19 Mar 2008 17:45:42 +0000 Subject: [issue2354] cmp argument to list.sort()/sorted() should raise a Py3K warning In-Reply-To: <1205782211.6.0.934088370296.issue2354@psf.upfronthosting.co.za> Message-ID: <1205948742.41.0.427669445797.issue2354@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Doh! Fixed in r61632 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 19:04:57 2008 From: report at bugs.python.org (Brett Cannon) Date: Wed, 19 Mar 2008 18:04:57 +0000 Subject: [issue2090] __import__ with fromlist=[''] causes double initialization of modules In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za> Message-ID: <1205949897.65.0.41172281799.issue2090@psf.upfronthosting.co.za> Brett Cannon added the comment: As you said, it's a hack, so supporting an abuse of the API is not reasonable. You don't have to set the fromlist for the import to work. And if you are doing it to get the tail module, you can write some simple code to use getattr() to walk down from the root module to the one you want. And I plan to add a much simpler API to the imp module for people to use directly so that these abuses don't continue. ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 19:13:23 2008 From: report at bugs.python.org (Georg Brandl) Date: Wed, 19 Mar 2008 18:13:23 +0000 Subject: [issue2421] doc\make.bat fails for htmlhelp because of hardcoded filename In-Reply-To: <1205921508.97.0.101247618577.issue2421@psf.upfronthosting.co.za> Message-ID: <1205950403.0.0.144801945665.issue2421@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: georg.brandl -> tiran nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 19:27:35 2008 From: report at bugs.python.org (hauser) Date: Wed, 19 Mar 2008 18:27:35 +0000 Subject: [issue2090] __import__ with fromlist=[''] causes double initialization of modules In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za> Message-ID: <1205951255.37.0.0431242420316.issue2090@psf.upfronthosting.co.za> hauser added the comment: There are quite a few projects that use this solution: http://google.com/codesearch?hl=en&lr=&q=__import__.*%5C%5B%27%27%5C%5D . I would change it even if it is a hack, but I understand your point. ---------- versions: +Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 19:33:56 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 19 Mar 2008 18:33:56 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205951636.16.0.667281024732.issue2349@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Wow! I never realized how many ways you could possibly assign to something. I found all the None assignments and put the True/False ones under it. Added file: http://bugs.python.org/file9772/bool_assign3.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 19:34:17 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 19 Mar 2008 18:34:17 +0000 Subject: [issue2426] pysqlite provides no interface for database SQL dump In-Reply-To: <1205947581.08.0.648809036566.issue2426@psf.upfronthosting.co.za> Message-ID: <1205951657.16.0.647149454458.issue2426@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 19:47:03 2008 From: report at bugs.python.org (Jack Diederich) Date: Wed, 19 Mar 2008 18:47:03 +0000 Subject: [issue2357] sys.exc_{type, values, traceback} should raise a Py3K warning In-Reply-To: <1205782726.96.0.925182629024.issue2357@psf.upfronthosting.co.za> Message-ID: <1205952423.62.0.465682291794.issue2357@psf.upfronthosting.co.za> Jack Diederich added the comment: Fixer patch works for me (both must be applied). A 3k warning for accessing is harder - it would have to copy the module type or dict type and supply a custom to_getattro that watches for accesses to exc_(type|values|traceback). I'll look into it. ---------- nosy: +jackdied __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 19:50:18 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 19 Mar 2008 18:50:18 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205952618.37.0.452402615734.issue2349@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I just added on a test. Added file: http://bugs.python.org/file9773/bool_assign4.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 19:52:18 2008 From: report at bugs.python.org (Facundo Batista) Date: Wed, 19 Mar 2008 18:52:18 +0000 Subject: [issue1152248] Enhance file.readlines by making line separator selectable Message-ID: <1205952738.16.0.24027049769.issue1152248@psf.upfronthosting.co.za> Facundo Batista added the comment: I took a look at it... It's not as not-complicated as I original thought. The way would be to adapt the Py_UniversalNewlineFread() function to *not* process the normal separators (like \n or \r), but the passed one. A critical point would be to handle more-than-1-byte characters... I concur with Nick that this would better suited for Py3k. So, I'm stepping down from this, and flagging it for that version. ---------- assignee: facundobatista -> versions: +Python 3.0 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Mar 19 19:56:58 2008 From: report at bugs.python.org (Jeff Balogh) Date: Wed, 19 Mar 2008 18:56:58 +0000 Subject: [issue2358] Using sys.exc_clear should raise a Py3K warning In-Reply-To: <1205782771.08.0.305016984378.issue2358@psf.upfronthosting.co.za> Message-ID: <1205953018.77.0.545544686529.issue2358@psf.upfronthosting.co.za> Changes by Jeff Balogh : Removed file: http://bugs.python.org/file9707/issue2358.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 20:04:10 2008 From: report at bugs.python.org (David Wolever) Date: Wed, 19 Mar 2008 19:04:10 +0000 Subject: [issue2412] Check 2to3 for support of print function. In-Reply-To: <1205883738.38.0.0352891857591.issue2412@psf.upfronthosting.co.za> Message-ID: <1205953450.08.0.36777684094.issue2412@psf.upfronthosting.co.za> David Wolever added the comment: I've updated the fixer (checkin to come shortly), but 2to3 gets upset when you it comes across print statements with kwargs (eg: print("spam", end=" ")), so the tests will be commented out 'till this is fixed. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 20:09:51 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 19 Mar 2008 19:09:51 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205953791.31.0.769483282833.issue2349@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I don't think it's important to catch every possible assignment. Add warnings for the common cases and declare victory. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 20:18:16 2008 From: report at bugs.python.org (David Wolever) Date: Wed, 19 Mar 2008 19:18:16 +0000 Subject: [issue2412] Check 2to3 for support of print function. In-Reply-To: <1205883738.38.0.0352891857591.issue2412@psf.upfronthosting.co.za> Message-ID: <1205954296.47.0.231403344163.issue2412@psf.upfronthosting.co.za> David Wolever added the comment: As of r61635, the fix_print fixer has been fixed and tests have been added (which will ``assert False`` when 2to3 is fixed so it can handle ``print(**kwargs)``). ---------- assignee: David Wolever -> collinwinter __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 20:22:46 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 19 Mar 2008 19:22:46 +0000 Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217 In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za> Message-ID: <1205954566.96.0.305895318869.issue2054@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: > This is a straightforward implementation of client-side use of SSL, > but it's missing a test case for evaluation. It should include a > patch to test_ftplib to test it. I'm not sure how it could be tested, since we don't have an FTPS server to test against. The current test suite itself only tests the new timeout feature added in ftplib.FTP class in Python 2.6 and nothing else. > Another thing to look at is what the useful arguments are to pass in > for TLS usage over FTP. If, for example, the client needs to validate > the server's certificate or identity, provision should be made for a > file of cacerts to be passed to the FTP_TLS instance. Passing in a > keyfile and certfile is usually only necessary when the client uses > them to identify itself to the server. I drew from the SSL classes defined in httplib, imaplib, poplib, smtplib and urllib modules which accept a keyfile and a certfile in the class constructor so I thought it was the "right way". Is there a reason why the FTP protocol should behave differently as you have described? > In FTP_TLS.__init__ you call FTP.__init__. The latter in turn calls > FTP.login if a username is supplied. Thus you end up trying to login > before issuing the AUTH TLS command. The result is, that username and > passwords are send unencrypted. Or do I miss a subtle trick here? You're right, I avoided doing that since the TLS encryption should be requested specifically by the user. We could implicitly secure the control connection if the "user" argument is provided when invoking the class constructor and eventually add a "secure" kwarg to login method that defaults to True. > The lib should give programmer choice wether to send login through TLS > or not. (as it is described in RFC 4217). This is what it does if you use auth_tls() before login(). > Also, there should be an optional parameter to specify port for ftp > connection. This is already possible by using the original (inherited) connect() method. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 20:33:18 2008 From: report at bugs.python.org (Jeff Balogh) Date: Wed, 19 Mar 2008 19:33:18 +0000 Subject: [issue2348] Py3K warn using file.softspace In-Reply-To: <1205781454.44.0.267838748773.issue2348@psf.upfronthosting.co.za> Message-ID: <1205955198.7.0.739713753753.issue2348@psf.upfronthosting.co.za> Changes by Jeff Balogh : Removed file: http://bugs.python.org/file9717/issue2348.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 20:33:21 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 19 Mar 2008 19:33:21 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205955201.84.0.812755463297.issue2349@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Do you think we should remove some? __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 20:33:32 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 19 Mar 2008 19:33:32 +0000 Subject: [issue2417] [py3k] Integer floor division (//): small int check omitted In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za> Message-ID: <1205955212.29.0.862873735175.issue2417@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree that this is not a bug in the strict sense. I could have selected Type: resource usage (for memory increase). But the change of behavior is also visible. I suspect the change is not intentional both because of the pattern and because of recent discussion on PyDev that small int caching should be kept. If the precise change is intentional, this should be documented (here) to answer further questions on c.l.p. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 20:34:47 2008 From: report at bugs.python.org (Jeff Balogh) Date: Wed, 19 Mar 2008 19:34:47 +0000 Subject: [issue2348] Py3K warn using file.softspace In-Reply-To: <1205781454.44.0.267838748773.issue2348@psf.upfronthosting.co.za> Message-ID: <1205955287.59.0.0455688325398.issue2348@psf.upfronthosting.co.za> Jeff Balogh added the comment: Here's a new patch that uses PyErr_WarnEx, has a test, and even updates Misc/NEWS. Added file: http://bugs.python.org/file9774/issue2348.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 20:34:54 2008 From: report at bugs.python.org (Bruce Frederiksen) Date: Wed, 19 Mar 2008 19:34:54 +0000 Subject: [issue2427] 2to3 should translate itertools.imap into generator expression, not list comprehension In-Reply-To: <1205955294.72.0.717480464196.issue2427@psf.upfronthosting.co.za> Message-ID: <1205955294.72.0.717480464196.issue2427@psf.upfronthosting.co.za> New submission from Bruce Frederiksen : 2to3, svn rev 61623 translates itertools.imap(lambda x: ..., ...) into a list comprehension. This should be translated instead into a generator expression so that doing itertools.imap on infinite iterators still works. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 64092 nosy: collinwinter, dangyogi severity: normal status: open title: 2to3 should translate itertools.imap into generator expression, not list comprehension type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 21:19:52 2008 From: report at bugs.python.org (Bill Janssen) Date: Wed, 19 Mar 2008 20:19:52 +0000 Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217 In-Reply-To: <1205954566.96.0.305895318869.issue2054@psf.upfronthosting.co.za> Message-ID: <4b3e516a0803191319i248ace4fm1773c3590ac6fb89@mail.gmail.com> Bill Janssen added the comment: As you point out, the other classes should be fixed. The old client-side protocol was never very well thought out, IMHO. Continuing to propagate it would be a mistake. Bill On Wed, Mar 19, 2008 at 12:22 PM, Giampaolo Rodola' wrote: > > Giampaolo Rodola' added the comment: > > Another thing to look at is what the useful arguments are to pass in > > for TLS usage over FTP. If, for example, the client needs to validate > > the server's certificate or identity, provision should be made for a > > file of cacerts to be passed to the FTP_TLS instance. Passing in a > > keyfile and certfile is usually only necessary when the client uses > > them to identify itself to the server. > > I drew from the SSL classes defined in httplib, imaplib, poplib, smtplib > and urllib modules which accept a keyfile and a certfile in the class > constructor so I thought it was the "right way". Is there a reason why > the FTP protocol should behave differently as you have described? > Added file: http://bugs.python.org/file9775/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080319/ab308f85/attachment.txt From report at bugs.python.org Wed Mar 19 21:28:30 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 19 Mar 2008 20:28:30 +0000 Subject: [issue2427] 2to3 should translate itertools.imap into generator expression, not list comprehension In-Reply-To: <1205955294.72.0.717480464196.issue2427@psf.upfronthosting.co.za> Message-ID: <1205958510.49.0.456217444197.issue2427@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Why isn't itertools.imap() being translated directly to builtins.map()? ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 21:32:24 2008 From: report at bugs.python.org (Glyph Lefkowitz) Date: Wed, 19 Mar 2008 20:32:24 +0000 Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za> Message-ID: <1205958744.83.0.0251256813186.issue2375@psf.upfronthosting.co.za> Glyph Lefkowitz added the comment: The idea is that PYTHON3PATH will be honored in preference to PYTHONPATH, but PYTHONPATH will still be honored. It's exposed only to people who specifically need it. However, I think it's misleading to call the Python 3 transition a "transient" problem. If we're lucky, it's going to be a decade of slow progress. If we're not, it will never end. Try, for example, compiling your system C library without "gets", and see what happens. (And that's been an issue for more than 10 years!) The biggest way to shorten this problem is to provide tools and idioms for developers to use when porting. Specifically like this feature. As far as "version specific file extensions" - I'd be very happy with that but Guido has said several times that he doesn't like it. Feel free to discuss that with him, but this change is far less invasive. Users who don't need it will simply never know about it. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 21:45:16 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 19 Mar 2008 20:45:16 +0000 Subject: [issue2354] cmp argument to list.sort()/sorted() should raise a Py3K warning In-Reply-To: <1205782211.6.0.934088370296.issue2354@psf.upfronthosting.co.za> Message-ID: <1205959516.3.0.372495922668.issue2354@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Collin, is there some place where I should write-up how to transition sort cmp functions? Often, it is straight-forward to write a simpler key function, but sometimes it isn't obvious how to proceed (i.e. cases that have an ascending primary key and descentding secondary key or cases where a user supplied cmp function is an unchangable, exposed part of the API). I would like to issue some guidance on the subject. ---------- assignee: rhettinger -> collinwinter nosy: +collinwinter status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 21:46:52 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 19 Mar 2008 20:46:52 +0000 Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217 In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za> Message-ID: <1205959612.68.0.754299368352.issue2054@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: > As you point out, the other classes should be fixed. The old > client-side protocol was never very well thought out, IMHO. > Continuing to propagate it would be a mistake. Ok, how do you think it would have be modified? Could you provide an example or a new patch? __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 21:47:21 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Mar 2008 20:47:21 +0000 Subject: [issue2102] New style vs. old style classes __ror__() operator overloading In-Reply-To: <1202914275.65.0.0408321545289.issue2102@psf.upfronthosting.co.za> Message-ID: <1205959641.16.0.0671181353933.issue2102@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> fdrake components: +Documentation -Interpreter Core nosy: +fdrake priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 22:00:03 2008 From: report at bugs.python.org (Bruce Frederiksen) Date: Wed, 19 Mar 2008 21:00:03 +0000 Subject: [issue2428] 2to3 deletes # comments before "from __future__ import with_statement" In-Reply-To: <1205960403.35.0.278186384366.issue2428@psf.upfronthosting.co.za> Message-ID: <1205960403.35.0.278186384366.issue2428@psf.upfronthosting.co.za> New submission from Bruce Frederiksen : 2to3, svn rev 61623. To reproduce this error: $ cat < foobar.py # line 1 # line 2 from __future__ import with_statement import sys ! $ 2to3 -w foobar.py RefactoringTool: Skipping implicit fixer: buffer RefactoringTool: Skipping implicit fixer: idioms RefactoringTool: Skipping implicit fixer: ws_comma --- foobar.py (original) +++ foobar.py (refactored) @@ -1,5 +1,2 @@ -# line 1 -# line 2 -from __future__ import with_statement import sys RefactoringTool: Files that were modified: RefactoringTool: foobar.py $ cat foobar.py import sys $ ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 64098 nosy: collinwinter, dangyogi severity: normal status: open title: 2to3 deletes # comments before "from __future__ import with_statement" type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 22:05:39 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Mar 2008 21:05:39 +0000 Subject: [issue1641] asyncore delayed calls feature In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za> Message-ID: <1205960739.49.0.783838270867.issue1641@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Giampaolo: Can you pleaes bring this up on python-dev or the normal python mailing list for further discussion on the issue? ---------- assignee: -> akuchling keywords: +patch nosy: +akuchling, jafo priority: -> normal type: -> feature request __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 22:06:20 2008 From: report at bugs.python.org (Brett Cannon) Date: Wed, 19 Mar 2008 21:06:20 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1205960780.93.0.177703801695.issue2349@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: brett.cannon -> rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 22:08:53 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Mar 2008 21:08:53 +0000 Subject: [issue2113] Bad interaction between signal and subprocess In-Reply-To: <1203003543.0.0.215384363172.issue2113@psf.upfronthosting.co.za> Message-ID: <1205960933.83.0.590743546346.issue2113@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Daniele: Please provide an updated version of this patch based on the feedback below. ---------- assignee: -> gregory.p.smith keywords: +patch nosy: +gregory.p.smith, jafo priority: -> normal type: crash -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 22:12:14 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Mar 2008 21:12:14 +0000 Subject: [issue2116] weakref copy module interaction In-Reply-To: <1203024154.91.0.456074381022.issue2116@psf.upfronthosting.co.za> Message-ID: <1205961134.27.0.735049069551.issue2116@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Rick: In the future, please provide a context or unified diff ("diff -c") so that we get the file name that the diff is for and some additional context. ---------- assignee: -> tim_one keywords: +patch nosy: +jafo, tim_one priority: -> normal type: crash -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 22:15:37 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 19 Mar 2008 21:15:37 +0000 Subject: [issue1053369] ftplib: add support for MDTM command Message-ID: <1205961337.29.0.381313846542.issue1053369@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: IMHO aside from the plus of providing a workaround for a broken FTP server response I don't think this is really necessary since the same thing can be done by just using sendcmd('mdtm filename'). ---------- nosy: +giampaolo.rodola _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Mar 19 22:16:07 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Mar 2008 21:16:07 +0000 Subject: [issue2125] Read support for Records in msilib In-Reply-To: <1203093337.85.0.620181363068.issue2125@psf.upfronthosting.co.za> Message-ID: <1205961367.3.0.904381993854.issue2125@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> loewis keywords: +patch nosy: +loewis priority: -> normal title: [patch] Read support for Records in msilib -> Read support for Records in msilib __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 22:16:55 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 19 Mar 2008 21:16:55 +0000 Subject: [issue1248] ftplib needs a rewrite to use bytes/buffers In-Reply-To: <1191874324.3.0.017965594704.issue1248@psf.upfronthosting.co.za> Message-ID: <1205961415.2.0.217433774514.issue1248@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 22:25:29 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 19 Mar 2008 21:25:29 +0000 Subject: [issue1641] asyncore delayed calls feature In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za> Message-ID: <1205961929.04.0.367244699411.issue1641@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Sean, I already tried to raise two discussion attempts on both lists here: http://groups.google.com/group/python-dev2/browse_thread/thread/ecbf4d38a868d4f/ec5c7dbd40664b7f?lnk=gst&q=asyncore+giampaolo ...and here: http://groups.google.com/group/comp.lang.python/browse_thread/thread/603d6c05aa6965c0/af451aedadb75832?lnk=gst&q=delayed+call#af451aedadb75832 ...but no one seems to be interested at this feature. Moreover, before doing anything against asyncore and asynhat there are a lot of long-time pending patches which should be committed first; see here: http://groups.google.com/group/python-dev2/browse_thread/thread/eec1ddadefe09fd8/a38270231620870e?lnk=gst&q=asyncore __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 22:26:50 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Mar 2008 21:26:50 +0000 Subject: [issue1390] toxml generates output that is not well formed In-Reply-To: <1194224464.02.0.498094570041.issue1390@psf.upfronthosting.co.za> Message-ID: <1205962010.45.0.365648667091.issue1390@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Martin: What do you think of this patch? ---------- assignee: -> loewis nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 22:28:37 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Wed, 19 Mar 2008 21:28:37 +0000 Subject: [issue2413] os.strerror does not check for out of range argument In-Reply-To: <1205889895.08.0.168690164912.issue2413@psf.upfronthosting.co.za> Message-ID: <1205962117.15.0.169796240888.issue2413@psf.upfronthosting.co.za> Ralf Schmitt added the comment: my manpage (debian testing) states: POSIX.1-2001 permits strerror() to set errno if the call encounters an error, but does not specify what value should be returned as the func? tion result in the event of an error. On some systems, strerror() returns NULL if the error number is unknown. On other systems, str? error() returns a string something like "Error nnn occurred" and sets errno to EINVAL if the error number is unknown. So, I think this patch should be rejected. ---------- nosy: +schmir __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 22:30:35 2008 From: report at bugs.python.org (Thomas Conway) Date: Wed, 19 Mar 2008 21:30:35 +0000 Subject: [issue1390] toxml generates output that is not well formed In-Reply-To: <1205962010.45.0.365648667091.issue1390@psf.upfronthosting.co.za> Message-ID: <784a62100803191430n65213833v6526aa0d94e3b8d9@mail.gmail.com> Thomas Conway added the comment: On Thu, Mar 20, 2008 at 8:26 AM, Sean Reifschneider wrote: > > Sean Reifschneider added the comment: > > Martin: What do you think of this patch? Looks fine. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 22:35:06 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Mar 2008 21:35:06 +0000 Subject: [issue2126] BaseHTTPServer.py fails long POST from IE In-Reply-To: <1203167938.11.0.556138107236.issue2126@psf.upfronthosting.co.za> Message-ID: <1205962506.08.0.384219592994.issue2126@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Raymond: Can you see the other related issues and see if the proposed fix (inline in the comment) is acceptable? ---------- assignee: -> rhettinger nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 22:40:57 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Mar 2008 21:40:57 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1205962857.57.0.645600397838.issue1943@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Marc-Andre: Wit the udpated patches, is this a set of patches we can accept? ---------- assignee: -> lemburg keywords: +patch nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 22:44:50 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Mar 2008 21:44:50 +0000 Subject: [issue1813] Codec lookup failing under turkish locale In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za> Message-ID: <1205963090.0.0.468827268091.issue1813@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Marc-Andre: How should we proceed with this bug? Discuss on python-dev or c.l.python? ---------- assignee: -> lemburg keywords: +patch nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 22:51:09 2008 From: report at bugs.python.org (Collin Winter) Date: Wed, 19 Mar 2008 21:51:09 +0000 Subject: [issue2354] cmp argument to list.sort()/sorted() should raise a Py3K warning In-Reply-To: <1205782211.6.0.934088370296.issue2354@psf.upfronthosting.co.za> Message-ID: <1205963469.25.0.105333528688.issue2354@psf.upfronthosting.co.za> Collin Winter added the comment: There's currently no central repository that I know of. We should have an informational PEP on the subject; would you like to start one with sort/sorted keys as the seed? I've got some notes I can contribute, and I'd like to milk Guido for his experience with str/bytes porting. ---------- assignee: collinwinter -> rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 22:58:52 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 19 Mar 2008 21:58:52 +0000 Subject: [issue1576598] ftplib doesn't follow standard Message-ID: <1205963932.81.0.947961131546.issue1576598@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: I think the problem you described is up to the FTP server implementation which does not have unicode support. The telnet protocol is used in FTP only when dealing with ABOR and STAT commands. It has nothing to do with pathnames. ---------- nosy: +giampaolo.rodola _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Mar 19 22:59:53 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 19 Mar 2008 21:59:53 +0000 Subject: [issue751758] ftplib.retrbinary fails when called from retrlines callback Message-ID: <1205963993.59.0.608756953759.issue751758@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola ____________________________________ Tracker ____________________________________ From report at bugs.python.org Wed Mar 19 23:00:58 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 19 Mar 2008 22:00:58 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1205964058.63.0.00375630538072.issue1943@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for your interest Sean :) By the way, on python-3000 both GvR and Martin von L?wis were ok on the proposed design change, although they did not review the patch itself. http://mail.python.org/pipermail/python-3000/2008-February/012076.html __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 23:02:58 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Mar 2008 22:02:58 +0000 Subject: [issue2413] os.strerror does not check for out of range argument In-Reply-To: <1205962117.15.0.169796240888.issue2413@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: And on some system "Unknown error: nnn" is returned with no error indication. Your concern that the patch is invalid on some unidentified system. This concern can easily be addressed by checking for NULL return *in addition* to the errno check. The real question is whether it is desirable to raise ValueError from strerror() when error code is out of bound. I would say the existing code intends to do exactly that, but th error check is incorrect on at least one popular platform. I believe it is better to raise an error because as a user, seeing "unknown error has occurred" message, is one of the worst experiences. On the other hand, if the consensus is that strerror() should always (short of out of memory condition) return a string, then (assuming null return is a possibility) the code needs to be changed to return "Unknown error: nnn" instead of raising an error. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 23:25:21 2008 From: report at bugs.python.org (David Wolever) Date: Wed, 19 Mar 2008 22:25:21 +0000 Subject: [issue2427] 2to3 should translate itertools.imap into generator expression, not list comprehension In-Reply-To: <1205955294.72.0.717480464196.issue2427@psf.upfronthosting.co.za> Message-ID: <1205965521.39.0.0220064785298.issue2427@psf.upfronthosting.co.za> David Wolever added the comment: itertools.imap is being translated directly to map... But I bet this is another one of those ordering problems -- itertools.imap is converted to the map, then the map is converted to list(map(...)) because fix_map doesn't know that map was already fixed. ---------- assignee: collinwinter -> David Wolever nosy: +David Wolever __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 23:34:07 2008 From: report at bugs.python.org (David Wolever) Date: Wed, 19 Mar 2008 22:34:07 +0000 Subject: [issue2428] 2to3 deletes # comments before "from __future__ import with_statement" In-Reply-To: <1205960403.35.0.278186384366.issue2428@psf.upfronthosting.co.za> Message-ID: <1205966047.23.0.511914045606.issue2428@psf.upfronthosting.co.za> Changes by David Wolever : ---------- assignee: collinwinter -> David Wolever nosy: +David Wolever __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 23:36:45 2008 From: report at bugs.python.org (Daniel Arbuckle) Date: Wed, 19 Mar 2008 22:36:45 +0000 Subject: [issue1641] asyncore delayed calls feature In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za> Message-ID: <1205966205.54.0.795376980752.issue1641@psf.upfronthosting.co.za> Daniel Arbuckle added the comment: Unfortunately, it appears that asyncore and asynchat are caught in a deadlock, in which it is demanded that certain patches be applied before any further work is done, but nobody (even among those making the demands) is both willing and able to review and apply those patches. We need this situation to be resolved, preferably by somebody with commit access doing the necessary work, but failing that by allowing new patches and requiring the old ones to be updated at whatever time somebody decides to actually address them. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 23:40:34 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Mar 2008 22:40:34 +0000 Subject: [issue2132] Blocking sockets take entirely too long to timeout In-Reply-To: <1203274614.89.0.5704894361.issue2132@psf.upfronthosting.co.za> Message-ID: <1205966434.44.0.384548876866.issue2132@psf.upfronthosting.co.za> Sean Reifschneider added the comment: smtplib is for sending messages via SMTP, not for testing to see if a user is behind an ISP that is incorrectly blocking outgoing SMTP connections. I would argue the "incorrectly" because they are dropping rather than rejecting the connection packets. One mechanism would be to use an alarm(30) call which would limit the whole transaction to 30 seconds (connection, EHLO, RCPT, QUIT), not just the connection. My experience with dealing with remote machines in a time-sensitive manner is that this approach is much more usable than using socket timeouts. A better mechanism is probably to use non-blocking socket I/O directly and make connections to all or many of the remote servers and test them in parallel, meaning all servers could be tested in 30 seconds (or whatever your timeout is) rather than 5 minutes (you imply in your message that you may be doing more than a dozen requests). So, I believe the current functionality in the smtplib of being simple and conservative at trying to get messages through, rather than trying to be optimized for checking for account existance, is reasonable. And that in any case, using alarm() is a better solution than socket timeouts. ---------- nosy: +jafo priority: -> normal resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 19 23:58:38 2008 From: report at bugs.python.org (Collin Winter) Date: Wed, 19 Mar 2008 22:58:38 +0000 Subject: [issue2366] Fixer for new metaclass syntax is needed In-Reply-To: <1205783672.52.0.982802083184.issue2366@psf.upfronthosting.co.za> Message-ID: <1205967518.71.0.022706361163.issue2366@psf.upfronthosting.co.za> Collin Winter added the comment: A quick test indicates that the old way doesn't work anymore. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 00:02:01 2008 From: report at bugs.python.org (Brett Cannon) Date: Wed, 19 Mar 2008 23:02:01 +0000 Subject: [issue2407] warnings.filterwarnings() not isolated between tests In-Reply-To: <1205873804.14.0.137963727485.issue2407@psf.upfronthosting.co.za> Message-ID: <1205967721.32.0.0904579545838.issue2407@psf.upfronthosting.co.za> Brett Cannon added the comment: Fixed in revision 61651. ---------- nosy: +brett.cannon resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 00:07:19 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 19 Mar 2008 23:07:19 +0000 Subject: [issue2417] [py3k] Integer floor division (//): small int check omitted In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za> Message-ID: <1205968039.16.0.354623514602.issue2417@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Attached patch fixes the cases discovered so far. It is possible that in some of these cases creation of the long object that is later discarded can be avoided by detecting small int return early, but such optimizations should probably be left for later. Any advise on how to write a unit test? Should the unit test detect python compiled with NSMALLNEGINTS + NSMALLPOSINTS == 0 and disable identity checks? ---------- keywords: +patch Added file: http://bugs.python.org/file9776/issue2417.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 00:12:47 2008 From: report at bugs.python.org (Jeff Balogh) Date: Wed, 19 Mar 2008 23:12:47 +0000 Subject: [issue2381] test_subprocess fails if your sys.executable is on a path with a space in it In-Reply-To: <1205813955.12.0.0111122307325.issue2381@psf.upfronthosting.co.za> Message-ID: <1205968367.35.0.733475921058.issue2381@psf.upfronthosting.co.za> Jeff Balogh added the comment: The patch works for me, and doesn't change anything except the test strings. Not having spaces in your path also helps. ;) ---------- nosy: +jeff.balogh __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 00:22:35 2008 From: report at bugs.python.org (Michael Foord) Date: Wed, 19 Mar 2008 23:22:35 +0000 Subject: [issue2429] Patch for test_urllib2_net moving tests to use a local server In-Reply-To: <1205968955.73.0.744201305439.issue2429@psf.upfronthosting.co.za> Message-ID: <1205968955.73.0.744201305439.issue2429@psf.upfronthosting.co.za> New submission from Michael Foord : This patch moves some tests from test_urllib2_net to test_urllib2_localnet. The moved tests now use a local server rather than going out to external servers. Mainly the work of Jerry Seutter - so blame him. ;-) ---------- components: Tests files: network_tests.patch keywords: patch messages: 64121 nosy: fuzzyman severity: normal status: open title: Patch for test_urllib2_net moving tests to use a local server versions: Python 2.6 Added file: http://bugs.python.org/file9777/network_tests.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 00:25:23 2008 From: report at bugs.python.org (Adam Olsen) Date: Wed, 19 Mar 2008 23:25:23 +0000 Subject: [issue2417] [py3k] Integer floor division (//): small int check omitted In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za> Message-ID: <1205969122.98.0.383112616988.issue2417@psf.upfronthosting.co.za> Adam Olsen added the comment: Unless someone has a legitimate use case for disabling small_int that doesn't involve debugging (which I really doubt), I'd just assume it's always in use. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 00:36:46 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Mar 2008 23:36:46 +0000 Subject: [issue2136] urllib2 basic auth handler doesn't handle realm names in single-quoted strings In-Reply-To: <1203296568.46.0.747126970867.issue2136@psf.upfronthosting.co.za> Message-ID: <1205969806.15.0.137572701495.issue2136@psf.upfronthosting.co.za> Sean Reifschneider added the comment: This patch looks good to me, but I don't know the implications of this. It seems reasonable to me, but I'd defer to an HTTP lawyer. ---------- assignee: -> georg.brandl keywords: +patch nosy: +georg.brandl, jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 00:38:00 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 19 Mar 2008 23:38:00 +0000 Subject: [issue2413] os.strerror does not check for out of range argument In-Reply-To: <1205889895.08.0.168690164912.issue2413@psf.upfronthosting.co.za> Message-ID: <1205969880.93.0.940800241576.issue2413@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: -tjreedy __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 00:44:32 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 19 Mar 2008 23:44:32 +0000 Subject: [issue1471] ioctl request argument broken on 64-bit OpenBSD or OS X In-Reply-To: <1195518427.96.0.197538707678.issue1471@psf.upfronthosting.co.za> Message-ID: <1205970272.13.0.871561434942.issue1471@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I am unable to reproduce this problem at all on Mac OS X 10.4 or 10.5 with 32-bit or 64-bit python trunk builds. I have however checked in a fix that'll prevent negative code values passed in from being sign extended to 64-bits when converted to an unsigned long on platforms that use those. A unittest for fcntl.ioctl behavior when passed both positive and negative values is included. trunk r61652 while the Linux man page describe's ioctl's code parameter as an int, the sys/ioctl.h file on linux has it as an unsigned long int in the function prototype. So its quite possible it is actually an unsigned long on all platforms and we should change unsigned int code to unsigned long code and the 'I' to a 'k'. However if that is done we -might- have a sign extension problem again if anyone is passing a negative value in and expecting it to act like a 32-bit value. If the OS kernels only look at the lower 32-bits of the ioctl code during the syscall it'd work, but if it tested the 64bit value -123 64bit != -123 32bit. The better answer to that would be to just reject all negative values and fix any defined ioctl code constants to be positive on all platforms. fbvortex. Can you apply the change from svn to your python and test that it works properly on your 64-bit OpenBSD system? Thanks. paste a note here once you have with the results. ---------- resolution: -> fixed status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 00:46:34 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Mar 2008 23:46:34 +0000 Subject: [issue2141] Pydoc interactive browser misses some docs In-Reply-To: <1203344335.25.0.229282723234.issue2141@psf.upfronthosting.co.za> Message-ID: <1205970394.4.0.491697262584.issue2141@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> ping nosy: +ping priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 00:49:20 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Mar 2008 23:49:20 +0000 Subject: [issue2148] nis module not supporting group aliases In-Reply-To: <1203510631.66.0.497834646199.issue2148@psf.upfronthosting.co.za> Message-ID: <1205970560.03.0.277671216299.issue2148@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> loewis priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 00:50:51 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Mar 2008 23:50:51 +0000 Subject: [issue2155] optparse.OptionGroup with_statement context handling In-Reply-To: <1203608881.22.0.564217354476.issue2155@psf.upfronthosting.co.za> Message-ID: <1205970651.89.0.316542119273.issue2155@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Patch is inline. ---------- assignee: -> gward keywords: +patch nosy: +gward, jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 00:56:59 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Wed, 19 Mar 2008 23:56:59 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1205971019.18.0.478419992184.issue2159@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Proposed patch is inline. ---------- assignee: -> gvanrossum keywords: +patch nosy: +gvanrossum, jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 00:58:50 2008 From: report at bugs.python.org (Jack Diederich) Date: Wed, 19 Mar 2008 23:58:50 +0000 Subject: [issue2366] Fixer for new metaclass syntax is needed In-Reply-To: <1205783672.52.0.982802083184.issue2366@psf.upfronthosting.co.za> Message-ID: <1205971130.27.0.579659048078.issue2366@psf.upfronthosting.co.za> Jack Diederich added the comment: Here is a partial implementation. It doesn't warn about __metaclass__ at the module level and doesn't handle multiple __metaclass__ assignements in one class. tests pending. ---------- keywords: +patch Added file: http://bugs.python.org/file9778/fix_metaclass.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 01:01:24 2008 From: report at bugs.python.org (Jeff Balogh) Date: Thu, 20 Mar 2008 00:01:24 +0000 Subject: [issue2370] operator.{isCallable,sequenceIncludes} needs a fixer In-Reply-To: <1205784272.93.0.866002228926.issue2370@psf.upfronthosting.co.za> Message-ID: <1205971284.4.0.100961955249.issue2370@psf.upfronthosting.co.za> Jeff Balogh added the comment: Attaching a revised patch that has a ``warnsunchanged`` test case. Added file: http://bugs.python.org/file9779/issue2370.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 01:01:31 2008 From: report at bugs.python.org (Jeff Balogh) Date: Thu, 20 Mar 2008 00:01:31 +0000 Subject: [issue2370] operator.{isCallable,sequenceIncludes} needs a fixer In-Reply-To: <1205784272.93.0.866002228926.issue2370@psf.upfronthosting.co.za> Message-ID: <1205971291.37.0.929216906948.issue2370@psf.upfronthosting.co.za> Changes by Jeff Balogh : Removed file: http://bugs.python.org/file9736/issue2370.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 01:01:35 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 00:01:35 +0000 Subject: [issue2059] OptionMenu class is defined both in Tkinter and Tix In-Reply-To: <1202658940.12.0.289973757596.issue2059@psf.upfronthosting.co.za> Message-ID: <1205971295.7.0.080715212897.issue2059@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I don't see the problem with the example listed in the last message. It sounds like the Tix documentation is confirming that this is the desired behavior. ---------- nosy: +jafo priority: -> normal resolution: -> works for me status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 01:10:53 2008 From: report at bugs.python.org (David Wolever) Date: Thu, 20 Mar 2008 00:10:53 +0000 Subject: [issue2427] 2to3 should translate itertools.imap into generator expression, not list comprehension In-Reply-To: <1205955294.72.0.717480464196.issue2427@psf.upfronthosting.co.za> Message-ID: <1205971853.9.0.17787242136.issue2427@psf.upfronthosting.co.za> David Wolever added the comment: Ok, I've added explicit ordering to fixers in r61654, fixing this issue. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 01:15:37 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 20 Mar 2008 00:15:37 +0000 Subject: [issue2427] 2to3 should translate itertools.imap into generator expression, not list comprehension In-Reply-To: <1205955294.72.0.717480464196.issue2427@psf.upfronthosting.co.za> Message-ID: <1205972137.58.0.357545233091.issue2427@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks David. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 01:16:57 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 00:16:57 +0000 Subject: [issue1741] .pypirc not found on windows In-Reply-To: <1199616321.65.0.452980154178.issue1741@psf.upfronthosting.co.za> Message-ID: <1205972217.45.0.69631800542.issue1741@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I'm closing this as a duplicate of #1858. ---------- nosy: +jafo resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 01:28:49 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 00:28:49 +0000 Subject: [issue2166] pydistutils.cfg won't be found on Windows In-Reply-To: <1203776225.5.0.753260751144.issue2166@psf.upfronthosting.co.za> Message-ID: <1205972929.04.0.597805444748.issue2166@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- priority: -> normal superseder: -> Make .pypirc handle multiple servers __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 01:30:17 2008 From: report at bugs.python.org (Trent Nelson) Date: Thu, 20 Mar 2008 00:30:17 +0000 Subject: [issue2329] ImportError: No module named _bsddb In-Reply-To: <1205774742.16.0.265427731372.issue2329@psf.upfronthosting.co.za> Message-ID: <1205973017.36.0.0284503463411.issue2329@psf.upfronthosting.co.za> Trent Nelson added the comment: Please provide more information about your platform. Also note that ./configure needs to be able to find pre-existing bsddb libs in order for Python to build the _bsddb module. ---------- nosy: +Trent.Nelson __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 01:30:36 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 00:30:36 +0000 Subject: [issue1741] .pypirc not found on windows In-Reply-To: <1199616321.65.0.452980154178.issue1741@psf.upfronthosting.co.za> Message-ID: <1205973036.84.0.2211597244.issue1741@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- superseder: -> Make .pypirc handle multiple servers __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 01:31:57 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 00:31:57 +0000 Subject: [issue2166] pydistutils.cfg won't be found on Windows In-Reply-To: <1203776225.5.0.753260751144.issue2166@psf.upfronthosting.co.za> Message-ID: <1205973117.35.0.0703252613277.issue2166@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Closing as a duplicate of 1858. ---------- nosy: +jafo resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 01:48:54 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 00:48:54 +0000 Subject: [issue2143] smtplib.SSLFakeFile hangs forever if "\n" is not encountered In-Reply-To: <1203450784.48.0.914624365549.issue2143@psf.upfronthosting.co.za> Message-ID: <1205974134.48.0.657816152586.issue2143@psf.upfronthosting.co.za> Sean Reifschneider added the comment: ssl.SSLSocket.read() says: Return zero-length string on EOF. So, I'm going to apply this patch. Applied in rev 61656. ---------- keywords: +patch nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 01:52:18 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 00:52:18 +0000 Subject: [issue2143] smtplib.SSLFakeFile hangs forever if "\n" is not encountered In-Reply-To: <1203450784.48.0.914624365549.issue2143@psf.upfronthosting.co.za> Message-ID: <1205974338.17.0.774655342613.issue2143@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 01:55:46 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 20 Mar 2008 00:55:46 +0000 Subject: [issue777588] asyncore is broken for windows if connection is refused Message-ID: <1205974546.01.0.46165809705.issue777588@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Mar 20 01:56:20 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 20 Mar 2008 00:56:20 +0000 Subject: [issue1025525] asyncore.file_dispatcher should not take fd as argument Message-ID: <1205974580.69.0.210353229314.issue1025525@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 20 02:32:52 2008 From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=) Date: Thu, 20 Mar 2008 01:32:52 +0000 Subject: [issue2320] Race condition in subprocess using stdin In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za> Message-ID: <1205976772.37.0.221961465006.issue2320@psf.upfronthosting.co.za> Ludwig H?hne added the comment: Hi, I narrowed the problem down to the creation of the error pipe in _execute_child: >> errpipe_read, errpipe_write = os.pipe() >> self._set_cloexec_flag(errpipe_write) If I protect these two lines with a lock, I cannot reproduce the hang anymore (tested against Python 2.5.1). I'm not yet sure why this should be atomic (as there are no classic race condition problems involved AFAICT). By the way, this is on Linux: > uname -a Linux jade 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 03:15:16 2008 From: report at bugs.python.org (Trent Nelson) Date: Thu, 20 Mar 2008 02:15:16 +0000 Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za> Message-ID: <1205979316.32.0.320826836337.issue1657@psf.upfronthosting.co.za> Trent Nelson added the comment: Patch applies cleanly on FreeBSD 6.2-STABLE and all tests pass. Can't comment on technical accuracy. ---------- nosy: +Trent.Nelson __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 03:38:57 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 02:38:57 +0000 Subject: [issue1738] filecmp.dircmp does exact match only In-Reply-To: <1199482445.72.0.241275927673.issue1738@psf.upfronthosting.co.za> Message-ID: <1205980737.56.0.0491321045515.issue1738@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Please also include at least documentation changes, since this changes the behavior of the module. This would be in the file: Doc/library/filecmp.rst Also. If possible a test would be great. The file for this would be: ./Lib/test/test_filecmp.py ---------- keywords: +patch nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 03:40:53 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 02:40:53 +0000 Subject: [issue1483] xml.sax.saxutils.prepare_input_source ignores character stream in InputSource In-Reply-To: <1195653795.8.0.542576278207.issue1483@psf.upfronthosting.co.za> Message-ID: <1205980853.84.0.16514072939.issue1483@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> akuchling priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 03:42:37 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 02:42:37 +0000 Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za> Message-ID: <1205980957.7.0.206244183086.issue2175@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> loewis nosy: +loewis priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 03:45:59 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 02:45:59 +0000 Subject: [issue2178] Problems with Belarusian Latin locale In-Reply-To: <1203887565.7.0.326406718733.issue2178@psf.upfronthosting.co.za> Message-ID: <1205981159.98.0.651918443896.issue2178@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- components: +Unicode -None priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 03:52:31 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 02:52:31 +0000 Subject: [issue2174] xml.sax.xmlreader does not support the InputSource protocol In-Reply-To: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za> Message-ID: <1205981551.98.0.410914546884.issue2174@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> fdrake nosy: +fdrake priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 03:54:15 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 02:54:15 +0000 Subject: [issue2182] tokenize: does not allow CR for a newline In-Reply-To: <1203905207.87.0.633637741257.issue2182@psf.upfronthosting.co.za> Message-ID: <1205981655.83.0.271922200146.issue2182@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> gvanrossum components: +Library (Lib) -Extension Modules nosy: +gvanrossum priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 03:56:57 2008 From: report at bugs.python.org (James Henstridge) Date: Thu, 20 Mar 2008 02:56:57 +0000 Subject: [issue2422] Automatically disable pymalloc when running under valgrind In-Reply-To: <1205925069.41.0.603933745456.issue2422@psf.upfronthosting.co.za> Message-ID: <1205981817.77.0.49859979927.issue2422@psf.upfronthosting.co.za> James Henstridge added the comment: A slightly cleaned up version of the previous patch. I only needed to include . Added file: http://bugs.python.org/file9780/disable-pymalloc-on-valgrind-v2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 04:08:15 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 03:08:15 +0000 Subject: [issue2180] tokenize: mishandles line joining In-Reply-To: <1203904758.19.0.84784431119.issue2180@psf.upfronthosting.co.za> Message-ID: <1205982495.57.0.0405702250962.issue2180@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> jhylton nosy: +jhylton __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 04:21:02 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 03:21:02 +0000 Subject: [issue2188] [patch] urllib2 hint - disabled ProxyHandler() In-Reply-To: <1203937729.17.0.846967390302.issue2188@psf.upfronthosting.co.za> Message-ID: <1205983261.99.0.689941742782.issue2188@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Committed in rev 61663, thanks. ---------- nosy: +jafo priority: -> normal resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 04:23:55 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 03:23:55 +0000 Subject: [issue2190] MozillaCookieJar ignore HttpOnly cookies In-Reply-To: <1203957546.34.0.123660895963.issue2190@psf.upfronthosting.co.za> Message-ID: <1205983435.24.0.209348896205.issue2190@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> loewis nosy: +loewis priority: -> normal type: -> feature request __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 04:27:17 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 03:27:17 +0000 Subject: [issue2189] urllib.quote() throws KeyError when passed an iterator In-Reply-To: <1203941389.03.0.634927871204.issue2189@psf.upfronthosting.co.za> Message-ID: <1205983637.76.0.506217748175.issue2189@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Yeah, I'm going to agree that urllib's documentation is clear about it taking a string instead of a list. ---------- assignee: -> jafo nosy: +jafo priority: -> normal resolution: -> wont fix status: open -> closed type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 04:29:59 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 03:29:59 +0000 Subject: [issue2001] Pydoc interactive browsing enhancement In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za> Message-ID: <1205983799.22.0.142071545567.issue2001@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> ping nosy: +ping priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 04:32:57 2008 From: report at bugs.python.org (David Wolever) Date: Thu, 20 Mar 2008 03:32:57 +0000 Subject: [issue2428] 2to3 deletes # comments before "from __future__ import with_statement" In-Reply-To: <1205960403.35.0.278186384366.issue2428@psf.upfronthosting.co.za> Message-ID: <1205983977.29.0.309977280686.issue2428@psf.upfronthosting.co.za> David Wolever added the comment: Ok, fixed in r61664. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 04:33:15 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 03:33:15 +0000 Subject: [issue2173] Python fails silently on bad locale In-Reply-To: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za> Message-ID: <1205983995.48.0.0529157313673.issue2173@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 04:37:19 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 03:37:19 +0000 Subject: [issue2197] Further simplify dict literal bytecode In-Reply-To: <1204087358.25.0.336185650198.issue2197@psf.upfronthosting.co.za> Message-ID: <1205984239.38.0.10785135282.issue2197@psf.upfronthosting.co.za> Sean Reifschneider added the comment: As addition thought is required by Alexander, I'm going to close this as postponed and you can re-open it if after further consideration you think it needs to be applied. Probably would be good to discuss on python-dev if you think it still needs to go forward though. ---------- assignee: -> rhettinger nosy: +jafo priority: -> normal resolution: -> postponed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 04:38:32 2008 From: report at bugs.python.org (James Henstridge) Date: Thu, 20 Mar 2008 03:38:32 +0000 Subject: [issue2422] Automatically disable pymalloc when running under valgrind In-Reply-To: <1205925069.41.0.603933745456.issue2422@psf.upfronthosting.co.za> Message-ID: <1205984312.44.0.66343041383.issue2422@psf.upfronthosting.co.za> Changes by James Henstridge : Added file: http://bugs.python.org/file9781/disable-pymalloc-on-valgrind-v3.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 04:38:43 2008 From: report at bugs.python.org (James Henstridge) Date: Thu, 20 Mar 2008 03:38:43 +0000 Subject: [issue2422] Automatically disable pymalloc when running under valgrind In-Reply-To: <1205925069.41.0.603933745456.issue2422@psf.upfronthosting.co.za> Message-ID: <1205984323.97.0.020315119963.issue2422@psf.upfronthosting.co.za> Changes by James Henstridge : Removed file: http://bugs.python.org/file9780/disable-pymalloc-on-valgrind-v2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 04:42:51 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 03:42:51 +0000 Subject: [issue2183] optimize list comprehensions In-Reply-To: <1203906152.35.0.945763555719.issue2183@psf.upfronthosting.co.za> Message-ID: <1205984571.85.0.16380174879.issue2183@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Neal: Can you make that doc change? ---------- assignee: -> nnorwitz nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 04:46:25 2008 From: report at bugs.python.org (Neal Norwitz) Date: Thu, 20 Mar 2008 03:46:25 +0000 Subject: [issue2183] optimize list comprehensions In-Reply-To: <1205984571.85.0.16380174879.issue2183@psf.upfronthosting.co.za> Message-ID: Neal Norwitz added the comment: Ya, I'll get around to it...hopefully soon. But if someone wants to do it for me, I won't complain. :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 04:56:26 2008 From: report at bugs.python.org (Bill Janssen) Date: Thu, 20 Mar 2008 03:56:26 +0000 Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217 In-Reply-To: <1205959612.68.0.754299368352.issue2054@psf.upfronthosting.co.za> Message-ID: <4b3e516a0803192056p62c74300pb42643dba180ae85@mail.gmail.com> Bill Janssen added the comment: Probably what I should do is fix httplib, that would provide an example we could extend to the rest of the modules. Bill On Wed, Mar 19, 2008 at 1:46 PM, Giampaolo Rodola' wrote: > > Giampaolo Rodola' added the comment: > > > As you point out, the other classes should be fixed. The old > > client-side protocol was never very well thought out, IMHO. > > Continuing to propagate it would be a mistake. > > Ok, how do you think it would have be modified? > Could you provide an example or a new patch? > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file9782/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080320/88f390b8/attachment.txt From report at bugs.python.org Thu Mar 20 04:56:47 2008 From: report at bugs.python.org (Bill Janssen) Date: Thu, 20 Mar 2008 03:56:47 +0000 Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217 In-Reply-To: <1205959612.68.0.754299368352.issue2054@psf.upfronthosting.co.za> Message-ID: <4b3e516a0803192056u8e35cd3q11ba362b730d231@mail.gmail.com> Bill Janssen added the comment: Once I've got JCC working, and finished the SSL work for 2.6. On Wed, Mar 19, 2008 at 1:46 PM, Giampaolo Rodola' wrote: > > Giampaolo Rodola' added the comment: > > > As you point out, the other classes should be fixed. The old > > client-side protocol was never very well thought out, IMHO. > > Continuing to propagate it would be a mistake. > > Ok, how do you think it would have be modified? > Could you provide an example or a new patch? > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file9783/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080320/4dd95f6f/attachment.txt From report at bugs.python.org Thu Mar 20 05:18:21 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 04:18:21 +0000 Subject: [issue2193] Cookie Colon Name Bug In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za> Message-ID: <1205986701.35.0.664533480513.issue2193@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> akuchling nosy: +akuchling priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 05:21:38 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 04:21:38 +0000 Subject: [issue2181] optimize out local variables at end of function In-Reply-To: <1203904814.51.0.0269762586023.issue2181@psf.upfronthosting.co.za> Message-ID: <1205986898.35.0.985963126704.issue2181@psf.upfronthosting.co.za> Changes by Sean Reifschneider : __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 05:25:22 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 04:25:22 +0000 Subject: [issue2181] optimize out local variables at end of function In-Reply-To: <1203904814.51.0.0269762586023.issue2181@psf.upfronthosting.co.za> Message-ID: <1205987122.8.0.356741600193.issue2181@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> nnorwitz priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 05:26:16 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 04:26:16 +0000 Subject: [issue2203] ssl module getpeercert returns empty dict when cert_reqs=ssl.CERT_NONE Message-ID: <1205987176.4.0.106982379401.issue2203@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- priority: -> normal status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 05:28:00 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 04:28:00 +0000 Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess auth) In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za> Message-ID: <1205987280.14.0.0958397716904.issue2202@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> georg.brandl nosy: +georg.brandl priority: -> normal versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 05:29:12 2008 From: report at bugs.python.org (Jerry Seutter) Date: Thu, 20 Mar 2008 04:29:12 +0000 Subject: [issue2430] Stop test_format.py from executing as side effect of import In-Reply-To: <1205987352.7.0.846357959052.issue2430@psf.upfronthosting.co.za> Message-ID: <1205987352.7.0.846357959052.issue2430@psf.upfronthosting.co.za> New submission from Jerry Seutter : Changes to test file only, no other changes. ---------- components: Tests files: test_format_to_unittest.patch keywords: patch, patch messages: 64148 nosy: jseutter priority: low severity: normal status: open title: Stop test_format.py from executing as side effect of import versions: Python 2.6 Added file: http://bugs.python.org/file9784/test_format_to_unittest.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 05:29:22 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 04:29:22 +0000 Subject: [issue2209] mailbox module doesn't support compressed mbox In-Reply-To: <1204283686.29.0.398991298124.issue2209@psf.upfronthosting.co.za> Message-ID: <1205987362.84.0.300224534528.issue2209@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> akuchling nosy: +akuchling priority: -> normal type: -> feature request __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 05:30:23 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 04:30:23 +0000 Subject: [issue2210] Nested module import clutters package namespace In-Reply-To: <1204286639.84.0.689580155696.issue2210@psf.upfronthosting.co.za> Message-ID: <1205987423.18.0.976349460118.issue2210@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> brett.cannon nosy: +brett.cannon priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 05:43:58 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 04:43:58 +0000 Subject: [issue2212] Cookie.BaseCookie has ambiguous unicode handling In-Reply-To: <1204315669.5.0.476777122389.issue2212@psf.upfronthosting.co.za> Message-ID: <1205988238.78.0.148992675823.issue2212@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Fix is inline. ---------- assignee: -> akuchling keywords: +patch nosy: +akuchling, jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 05:46:30 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 20 Mar 2008 04:46:30 +0000 Subject: [issue2417] [py3k] Integer floor division (//): small int check omitted In-Reply-To: <1205901957.73.0.828809494878.issue2417@psf.upfronthosting.co.za> Message-ID: <1205988390.57.0.184598575797.issue2417@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Attached (issue2417a.diff) patch adds unit tests and fixes a few corner cases when a non-preallocated 0 was returned to python. Added file: http://bugs.python.org/file9785/issue2417a.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 05:54:27 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 04:54:27 +0000 Subject: [issue2195] urlparse() does not handle URLs with port numbers properly In-Reply-To: <1204065114.68.0.139974159124.issue2195@psf.upfronthosting.co.za> Message-ID: <1205988867.89.0.0951655848394.issue2195@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> georg.brandl nosy: +georg.brandl priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 06:01:20 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 05:01:20 +0000 Subject: [issue2228] Imaplib speedup patch In-Reply-To: <1204580526.67.0.16390655339.issue2228@psf.upfronthosting.co.za> Message-ID: <1205989280.79.0.189624637037.issue2228@psf.upfronthosting.co.za> Sean Reifschneider added the comment: This patch buffers data inside imaplib, so if anything else wants to use the socket it may generate surprises. Piers? ---------- assignee: -> pierslauder keywords: +patch nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 06:30:55 2008 From: report at bugs.python.org (David Wolever) Date: Thu, 20 Mar 2008 05:30:55 +0000 Subject: [issue2431] 2to3 is rather slow In-Reply-To: <1205991054.16.0.327808127723.issue2431@psf.upfronthosting.co.za> Message-ID: <1205991054.16.0.327808127723.issue2431@psf.upfronthosting.co.za> New submission from David Wolever : It takes me 10 seconds to run 2to3 on the example file. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 64152 nosy: David Wolever, collinwinter severity: normal status: open title: 2to3 is rather slow type: performance __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 06:43:44 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 20 Mar 2008 05:43:44 +0000 Subject: [issue1720] VC6 build patch for release-maint25 In-Reply-To: <1199285194.09.0.0105963062735.issue1720@psf.upfronthosting.co.za> Message-ID: <1205991824.87.0.273992354967.issue1720@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: issue2065 contains the patch for this branch too, so I'll close this issue. ---------- resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 06:44:29 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 20 Mar 2008 05:44:29 +0000 Subject: [issue1700463] VC6 build patch for trunk Message-ID: <1205991869.39.0.757608272312.issue1700463@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: issue2065 contains the patch for this branch too, so I'll close this issue. ---------- resolution: -> duplicate status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 20 06:44:29 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 20 Mar 2008 05:44:29 +0000 Subject: [issue1471] ioctl request argument broken on 64-bit OpenBSD or OS X In-Reply-To: <1195518427.96.0.197538707678.issue1471@psf.upfronthosting.co.za> Message-ID: <1205991869.9.0.1386620803.issue1471@psf.upfronthosting.co.za> Gregory P. Smith added the comment: r61665 moves the test to test_ioctl instead of test_fcntl. it also forces it to only run when a pty is present rather than assuming fd 0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 06:47:49 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 20 Mar 2008 05:47:49 +0000 Subject: [issue2382] [Py3k] SyntaxError cursor shifted if multibyte character is in line. In-Reply-To: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za> Message-ID: <1205992069.06.0.247652602497.issue2382@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: > (I assumed get_length_in_bytes(f, " ", 1) == 1 but I'm not sure > this is always true in other platforms. Probably nicer and more > general solution may exist) This assumption still lives, but I cannot find better solution. I'm thinking now attached patch is good enough. Added file: http://bugs.python.org/file9786/fix.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 06:48:01 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 20 Mar 2008 05:48:01 +0000 Subject: [issue2382] [Py3k] SyntaxError cursor shifted if multibyte character is in line. In-Reply-To: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za> Message-ID: <1205992081.11.0.328181069989.issue2382@psf.upfronthosting.co.za> Changes by Hirokazu Yamamoto : Removed file: http://bugs.python.org/file9723/experimental.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 07:15:10 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 20 Mar 2008 06:15:10 +0000 Subject: [issue2384] [Py3k] line number is wrong after encoding declaration In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za> Message-ID: <1205993710.73.0.369658094048.issue2384@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: Following dirty hack workarounds this bug. Comment of this function says not ascii compatible encoding is not supported yet, (ie: UTF-16) so probably this works. Index: Parser/tokenizer.c =================================================================== --- Parser/tokenizer.c (revision 61632) +++ Parser/tokenizer.c (working copy) @@ -464,6 +464,7 @@ Py_XDECREF(tok->decoding_readline); readline = PyObject_GetAttrString(stream, "readline"); tok->decoding_readline = readline; + tok->lineno = -1; /* dirty hack */ cleanup: Py_XDECREF(stream); But if multibyte character is in line like this, its line will not be printed. # coding: cp932 # 1 raise RuntimeError("?????") # 2 C:\Documents and Settings\WhiteRabbit>py3k cp932.py Traceback (most recent call last): File "cp932.py", line 3, in [22819 refs] This is because Python/trackeback.c 's tb_displayline() assumes input line is encoded with UTF-8. (simply using FILE structure + Py_UniversalNewlineFgets) # http://mail.python.org/pipermail/python-3000/2008-March/012546.html # sounds nice, if we can replace all FILE structure to Python's own # fast enough codeced Reader or something. ---------- type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 07:44:59 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 20 Mar 2008 06:44:59 +0000 Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za> Message-ID: <1205995499.03.0.537612607361.issue1657@psf.upfronthosting.co.za> Gregory P. Smith added the comment: +1 trunk_select_epoll_kqueue9.patch looks good to me. style nit: I'd just use self.fail("error message") instead of raise AssertionError("error message") within unittests. regardless, both work so I don't care. :) ---------- nosy: +gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 08:26:08 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 20 Mar 2008 07:26:08 +0000 Subject: [issue2383] Remove old XXX comment in stat.py In-Reply-To: <1205822422.49.0.9184745501.issue2383@psf.upfronthosting.co.za> Message-ID: <1205997968.36.0.431835588265.issue2383@psf.upfronthosting.co.za> Georg Brandl added the comment: Applied in r61667. ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 09:47:00 2008 From: report at bugs.python.org (ivanoe) Date: Thu, 20 Mar 2008 08:47:00 +0000 Subject: [issue2432] DictReader does not suport line_num In-Reply-To: <1206002820.55.0.716931876955.issue2432@psf.upfronthosting.co.za> Message-ID: <1206002820.55.0.716931876955.issue2432@psf.upfronthosting.co.za> New submission from ivanoe : Documentation http://docs.python.org/lib/node264.html mentions that both 'reader' and 'DictReader' support 'line_num' fields. But in fact in version 2.5.2 of the library line_num is not in 'DictReader' class. (looking at csv.py) For the moment I created little wrapper class to handle the issue, but it should be done in the original 'DictReader' to support uniform 'interface' of the reader. {{{ import csv class DictReader(csv.DictReader): """ DictReader that supports line_num field. """ def __init__(self, f, fieldnames=None, restkey=None, restval=None, dialect="excel", *args, **kwds): csv.DictReader.__init__(self, f, fieldnames, restkey, restval, dialect) self.line_num = 0 def next(self): res = csv.DictReader.next(self) self.line_num+=1 return res }}} (sorry, no tests) I suggest that line_num gets implemented, rather then documentation changed. ---------- assignee: georg.brandl components: Documentation, Library (Lib) messages: 64160 nosy: georg.brandl, ivanoe severity: normal status: open title: DictReader does not suport line_num type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 11:04:01 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 20 Mar 2008 10:04:01 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206007441.4.0.666404446008.issue1943@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Antoine, as I've already mentioned in my other comments, I'm -1 on changing the Unicode object to a variable size object. I also don't think that the micro-benchmarks you are applying really do test the implementation in a real-life situations. The only case where your patch appears significantly faster is the "long string" case. If you look at the distribution of the Unicode strings generated by this case, you'll find that most strings have less than 10-20 characters. Optimizing pymalloc for these cases and tuning the parameters in the Unicode implementation will likely give you the same performance increase without having to sacrifice the advantages of using a pointer in the object rather than a inlining the data. I'm +1 on the free list changes, though, in the long run, I think that putting more efforts into improving pymalloc and removing the free lists altogether would be better. BTW: Unicode slices would be a possible and fairly attractive target for a C level subclass of Unicode objects. The pointer in the Unicode object implementation could then point to the original Unicode object's buffer and the subclass would add an extra pointer to the original object itself (in order to keep it alive). The Unicode type (written by Fredrik Lundh) I used as basis for the Unicode implementation worked with this idea. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 11:20:48 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 20 Mar 2008 10:20:48 +0000 Subject: [issue1813] Codec lookup failing under turkish locale In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za> Message-ID: <1206008448.85.0.240907368627.issue1813@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Sean: I'd suggest to discuss this on python-dev. Note that even if we do use Unicode for the cases in question, the Turkish locale will still pose a problem - see #1528802 for a discussion. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 11:31:01 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 20 Mar 2008 10:31:01 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206009061.46.0.732675750212.issue1943@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Marc-Andre: don't all your objections also apply to the 8bit string type, which is already a variable-size structure? Is extending unicode more common than extending str? With python 3.0, all strings are unicode. Shouldn't this type be optimized for the same use cases of the previous str type? ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 11:39:14 2008 From: report at bugs.python.org (=?utf-8?q?Ludwig_H=C3=A4hne?=) Date: Thu, 20 Mar 2008 10:39:14 +0000 Subject: [issue2320] Race condition in subprocess using stdin In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za> Message-ID: <1206009554.56.0.438745904282.issue2320@psf.upfronthosting.co.za> Ludwig H?hne added the comment: Just realized that passing 'close_fds=True' also circumvents the problem: s = subprocess.Popen(("cat"), stdin=subprocess.PIPE, close_fds=True) Should this issue be closed as it's that easy to avoid? I would still like to know what happens here, though. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 12:00:14 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 20 Mar 2008 11:00:14 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206010814.68.0.0460200748164.issue1943@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Yes, all those objections apply to the string type as well. The fact that strings are variable length objects makes it impossible to do apply any of the possible optimizations I mentioned. If strings were a fixed length object, it would have been possible to write a true basestring object from which both 8-bit strings and Unicode subclass, making a lot of things easier. BTW: Please also see ticket #2321 to see how the change affects your benchmarks. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 12:32:39 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 20 Mar 2008 11:32:39 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206012759.83.0.71634043205.issue1943@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hi, Marc-Andr?, I'm all for "real-life" benchmarks if someone proposes some. Until that we have to live with micro-benchmarks, which seems to be the method used for other CPython optimizations by the way. You are talking about slicing optimizations but you forget that the "lazy slices" idea has been shot down by Guido and others when proposed by Larry Hastings (with a patch) some time ago. Also the "lazy slices" patch was for 8-bit strings, which *are* variable-size objects, which seems to counter your argument that variable-size Unicode objects would prevent making such optimizations. As I said the freelist changes actually have mixed consequences, and in general don't improve much (and that improvement is just backed by micro-benchmarks after all... why would it be more convincing than the far greater improvement brought by making Unicode objects variable-size objects?). Why wouldn't you express your arguments in the python-3000 thread I launched one month ago, so that at least there is a clear picture of the different arguments for and against this approach? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 13:53:14 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 20 Mar 2008 12:53:14 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206017594.86.0.179783265126.issue1943@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Regarding benchmarks: It's difficult to come up with decent benchmarks for things like this. A possible strategy is to use an instrumented interpreter that records which Unicode objects are created and when they are deleted. If you then run this instrumented interpreter against a few larger applications such as Zope for a while, you'll get a data set that can be used as input for a more real-life like benchmark. I've done this in the past for Python byte codes to see which are used how often - based on such data you can create optimizations that have a real-life effect. Regarding the lazy slice patches: those were not using subclassing, they were patches to the existing type implementations. With subclassing you don't affect all uses of an object, but instead let the user control which uses should take advantage of the slice operations. Since the user also controls the objects which are kept alive this way, the main argument against Unicode slice objects goes away. This is different than patching the type itself and doesn't change the main object implementation in any way. Furthermore, it's possible to implement and provide such subclasses outside the Python core, which gives developers a lot more freedom. Regarding discussions on the py3k list: I'm not on that list, since I already get more email than I can manage. I am on the python-dev list, if you want to take up the discussions there. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 14:57:15 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 20 Mar 2008 13:57:15 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206021435.13.0.148068226304.issue1943@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well I'm not subscribed to the python-3k list either - too much traffic indeed. You can read and post into it with gmane for example: http://thread.gmane.org/gmane.comp.python.python-3000.devel/11768 (there is probably an NNTP gateway too) As for instrumenting the interpreter, this would tell us when and which strings are allocated, but not the precise effect it has on a modern CPU's memory subsystem (which is quite a complicated thing). Also, this is Py3k - we can't test any real-life applications until they are ported to it... (someone really motivated would have to learn Intel VTune or AMD CodeAnalyst and run such a "py3k real-life application" with it :-)) As for the explicit slicing approach, "explicit string views" have been discussed in 2006 on the python-3k list, including a proof-of-concept patch by Josiah Carlson - without any definitive pronouncement it seems. See the subthread here: http://mail.python.org/pipermail/python-3000/2006-August/003280.html The reason I'm bringing in those previous discussions is that, in theory, I'm all for much faster concatenation and slicing thanks to buffer sharing etc., but realistically the previous attempts have failed for various reasons (either technical or political). And since those optimizations are far from simple to implement and maintain, chances are they will not be attempted again, let alone accepted. I'd be happy to be proven wrong :) regards Antoine. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 15:34:34 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 20 Mar 2008 14:34:34 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206023674.55.0.839632337311.issue1943@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I've read the comments from Guido and Martin, but they don't convince me in changing my -1. As you say: it's difficult to get support for optimizations such a slicing and concatenation into the core. And that's exactly why I want to keep the door open for developers to add such support via extension modules. With the 8-bit string implementation this was never possible. With the Unicode implementation and the subclassing support for builtin types, it is possible to add support without having to go through all the hoops and discussions on python-dev or py3k lists. I'm also for making Python faster, but not if it limits future optimizations and produces dead-ends. The fact that such optimizations haven't been implemented yet doesn't really mean anything either - people are not yet using Unicode intensively enough to let the need arise. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 15:50:42 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 20 Mar 2008 14:50:42 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206024642.37.0.435129793613.issue1943@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, I'm not gonna try to defend my patch eternally :) I understand your opinion even if I find a bit disturbing that we refuse a concrete, actual optimization on the basis of future hypothetical ones. Since all the arguments have been laid down, I'll let other developers decide whether further discussion of this proposal is useful or not. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 16:29:11 2008 From: report at bugs.python.org (Collin Winter) Date: Thu, 20 Mar 2008 15:29:11 +0000 Subject: [issue2431] 2to3 is rather slow In-Reply-To: <1205991054.16.0.327808127723.issue2431@psf.upfronthosting.co.za> Message-ID: <1206026951.58.0.351250777992.issue2431@psf.upfronthosting.co.za> Collin Winter added the comment: Yes, and each new fixer makes it slower. The biggest problem is the pattern matching system, which tends to take 99% of the running time. I've talked to several people who are interested in optimizing 2to3 as a GSoC project, though, so I anticipate some speed ups coming through that. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 16:32:34 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 20 Mar 2008 15:32:34 +0000 Subject: [issue2329] ImportError: No module named _bsddb In-Reply-To: <1205774742.16.0.265427731372.issue2329@psf.upfronthosting.co.za> Message-ID: <1206027154.37.0.165639579487.issue2329@psf.upfronthosting.co.za> Gregory P. Smith added the comment: BerkeleyDB is detected when make runs setup.py. Look in the output from your make and you'll see a message about whether or not a useful BerkeleyDB library and include files were found. Typically this happens on linux distros because people do not have a bsddb-dev type package installed containing the header files needed to compile. ---------- nosy: +gregory.p.smith priority: -> low resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 16:41:51 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 20 Mar 2008 15:41:51 +0000 Subject: [issue2320] Race condition in subprocess using stdin In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za> Message-ID: <1206027711.99.0.954417362314.issue2320@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 16:56:03 2008 From: report at bugs.python.org (Jeff Balogh) Date: Thu, 20 Mar 2008 15:56:03 +0000 Subject: [issue2359] A Py3K warning for array.array.{read,write} is needed In-Reply-To: <1205782883.21.0.134767238935.issue2359@psf.upfronthosting.co.za> Message-ID: <1206028563.21.0.769237367214.issue2359@psf.upfronthosting.co.za> Changes by Jeff Balogh : Removed file: http://bugs.python.org/file9702/issue2359.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 17:00:16 2008 From: report at bugs.python.org (Jeff Balogh) Date: Thu, 20 Mar 2008 16:00:16 +0000 Subject: [issue2370] operator.{isCallable,sequenceIncludes} needs a fixer In-Reply-To: <1205784272.93.0.866002228926.issue2370@psf.upfronthosting.co.za> Message-ID: <1206028816.51.0.511873460862.issue2370@psf.upfronthosting.co.za> Jeff Balogh added the comment: Attaching a patch that adds deprecation warnings in trunk. Added file: http://bugs.python.org/file9787/operator-warnings.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 17:02:06 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 16:02:06 +0000 Subject: [issue2219] Py30a3: Possibly confusing message when module detection fails In-Reply-To: <1204531957.41.0.514268836397.issue2219@psf.upfronthosting.co.za> Message-ID: <1206028926.55.0.262954436014.issue2219@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Don't modify Modules/Setup*, do as the message says and modify setup.py. Search for "4, 5", and change that to "4, 6", then run configure and make and it will build without this message. I have done this against the py3k trunk and it built properly and did not display this message, so I think the current message is correct. As far as the bsddb 4.6 being broken, I spoke to Gregory and Martin and the story is that it is broken on some platforms, and isn't enabled by default because doing so breaks our buildbots on those platforms. I wouldn't expect the problem from F8 version, if nothing else because it's probably not a stock version, it's likely patched to the issues that Gregory has seen, if they impact F8. ---------- assignee: -> jafo nosy: +jafo priority: -> normal resolution: -> works for me status: open -> closed type: -> compile error __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 17:08:21 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 16:08:21 +0000 Subject: [issue2229] Search in 2.6 docs does not work In-Reply-To: <1204590780.07.0.631438682332.issue2229@psf.upfronthosting.co.za> Message-ID: <1206029301.69.0.447316745433.issue2229@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I just tested it under Linux Fedora 8 Firefox 3 and it shows results for the searches "move" and "rename" and got reasonable-looking results. ---------- nosy: +jafo priority: -> normal resolution: later -> works for me status: pending -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 17:19:18 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 16:19:18 +0000 Subject: [issue2234] cygwinccompiler.py fails for latest MinGW releases. In-Reply-To: <1204656219.89.0.991339984516.issue2234@psf.upfronthosting.co.za> Message-ID: <1206029958.67.0.151278080851.issue2234@psf.upfronthosting.co.za> Sean Reifschneider added the comment: This patch looks ok to me, but I'd like jlt63 to review it since they were the last to touch these regexes. ---------- assignee: -> jlt63 keywords: +easy nosy: +jafo, jlt63 priority: -> normal type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 17:25:13 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 16:25:13 +0000 Subject: [issue2236] Distutils' mkpath implementation ignoring the "mode" parameter In-Reply-To: <1204664208.81.0.312695054648.issue2236@psf.upfronthosting.co.za> Message-ID: <1206030313.56.0.293417949891.issue2236@psf.upfronthosting.co.za> Sean Reifschneider added the comment: This patch looks good to me. Greg? ---------- assignee: -> gward components: +Distutils -Library (Lib) keywords: +easy nosy: +gward, jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 17:27:46 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 20 Mar 2008 16:27:46 +0000 Subject: [issue2320] Race condition in subprocess using stdin In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za> Message-ID: <1206030466.28.0.44446465457.issue2320@psf.upfronthosting.co.za> Gregory P. Smith added the comment: This is easily reproducable on my OS X 10.4 macbookpro. However your suggested two lines with the os.pipe to lock to prevent the problem are a red herring... Locking those does not fix it. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 17:30:28 2008 From: report at bugs.python.org (Mark Summerfield) Date: Thu, 20 Mar 2008 16:30:28 +0000 Subject: [issue2219] Py30a3: Possibly confusing message when module detection fails In-Reply-To: <1206028926.55.0.262954436014.issue2219@psf.upfronthosting.co.za> Message-ID: <200803201624.45174.mark@qtrac.eu> Mark Summerfield added the comment: On 2008-03-20, Sean Reifschneider wrote: > Sean Reifschneider added the comment: > > Don't modify Modules/Setup*, do as the message says and modify setup.py. > Search for "4, 5", and change that to "4, 6", then run configure and > make and it will build without this message. I did as you said and it worked perfectly. Thanks! > I have done this against the py3k trunk and it built properly and did > not display this message, so I think the current message is correct. Yes you're right---it was just a bit surprising because in the past it has always been Modules/Setup that needed fixing. > As far as the bsddb 4.6 being broken, I spoke to Gregory and Martin and > the story is that it is broken on some platforms, and isn't enabled by > default because doing so breaks our buildbots on those platforms. > > I wouldn't expect the problem from F8 version, if nothing else because > it's probably not a stock version, it's likely patched to the issues > that Gregory has seen, if they impact F8. So presumably the Fedora maintainers will do the setup.py fix you suggested. Thanks! __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 17:40:11 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 20 Mar 2008 16:40:11 +0000 Subject: [issue1731717] race condition in subprocess module Message-ID: <1206031211.3.0.660181022947.issue1731717@psf.upfronthosting.co.za> Gregory P. Smith added the comment: """Basically it's OK to collect all the child exit codes if you record the results and return them when requested. This would mean that waitpid and the like would have to check a cached list of PIDs and exit statuses before actually waiting.""" note that this would still have problems. PIDs are recycled by the OS so as soon as you've waited on one and the process dies, the OS is free to launch a new process using it. If the new process happens to be another one of ours launched by subprocess that would be a problem. Make the cached map of pids -> exit codes be a map of pids -> [list of exit codes] instead? _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 20 17:45:23 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 20 Mar 2008 16:45:23 +0000 Subject: [issue1731717] race condition in subprocess module Message-ID: <1206031523.86.0.817922679513.issue1731717@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I am unable to reproduce this problem in today's trunk (2.6a) on OSX 10.4. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 20 17:47:08 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 20 Mar 2008 16:47:08 +0000 Subject: [issue2381] test_subprocess fails if your sys.executable is on a path with a space in it In-Reply-To: <1205813955.12.0.0111122307325.issue2381@psf.upfronthosting.co.za> Message-ID: <1206031628.77.0.376219266088.issue2381@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: -> gregory.p.smith keywords: +easy nosy: +gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 18:20:47 2008 From: report at bugs.python.org (Michael Bishop) Date: Thu, 20 Mar 2008 17:20:47 +0000 Subject: [issue2433] Merge audio modules In-Reply-To: <1206033647.05.0.831244595628.issue2433@psf.upfronthosting.co.za> Message-ID: <1206033647.05.0.831244595628.issue2433@psf.upfronthosting.co.za> New submission from Michael Bishop : There are many duplicate functions throughout the many audio modules. I plan to merge relevant functions into 2 modules; a C module and a py module. Once I go through the audio modules in detail, I'll post my plan here. Reference: http://www.python.org/dev/peps/pep-3108/ http://mail.python.org/pipermail/python-3000/2007-January/005295.html ---------- components: Library (Lib) messages: 64182 nosy: MichaelBishop, brett.cannon severity: normal status: open title: Merge audio modules type: behavior versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 18:37:54 2008 From: report at bugs.python.org (David Wolever) Date: Thu, 20 Mar 2008 17:37:54 +0000 Subject: [issue2431] 2to3 is rather slow In-Reply-To: <1205991054.16.0.327808127723.issue2431@psf.upfronthosting.co.za> Message-ID: <1206034674.09.0.908592050166.issue2431@psf.upfronthosting.co.za> David Wolever added the comment: Martin and I talked about this, and I'm going to try loading the first node of each tree generated by the PATTERNs into a dictionary, then when the tree is walked, only fixers which could potentially match the current node are executed. ---------- assignee: collinwinter -> David Wolever __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 18:40:03 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 17:40:03 +0000 Subject: [issue2238] TypeError instead of SyntaxError for syntactically invalid gen exp In-Reply-To: <1204678396.78.0.214556638013.issue2238@psf.upfronthosting.co.za> Message-ID: <1206034803.52.0.842853585755.issue2238@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Back-ported to 2.5 and committed in rev 61675. ---------- nosy: +jafo priority: -> normal status: pending -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 18:53:46 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 17:53:46 +0000 Subject: [issue1524] os.system() fails for commands with multiple quoted file names In-Reply-To: <1196367416.9.0.40290581495.issue1524@psf.upfronthosting.co.za> Message-ID: <1206035626.71.0.315321904114.issue1524@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I would agree with Georg that there isn't anything we can do about this. I had someone try from the Windows XP command shell and: "dir" "/w" reports that it can't run the combined command, where: dir /w works just fine. My conclusions are: This is a bug in the Windows shell (which os.system hands the command to). There is a work-around using "call" as pointed out by Jean-Fran?ois The subprocess module is a better match for this, as you pass a tuple to make quoting unnecessary. According to the os module documentation, using subprocess is recommended in preference to using os.system(). ---------- nosy: +jafo priority: -> normal resolution: -> wont fix status: open -> closed type: crash -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 18:58:44 2008 From: report at bugs.python.org (Collin Winter) Date: Thu, 20 Mar 2008 17:58:44 +0000 Subject: [issue2431] 2to3 is rather slow In-Reply-To: <1205991054.16.0.327808127723.issue2431@psf.upfronthosting.co.za> Message-ID: <1206035924.51.0.848725324049.issue2431@psf.upfronthosting.co.za> Collin Winter added the comment: Keep in mind that not all fixers use PATTERN, for example fix_ne. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 19:01:48 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 20 Mar 2008 18:01:48 +0000 Subject: [issue2434] Improve platform.win32_ver() support for Python installations without win32all installed In-Reply-To: <1206036108.55.0.836121588011.issue2434@psf.upfronthosting.co.za> Message-ID: <1206036108.55.0.836121588011.issue2434@psf.upfronthosting.co.za> New submission from Marc-Andre Lemburg : platform should use _winreg and sys.getwindowsversion() to emulate the missing win32all APIs. ---------- assignee: lemburg components: Library (Lib) messages: 64187 nosy: lemburg severity: normal status: open title: Improve platform.win32_ver() support for Python installations without win32all installed type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 19:03:25 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 18:03:25 +0000 Subject: [issue2243] urllib2. strange behavior for getting chuncked transfer-ecnoded data In-Reply-To: <1204798625.87.0.148151937521.issue2243@psf.upfronthosting.co.za> Message-ID: <1206036205.75.0.41270010989.issue2243@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- assignee: -> georg.brandl nosy: +georg.brandl priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 19:03:49 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 20 Mar 2008 18:03:49 +0000 Subject: [issue2434] Improve platform.win32_ver() support for Python installations without win32all installed In-Reply-To: <1206036108.55.0.836121588011.issue2434@psf.upfronthosting.co.za> Message-ID: <1206036229.14.0.760339529868.issue2434@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Checked in as r61674 and r61676 along with some other improvements for detecting the machine type on Windows. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 19:16:13 2008 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Thu, 20 Mar 2008 18:16:13 +0000 Subject: [issue1328] Force BOM option in UTF output. In-Reply-To: <1193353176.1.0.485065586233.issue1328@psf.upfronthosting.co.za> Message-ID: <1206036973.18.0.778841029058.issue1328@psf.upfronthosting.co.za> Walter D?rwald added the comment: I don't see exactly what James is proposing. > For my needs, I would like the decoding parts of the utf_8 module > to treat an initial BOM as an optional signature and skip it if > there is one (just like the utf_8_sig decoder). In fact I have > a working patch that replaces the utf_8_sig decode, > IncrementalDecoder and StreamReader components by direct > transplants from utf_8_sig (as recently repaired -- there was a > SteamReader error). I've you want a decoder that behave like the utf-8-sig decoder, use the utf-8-sig decoder. I don't see how changing the utf-8 decoder helps here. > I can imagine there might be utf_8 client code out there which > expects to see a leading U+feff as (perhaps) a clue that the > output should be returned with a BOM-signature (say) to > accomodate the guessed input requirements of the remote > correspondant. In this case use UTF-8: The leading BOM will be passed to the application. > I can just live with code like > if input[0] == u"\ufeff": > input=input[1:} > spread around, and of course slightly different for incremental > and stream inputs. Can you post an example that requires this code? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 19:38:19 2008 From: report at bugs.python.org (Forest Wilkinson) Date: Thu, 20 Mar 2008 18:38:19 +0000 Subject: [issue1641] asyncore delayed calls feature In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za> Message-ID: <1206038299.21.0.0456771580556.issue1641@psf.upfronthosting.co.za> Changes by Forest Wilkinson : ---------- nosy: +forest __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 19:45:18 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 20 Mar 2008 18:45:18 +0000 Subject: [issue2435] pybench does not run anymore In-Reply-To: <1206038718.43.0.678632564965.issue2435@psf.upfronthosting.co.za> Message-ID: <1206038718.43.0.678632564965.issue2435@psf.upfronthosting.co.za> New submission from Antoine Pitrou : I get this on py3k: $ ./python Tools/pybench/pybench.py Traceback (most recent call last): File "Tools/pybench/pybench.py", line 391, in import Setup File "/home/antoine/py3k/unialloc/Tools/pybench/Setup.py", line 34, in from With import * ImportError: No module named With It seems like the With.py file in Tools/pybench was not added as part of an SVN merge from the 2.x trunk. ---------- components: Demos and Tools messages: 64190 nosy: pitrou severity: normal status: open title: pybench does not run anymore type: crash versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 19:57:43 2008 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Thu, 20 Mar 2008 18:57:43 +0000 Subject: [issue1477] UnicodeDecodeError that cannot be caught in narrow unicode builds In-Reply-To: <1195593459.02.0.388666867716.issue1477@psf.upfronthosting.co.za> Message-ID: <1206039463.07.0.649530677806.issue1477@psf.upfronthosting.co.za> Walter D?rwald added the comment: For a wide build, the code if (x <= 0xffff) *p++ = (Py_UNICODE) x; else { *p++ = (Py_UNIC0DE) x; looks strange. Furthermore with the patch applied Python no longer complains about illegal code points: >>> ur'\U11111111' u'\u1c04\udd11' __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 19:58:22 2008 From: report at bugs.python.org (Miki Tebeka) Date: Thu, 20 Mar 2008 18:58:22 +0000 Subject: [issue2227] time.strptime too strict? should it assume current year? In-Reply-To: <1204580486.17.0.196786227347.issue2227@psf.upfronthosting.co.za> Message-ID: <1206039502.3.0.13948201013.issue2227@psf.upfronthosting.co.za> Miki Tebeka added the comment: Here is a patch, hope it'll make it to 2.6 ---------- keywords: +patch nosy: +tebeka Added file: http://bugs.python.org/file9788/_strptime.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 20:08:19 2008 From: report at bugs.python.org (Eric Smith) Date: Thu, 20 Mar 2008 19:08:19 +0000 Subject: [issue2436] Should __future__ print_function be valid in 3.0? In-Reply-To: <1206040099.45.0.826679091629.issue2436@psf.upfronthosting.co.za> Message-ID: <1206040099.45.0.826679091629.issue2436@psf.upfronthosting.co.za> New submission from Eric Smith : Should this be accepted in 3.0, and become a no-op: from __future__ import print_function ? It might make using code in 2.6 and 3.0 easier, since you would not have to delete this line. I note that: from __future__ import with_statement is already valid in 3.0. ---------- assignee: eric.smith components: Interpreter Core messages: 64193 nosy: eric.smith priority: normal severity: normal status: open title: Should __future__ print_function be valid in 3.0? versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 20:10:34 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 20 Mar 2008 19:10:34 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206040234.4.0.995216977738.issue1943@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Regarding the benchmark: You can instrument a 2.x version of the interpreter to build the data set and then have the test load this data set in Py3k and have it replay the allocation/deallocation in the same way it was done on the 2.x system. I also expect that patch #2321 will have an effect on the performance since that patch changed the way memory allocation of the buffer was done (from using the system malloc() to using pymalloc's allocator for the buffer as well). __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 20:10:53 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 20 Mar 2008 19:10:53 +0000 Subject: [issue2436] Should __future__ print_function be valid in 3.0? In-Reply-To: <1206040099.45.0.826679091629.issue2436@psf.upfronthosting.co.za> Message-ID: <1206040253.76.0.242229739301.issue2436@psf.upfronthosting.co.za> Christian Heimes added the comment: Yes, you *must* implement it. From http://docs.python.org/lib/module-future.html No feature description will ever be deleted from __future__. ---------- nosy: +tiran resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 20:28:24 2008 From: report at bugs.python.org (Thomas Heller) Date: Thu, 20 Mar 2008 19:28:24 +0000 Subject: [issue1971] ctypes exposing the pep 3118 buffer interface In-Reply-To: <1201680953.7.0.68287385548.issue1971@psf.upfronthosting.co.za> Message-ID: <1206041304.4.0.484664340783.issue1971@psf.upfronthosting.co.za> Thomas Heller added the comment: Travis, can you please review this / when can you review this issue for compliance with pep 3118? ---------- nosy: +teoliphant __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 20:36:50 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 20 Mar 2008 19:36:50 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206041810.78.0.198129890024.issue1943@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You are right, #2321 made the numbers a bit tighter: With a small string: ./python -m timeit -s "s=open('INTBENCH', 'r').read()" "s.split()" -> Unpatched py3k: 23.1 usec per loop -> Freelist patch: 21.3 usec per loop -> PyVarObject patch: 20.5 usec per loop With a medium-sized string: ./python -m timeit -s "s=open('LICENSE', 'r').read()" "s.split()" -> Unpatched py3k: 406 usec per loop -> Freelist patch: 353 usec per loop -> PyVarObject patch: 314 usec per loop With a long string: ./python -m timeit -s "s=open('Misc/HISTORY', 'r').read()" "s.split()" -> Unpatched py3k: 22.7 msec per loop -> Freelist patch: 24 msec per loop -> PyVarObject patch: 20.6 msec per loop stringbench3k: -> Unpatched py3k: 266 seconds -> Freelist patch: 264 seconds -> PyVarObject patch: 249 seconds Regarding your benchmarking suggestion, this would certainly be an interesting thing to do, but I fear it is also much more than I'm willing to do... I'm going to post the updated patches. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 20:37:36 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 20 Mar 2008 19:37:36 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206041856.78.0.544711960645.issue1943@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Added file: http://bugs.python.org/file9789/unialloc4.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 20:37:55 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 20 Mar 2008 19:37:55 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206041875.96.0.986961036971.issue1943@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Added file: http://bugs.python.org/file9790/freelists2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 20:38:00 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 20 Mar 2008 19:38:00 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206041880.84.0.108189231635.issue1943@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file9296/unialloc.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 20:38:06 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 20 Mar 2008 19:38:06 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206041886.49.0.832454591406.issue1943@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file9332/freelists.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 20:38:14 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 20 Mar 2008 19:38:14 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206041894.28.0.847501683114.issue1943@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file9441/unialloc3.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 20:38:10 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 20 Mar 2008 19:38:10 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206041890.79.0.737957766801.issue1943@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file9419/unialloc2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 20:43:32 2008 From: report at bugs.python.org (Andy Harrington) Date: Thu, 20 Mar 2008 19:43:32 +0000 Subject: [issue1038909] pydoc method documentation lookup enhancement Message-ID: <1206042212.15.0.158872404297.issue1038909@psf.upfronthosting.co.za> Andy Harrington added the comment: After going to the sprint Monday, I am working on this as my first patch. There is no test file for pydoc. ?? ---------- nosy: +andyharrington _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 20 20:55:05 2008 From: report at bugs.python.org (David Wolever) Date: Thu, 20 Mar 2008 19:55:05 +0000 Subject: [issue2431] 2to3 is rather slow In-Reply-To: <1205991054.16.0.327808127723.issue2431@psf.upfronthosting.co.za> Message-ID: <1206042905.66.0.282349491363.issue2431@psf.upfronthosting.co.za> David Wolever added the comment: A patch so that, on each node, only fixers who's head node could match this node are executed. It's still hacky and ugly, but a decent POC. ---------- keywords: +patch Added file: http://bugs.python.org/file9791/fixer_head_node_lookup.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 21:23:15 2008 From: report at bugs.python.org (Bill Janssen) Date: Thu, 20 Mar 2008 20:23:15 +0000 Subject: [issue2437] Distutils runtime_library_dirs broken on Windows In-Reply-To: <1206044595.46.0.100105317073.issue2437@psf.upfronthosting.co.za> Message-ID: <1206044595.46.0.100105317073.issue2437@psf.upfronthosting.co.za> New submission from Bill Janssen : The distutils.unixcompiler.runtime_library_dirs() function, used when compiling with MinGW or Cygwin on Windows, fails catastrophically because the return result of sysconfig.get_config_var("CC") returns None. It should probably be prepared for that eventuality. ---------- messages: 64200 nosy: janssen severity: normal status: open title: Distutils runtime_library_dirs broken on Windows __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 21:23:48 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 20:23:48 +0000 Subject: [issue2244] urllib and urllib2 decode userinfo multiple times In-Reply-To: <1204819810.33.0.413464262118.issue2244@psf.upfronthosting.co.za> Message-ID: <1206044628.3.0.682336448573.issue2244@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Fred: You most recently touched the code impacted by this test, does this sound reasonable? ---------- assignee: -> fdrake nosy: +fdrake, jafo priority: -> normal type: behavior -> resource usage versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 21:23:56 2008 From: report at bugs.python.org (Bill Janssen) Date: Thu, 20 Mar 2008 20:23:56 +0000 Subject: [issue2437] Distutils runtime_library_dirs broken on Windows In-Reply-To: <1206044595.46.0.100105317073.issue2437@psf.upfronthosting.co.za> Message-ID: <1206044636.86.0.548125891815.issue2437@psf.upfronthosting.co.za> Changes by Bill Janssen : ---------- components: +Distutils priority: -> high type: -> crash versions: +Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 21:29:20 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 20:29:20 +0000 Subject: [issue2219] Py30a3: Possibly confusing message when module detection fails In-Reply-To: <1204531957.41.0.514268836397.issue2219@psf.upfronthosting.co.za> Message-ID: <1206044960.73.0.827480172671.issue2219@psf.upfronthosting.co.za> Sean Reifschneider added the comment: It's actually been quite a while since it changed from being Modules/Setup to being in setup.py, I think a couple of years at least. And, yes, I realize that Fedora is changing the Modules/Setup file in their SRPM, but with Python 3k they will probably be changing the setup.py. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 21:32:21 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 20:32:21 +0000 Subject: [issue2211] Cookie.Morsel interface needs update In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za> Message-ID: <1206045141.16.0.381015134689.issue2211@psf.upfronthosting.co.za> Sean Reifschneider added the comment: I'm going to push this to pending until you can get a patch. Thanks, Jamie. ---------- nosy: +jafo priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 21:32:28 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 20:32:28 +0000 Subject: [issue2211] Cookie.Morsel interface needs update In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za> Message-ID: <1206045148.53.0.812251012712.issue2211@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 21:38:32 2008 From: report at bugs.python.org (Patrick) Date: Thu, 20 Mar 2008 20:38:32 +0000 Subject: [issue2438] subprocess.Popen with wildcard arguments In-Reply-To: <1206045512.59.0.667907711794.issue2438@psf.upfronthosting.co.za> Message-ID: <1206045512.59.0.667907711794.issue2438@psf.upfronthosting.co.za> New submission from Patrick : When using wildcards as arguments to the processes being spawned by Popen, it seems to interpret them as hard literals. IE, when doing something like: >>> import subprocess >>> output = subprocess.Popen(['ls', '*'], stdout=subprocess.PIPE).communicate()[0] ls: *: No such file or directory >>> ---------- components: Library (Lib) messages: 64204 nosy: pbrandt severity: normal status: open title: subprocess.Popen with wildcard arguments type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 21:45:46 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 20:45:46 +0000 Subject: [issue2248] quit() method of SMTP instance (of smtplib) doesn't return it's result In-Reply-To: <1204875778.72.0.769426067571.issue2248@psf.upfronthosting.co.za> Message-ID: <1206045946.5.0.898420644893.issue2248@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Kei: The documentation does not say that quit() returns a value, so the current behavior is correct. However, SMTP defines a return value for QUIT, so there is a case for smtplib.quit() returning that value. This patch does need a documentation change to Doc/library/smtplib.rst Guido: You wrote and last touched this code, any objections? ---------- assignee: -> gvanrossum nosy: +gvanrossum, jafo priority: -> normal type: -> feature request __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 21:49:32 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Thu, 20 Mar 2008 20:49:32 +0000 Subject: [issue2250] rlcompleter raises Exception on bad input In-Reply-To: <1204886997.65.0.75088007868.issue2250@psf.upfronthosting.co.za> Message-ID: <1206046172.37.0.368714954386.issue2250@psf.upfronthosting.co.za> Sean Reifschneider added the comment: Is a straightforward patch, but I'd like NAS to comment on the change in behavior. Probably would also need a documentation change, are you up for doing that Lorenz? ---------- assignee: -> nascheme keywords: +easy nosy: +jafo, nascheme priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 21:50:18 2008 From: report at bugs.python.org (Jim Jewett) Date: Thu, 20 Mar 2008 20:50:18 +0000 Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za> Message-ID: <1206046218.46.0.597452080235.issue1657@psf.upfronthosting.co.za> Jim Jewett added the comment: Is pyepoll a good prefix? To me, it looks a lot like the _Py and Py reservered namespaces, but not quite... ---------- nosy: +jimjjewett __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 21:58:33 2008 From: report at bugs.python.org (Paul Moore) Date: Thu, 20 Mar 2008 20:58:33 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za> Message-ID: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za> New submission from Paul Moore : This patch adds a new get_data function to the pkgutil module, allowing access to data stored in the package directory. It wraps the PEP 302 loader "get_data" function, so that it works with such loaders (for example, zipimport). The patch includes documentation and tests (I created a new test_pkgutil test module, but did not add tests for the existing pkgutil functionality). All tests pass on Windows against svn rev 61679 (except test_tcl, which was skipped as I didn't build TCL support). ---------- components: Library (Lib) files: pkgutil.patch keywords: patch messages: 64208 nosy: pmoore severity: normal status: open title: Patch to add a get_data function to pkgutil type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file9792/pkgutil.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 21:58:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 20 Mar 2008 20:58:51 +0000 Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za> Message-ID: <1206046731.34.0.48299809515.issue1657@psf.upfronthosting.co.za> Christian Heimes added the comment: I had to use some kind of prefix to avoid naming collisions with the epoll_* functions for the epoll header file. pyepoll sounded reasonable to me. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 22:22:27 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 20 Mar 2008 21:22:27 +0000 Subject: [issue2435] pybench does not run anymore In-Reply-To: <1206038718.43.0.678632564965.issue2435@psf.upfronthosting.co.za> Message-ID: <1206048147.65.0.655122131718.issue2435@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Corrected in r61680. Thanks for the report! ---------- nosy: +amaury.forgeotdarc resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 22:25:56 2008 From: report at bugs.python.org (Neil Schemenauer) Date: Thu, 20 Mar 2008 21:25:56 +0000 Subject: [issue628842] Deprecate PyNumber_Check Message-ID: <1206048356.46.0.675969289141.issue628842@psf.upfronthosting.co.za> Changes by Neil Schemenauer : ---------- status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Mar 20 22:36:28 2008 From: report at bugs.python.org (Phillip J. Eby) Date: Thu, 20 Mar 2008 21:36:28 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za> Message-ID: <1206048988.67.0.828985382937.issue2439@psf.upfronthosting.co.za> Phillip J. Eby added the comment: Hi Paul. AFAICT, this doesn't look like it will actually work for filesystem data. get_loader() will return None for "regular", filesystem-installed modules, at least in Python 2.5. Perhaps you should add a test case for that? ---------- nosy: +pje __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 23:00:42 2008 From: report at bugs.python.org (Trent Nelson) Date: Thu, 20 Mar 2008 22:00:42 +0000 Subject: [issue2440] Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t. In-Reply-To: <1206050442.67.0.496216797611.issue2440@psf.upfronthosting.co.za> Message-ID: <1206050442.67.0.496216797611.issue2440@psf.upfronthosting.co.za> New submission from Trent Nelson : test_getargs2 fails on Win x64: test_getargs2 is failing on Windows x64: test test_getargs2 failed -- Traceback (most recent call last): File "S:\buildbots\python.x64\3.0.nelson-win64\build\lib\test\test_getargs2.py", line 190, in test_n self.failUnlessEqual(99, getargs_n(Long())) TypeError: 'Long' object cannot be interpreted as an integer The problem is twofold: case 'n' on Win x64 (where SIZEOF_SIZE_T != SIZEOF_LONG) had a broken code path and needed updating. Also, the fallback to 'l' for systems where SIZEOF_SIZE_T == SIZEOF_LONG wasn't correct -- it should still do a PyNumber_Index() check, and then use PyLong_AsSize_t() to extract the value. The attached patch corrects the behaviour on 32-bit and 64-bit systems, including Windows. However, it has now uncovered another bug in Windows x64: >>> from _testcapi import getargs_n >>> getargs_n(sys.maxsize) 9223372036854775807 >>> getargs_n(-sys.maxsize) 1 >>> getargs_n(-sys.maxsize-1) 0 After a bit of investigation with Martin, the logic in PyLong_AsSize_t() is incorrect and needs to be reworked to handle negative maximums properly. ---------- components: Interpreter Core files: getargs_and_abstract.patch keywords: patch, patch messages: 64212 nosy: Trent.Nelson, loewis severity: normal status: open title: Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t. versions: Python 3.0 Added file: http://bugs.python.org/file9793/getargs_and_abstract.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 23:01:42 2008 From: report at bugs.python.org (Trent Nelson) Date: Thu, 20 Mar 2008 22:01:42 +0000 Subject: [issue2440] Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t. In-Reply-To: <1206050442.67.0.496216797611.issue2440@psf.upfronthosting.co.za> Message-ID: <1206050502.99.0.262212261078.issue2440@psf.upfronthosting.co.za> Changes by Trent Nelson : Removed file: http://bugs.python.org/file9793/getargs_and_abstract.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 23:07:12 2008 From: report at bugs.python.org (Trent Nelson) Date: Thu, 20 Mar 2008 22:07:12 +0000 Subject: [issue2440] Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t. In-Reply-To: <1206050442.67.0.496216797611.issue2440@psf.upfronthosting.co.za> Message-ID: <1206050832.14.0.717137312987.issue2440@psf.upfronthosting.co.za> Trent Nelson added the comment: Attached a slightly cleaner patch. Added file: http://bugs.python.org/file9794/getargs_and_abstract.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 23:07:50 2008 From: report at bugs.python.org (Trent Nelson) Date: Thu, 20 Mar 2008 22:07:50 +0000 Subject: [issue2440] Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t. In-Reply-To: <1206050442.67.0.496216797611.issue2440@psf.upfronthosting.co.za> Message-ID: <1206050870.91.0.920161188533.issue2440@psf.upfronthosting.co.za> Changes by Trent Nelson : __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 23:07:56 2008 From: report at bugs.python.org (Trent Nelson) Date: Thu, 20 Mar 2008 22:07:56 +0000 Subject: [issue2440] Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t. In-Reply-To: <1206050442.67.0.496216797611.issue2440@psf.upfronthosting.co.za> Message-ID: <1206050876.1.0.449138824255.issue2440@psf.upfronthosting.co.za> Changes by Trent Nelson : Removed file: http://bugs.python.org/file9794/getargs_and_abstract.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 23:09:18 2008 From: report at bugs.python.org (Trent Nelson) Date: Thu, 20 Mar 2008 22:09:18 +0000 Subject: [issue2440] Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t. In-Reply-To: <1206050442.67.0.496216797611.issue2440@psf.upfronthosting.co.za> Message-ID: <1206050958.67.0.907627128016.issue2440@psf.upfronthosting.co.za> Trent Nelson added the comment: Attach a slightly cleaner patch, take 2. Added file: http://bugs.python.org/file9795/getargs_and_abstract.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 23:13:05 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 20 Mar 2008 22:13:05 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206051185.04.0.300326312593.issue1943@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Thanks for running the tests again. The use of pymalloc for the buffer made a significant difference indeed. I expect that more can be had by additionally tweaking KEEPALIVE_SIZE_LIMIT. It is interesting to see that the free list patch only appears to provide better timings for the "smaller" strings tests. I couldn't find the INTBENCH file anywhere in the Python source tree, but here's the distribution of the words of the latter two files: Dev-Python/LICENSE: ------------------------------------------------------------------------ Length: [Count] 0----1----2----3----4----5----6----7----8----9----10 * 10% 1: [ 28] === 2: [ 350] ================================================= 3: [ 354] ================================================== 4: [ 190] ========================== 5: [ 191] ========================== 6: [ 158] ====================== 7: [ 164] ======================= 8: [ 132] ================== 9: [ 127] ================= 10: [ 102] ============== 11: [ 39] ===== 12: [ 34] ==== 13: [ 21] == 14: [ 10] = 15: [ 10] = 16: [ 0] 17: [ 0] 18: [ 1] 19: [ 0] 20: [ 0] 21: [ 1] 22: [ 0] 23: [ 0] 24: [ 0] 25: [ 1] 26: [ 1] 27: [ 1] 28: [ 0] 29: [ 1] 30: [ 0] 31: [ 0] 32: [ 0] 33: [ 0] 34: [ 0] 35: [ 0] 36: [ 2] 37: [ 0] 38: [ 0] 39: [ 1] 40: [ 0] 41: [ 0] 42: [ 0] 43: [ 1] 44: [ 1] 45: [ 0] 46: [ 0] 47: [ 0] 48: [ 0] 49: [ 0] 50: [ 1] 51: [ 0] 52: [ 0] 53: [ 0] 54: [ 0] 55: [ 0] 56: [ 0] 57: [ 0] 58: [ 0] 59: [ 0] 60: [ 0] 61: [ 0] 62: [ 0] 63: [ 1] Dev-Python/Misc/HISTORY: ------------------------------------------------------------------------ Length: [Count] 0----1----2----3----4----5----6----7----8----9----10 * 10% 1: [ 6853] ================== 2: [13920] ===================================== 3: [18401] ================================================== 4: [12626] ================================== 5: [ 9545] ========================= 6: [ 9348] ========================= 7: [ 9625] ========================== 8: [ 7351] =================== 9: [ 5353] ============== 10: [ 3266] ======== 11: [ 1947] ===== 12: [ 1336] === 13: [ 983] == 14: [ 638] = 15: [ 408] = 16: [ 288] 17: [ 286] 18: [ 216] 19: [ 176] 20: [ 147] 21: [ 120] 22: [ 116] 23: [ 85] 24: [ 89] 25: [ 70] 26: [ 44] 27: [ 59] 28: [ 39] 29: [ 32] 30: [ 65] 31: [ 23] 32: [ 26] 33: [ 28] 34: [ 19] 35: [ 18] 36: [ 9] 37: [ 18] 38: [ 5] 39: [ 10] 40: [ 9] 41: [ 9] 42: [ 1] 43: [ 1] 44: [ 8] 45: [ 4] 46: [ 5] 47: [ 5] 48: [ 3] 49: [ 3] 50: [ 4] 51: [ 0] 52: [ 0] 53: [ 2] 54: [ 0] 55: [ 0] 56: [ 4] 57: [ 2] 58: [ 4] 59: [ 1] 60: [ 0] 61: [ 1] 62: [ 0] 63: [ 1] 64: [ 1] 65: [ 9] 66: [ 1] 67: [ 1] 68: [ 0] 69: [ 0] 70: [ 16] 71: [ 1] 72: [ 0] 73: [ 1] Compare that to a typical Python module source file... Dev-Python/Lib/urllib.py: ------------------------------------------------------------------------ Length: [Count] 0----1----2----3----4----5----6----7----8----9----10 * 10% 1: [ 806] ================================================== 2: [ 672] ========================================= 3: [ 675] ========================================= 4: [ 570] =================================== 5: [ 531] ================================ 6: [ 501] =============================== 7: [ 296] ================== 8: [ 393] ======================== 9: [ 246] =============== 10: [ 147] ========= 11: [ 150] ========= 12: [ 102] ====== 13: [ 90] ===== 14: [ 116] ======= 15: [ 61] === 16: [ 51] === 17: [ 45] == 18: [ 38] == 19: [ 31] = 20: [ 39] == 21: [ 24] = 22: [ 18] = 23: [ 18] = 24: [ 23] = 25: [ 17] = 26: [ 15] 27: [ 13] 28: [ 14] 29: [ 11] 30: [ 9] 31: [ 7] 32: [ 1] 33: [ 6] 34: [ 10] 35: [ 2] 36: [ 4] 37: [ 3] 38: [ 6] 39: [ 1] 40: [ 0] 41: [ 1] 42: [ 5] 43: [ 0] 44: [ 0] 45: [ 0] 46: [ 0] 47: [ 0] 48: [ 2] 49: [ 0] 50: [ 1] 51: [ 1] 52: [ 2] The distributions differ a lot, but they both show that typical strings (both in English text and Python program code) have a length of < 25 characters. Setting KEEPALIVE_SIZE_LIMIT to 32 should cover most of those cases while still keeping the memory load within bounds. Raising the free list limit to e.g. 2048 would cause at most 64kB to be used by the free list - which is well within bounds of any modern CPU L2 cache. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 23:19:52 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 20 Mar 2008 22:19:52 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206051592.13.0.0158174387286.issue1943@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, of course most words in most languages are below 20 characters. Hence most strings containing words are also below 20 chars. But strings can also contain whole lines (e.g. decoding of various Internet protocols), which are statistically below 80 chars. I took that into account in the freelists patch (it keeps lots of <15 char strings in memory, and a few <90 char strings), which as you can see still yields rather little benefits :) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 23:21:41 2008 From: report at bugs.python.org (James G. sack (jim)) Date: Thu, 20 Mar 2008 22:21:41 +0000 Subject: [issue1328] Force BOM option in UTF output. In-Reply-To: <1193353176.1.0.485065586233.issue1328@psf.upfronthosting.co.za> Message-ID: <1206051701.68.0.0973039961354.issue1328@psf.upfronthosting.co.za> James G. sack (jim) added the comment: > Can you post an example that requires this code? This is not a big issue, and it wouldn't hurt if it got declared "go away and come back later if you have patch, test, docs, and a convincing use case". ..But, for the record.. Suppose I want to both read and write some utf8. It is unknown whether the input has a BOM, but it is known to be utf8. I want to write utf8 without any BOM. I see two options, which I find slightly ugly/annoying/error-prone: a) Use 2 separate encodings: read via utf_8_sig so as to transparently accept input with/without BOM; use utf_8 on output to not emit any BOM. b) Use utf_8 for read and write and explicitly check for and discard leading BOM on input if any. What _I_ would prefer is that utf_8 would ignore a BOM, if present (just like utf_8_sig). (What I was talking about in my last post was a complication in consideration of someone else who would prefer otherwise, or of code that might break upon my change.) Regards, ..jim __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 23:37:27 2008 From: report at bugs.python.org (Carlos Eduardo de Paula) Date: Thu, 20 Mar 2008 22:37:27 +0000 Subject: [issue2441] Mac build_install.py script fetches unavailable SQLite version In-Reply-To: <1206052647.34.0.885320572694.issue2441@psf.upfronthosting.co.za> Message-ID: <1206052647.34.0.885320572694.issue2441@psf.upfronthosting.co.za> New submission from Carlos Eduardo de Paula : The build_installer.py script, used to create MacPython installers tries to fetch a SQLite version that is not available anymore. I provided a patch with an updated version and its corresponding hash. Maybe this should be backported to 2.5 and 2.6 branches. ---------- components: Installation files: build_installer.diff keywords: patch messages: 64218 nosy: carlosedp severity: normal status: open title: Mac build_install.py script fetches unavailable SQLite version type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file9796/build_installer.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 23:51:53 2008 From: report at bugs.python.org (Paul Moore) Date: Thu, 20 Mar 2008 22:51:53 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za> Message-ID: <1206053513.95.0.349603926663.issue2439@psf.upfronthosting.co.za> Paul Moore added the comment: I'm not sure I understand. It uses pkgutil.get_loader, which returns a wrapper for filesystem modules. You pointed me to it. It seems to work, that's what test_getdata_filesys is testing in test_pkgutil.py. Can you supply a testcase that fails? (BTW, this is a patch for the trunk - ie 2.6-to be. I can't see why 2.5 would be different, but maybe that's the problem for you?) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 20 23:54:23 2008 From: report at bugs.python.org (Dave Peterson) Date: Thu, 20 Mar 2008 22:54:23 +0000 Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails Message-ID: <1206053663.45.0.434350092276.issue1424152@psf.upfronthosting.co.za> Changes by Dave Peterson : ---------- nosy: +dpeterson _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 21 00:01:17 2008 From: report at bugs.python.org (Jack Diederich) Date: Thu, 20 Mar 2008 23:01:17 +0000 Subject: [issue2366] Fixer for new metaclass syntax is needed In-Reply-To: <1205783672.52.0.982802083184.issue2366@psf.upfronthosting.co.za> Message-ID: <1206054077.66.0.570436764772.issue2366@psf.upfronthosting.co.za> Jack Diederich added the comment: New patch that does more. Collin, could you take a look at the fixer? I listed some stumbling blocks at the top (and at least one bug in 2to3). The fixer seems to work fine on actual files but the unit tests that use strings do nothing. Thanks. Added file: http://bugs.python.org/file9797/fix_metaclass.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 00:03:01 2008 From: report at bugs.python.org (Eric Smith) Date: Thu, 20 Mar 2008 23:03:01 +0000 Subject: [issue2436] Should __future__ print_function be valid in 3.0? In-Reply-To: <1206040099.45.0.826679091629.issue2436@psf.upfronthosting.co.za> Message-ID: <1206054180.99.0.420970703499.issue2436@psf.upfronthosting.co.za> Eric Smith added the comment: Implemented in r61682. ---------- resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 00:28:27 2008 From: report at bugs.python.org (Christopher Li) Date: Thu, 20 Mar 2008 23:28:27 +0000 Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails Message-ID: <1206055707.94.0.222386014535.issue1424152@psf.upfronthosting.co.za> Christopher Li added the comment: In cast it is not obvious. I already attached the purpose patch "http-tunnel-urllib" in the bug. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 21 00:28:52 2008 From: report at bugs.python.org (Phillip J. Eby) Date: Thu, 20 Mar 2008 23:28:52 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za> Message-ID: <1206055732.01.0.864252639363.issue2439@psf.upfronthosting.co.za> Phillip J. Eby added the comment: Oops, my bad. I'm thinking of an entirely unrelated get_loader() function. Meanwhile, I misread your patch entirely, and thought you had some dead code for os.path processing that is in fact live. So there is "another" problem (really the only one) that I spotted on this re-read. Your patch is calling load_module() even if the module is already in sys.modules. This will *reload* the module, potentially causing problems elsewhere in the system. You can test this by adding an assertion to your test's load_module(), that the module isn't already in sys.modules. Then call get_data for the same module twice. Sorry again for the mixup. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 00:04:37 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 20 Mar 2008 23:04:37 +0000 Subject: [issue1477] UnicodeDecodeError that cannot be caught in narrow unicode builds In-Reply-To: <1195593459.02.0.388666867716.issue1477@psf.upfronthosting.co.za> Message-ID: <1206054277.35.0.739455507088.issue1477@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The "strange" code is a copy of PyUnicode_DecodeUnicodeEscape. I find it easier to read. And the duplicate lines are likely to be optimized by the compiler. Here is a new version of the patch which: - correctly forbid illegal code points - compute the byte positions; this is important for error handlers in python2.5, the end position was completely bogus: >>> try: '\U11111111'.decode("raw-unicode-escape") ... except Exception, e: print repr(e) UnicodeDecodeError('rawunicodeescape', '\\U11111111', 0, 504955452, '\\Uxxxxxxxx out of range') Added file: http://bugs.python.org/file9798/raw-unicode-escape2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 00:55:33 2008 From: report at bugs.python.org (Paul Moore) Date: Thu, 20 Mar 2008 23:55:33 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za> Message-ID: <1206057333.58.0.377743936853.issue2439@psf.upfronthosting.co.za> Paul Moore added the comment: Is that true? loader.load_module(pkg) should return sys.modules[pkg] without reloading if it already exists. See PEP 302 "Specification part 1: The Importer Protocol": The load_module() method has a few responsibilities that it must fulfil *before* it runs any code: - If there is an existing module object named 'fullname' in sys.modules, the loader must use that existing module. (Otherwise, the reload() builtin will not work correctly.) If a module named 'fullname' does not exist in sys.modules, the loader must create a new module object and add it to sys.modules. I've added a test for this, but I'm not 100% sure it's right. It certainly works with unchanged code. If you can make it fail, let me know and I'll work up a fix. But I think repeated calls to load_module() should be safe (assuming loaders work as required by PEP 302). Added file: http://bugs.python.org/file9799/pkgutil.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 00:55:50 2008 From: report at bugs.python.org (Paul Moore) Date: Thu, 20 Mar 2008 23:55:50 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za> Message-ID: <1206057350.37.0.423476991732.issue2439@psf.upfronthosting.co.za> Changes by Paul Moore : Removed file: http://bugs.python.org/file9792/pkgutil.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 01:04:34 2008 From: report at bugs.python.org (Phillip J. Eby) Date: Fri, 21 Mar 2008 00:04:34 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206057333.58.0.377743936853.issue2439@psf.upfronthosting. co.za> Message-ID: <20080321000431.7E0313A4074@sparrow.telecommunity.com> Phillip J. Eby added the comment: reload() is implemented by calling the PEP 302 load_module() method on the existing module object. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 01:56:23 2008 From: report at bugs.python.org (Robert Schuppenies) Date: Fri, 21 Mar 2008 00:56:23 +0000 Subject: [issue2227] time.strptime too strict? should it assume current year? In-Reply-To: <1204580486.17.0.196786227347.issue2227@psf.upfronthosting.co.za> Message-ID: <1206060983.85.0.888566734049.issue2227@psf.upfronthosting.co.za> Robert Schuppenies added the comment: Applying the _strptime.diff patch broke the _strptime test("test_defaults"). Once you change the year, you also have to adapt the day of week, as this becomes dynamic, too. The rest remains the same, though. I attached a patch to this test which tests for the new-years day of the current year instead of 1900, but I feel like changing the semantic of the default value is no minor change. Also, I am not sure what the documentation should say then. ---------- nosy: +okkoto Added file: http://bugs.python.org/file9800/test_strptime.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 02:10:56 2008 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 21 Mar 2008 01:10:56 +0000 Subject: [issue2438] subprocess.Popen with wildcard arguments In-Reply-To: <1206045512.59.0.667907711794.issue2438@psf.upfronthosting.co.za> Message-ID: <1206061855.95.0.918332923744.issue2438@psf.upfronthosting.co.za> Skip Montanaro added the comment: The default for Popen objects is to not use the shell, thus no expansion. Set shell=True in the Popen call: >>> import subprocess >>> output = subprocess.Popen(['ls', '*']) >>> ls: *: No such file or directory >>> output = subprocess.Popen(['ls', '*'], shell=True) >>> configure.out svn-stat.out svn-update.out Skip ---------- nosy: +skip.montanaro resolution: -> works for me status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 02:39:55 2008 From: report at bugs.python.org (Sean Reifschneider) Date: Fri, 21 Mar 2008 01:39:55 +0000 Subject: [issue2222] Memory leak in os.rename? In-Reply-To: <1204549533.94.0.102574866059.issue2222@psf.upfronthosting.co.za> Message-ID: <1206063595.66.0.217376715629.issue2222@psf.upfronthosting.co.za> Changes by Sean Reifschneider : ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 02:59:30 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 21 Mar 2008 01:59:30 +0000 Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217 In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za> Message-ID: <1206064770.09.0.140793586331.issue2054@psf.upfronthosting.co.za> Antoine Pitrou added the comment: FWIW, m2crypto already provides an FTP-TLS facility with an ftplib-compatible API. See http://chandlerproject.org/Projects/MeTooCrypto ---------- nosy: +pitrou __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 03:05:29 2008 From: report at bugs.python.org (A.M. Kuchling) Date: Fri, 21 Mar 2008 02:05:29 +0000 Subject: [issue2442] Undocumented features added to 2.6 In-Reply-To: <1206065129.51.0.279261412991.issue2442@psf.upfronthosting.co.za> Message-ID: <1206065129.51.0.279261412991.issue2442@psf.upfronthosting.co.za> New submission from A.M. Kuchling : The following modules or features aren't documented: future_builtins, __self__ and __func__ on method objects, the print() function. ---------- assignee: georg.brandl components: Documentation messages: 64230 nosy: akuchling, georg.brandl severity: normal status: open title: Undocumented features added to 2.6 versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 05:49:33 2008 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 21 Mar 2008 04:49:33 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za> Message-ID: <1206074973.16.0.258850672937.issue2439@psf.upfronthosting.co.za> Nick Coghlan added the comment: To clarify the intent of the section of PEP 302 Paul quoted: the *module* object gets reused, but the contents of mod.__dict__ are clobbered and the module code re-executed. So it's the same module object, but with brand new contents (this is why "from foo import bar" and "reload(foo)" do not play nicely with each other, but doing "import foo" and then invoking "foo.bar" picks up the new version of "bar" after a reload). ---------- nosy: +ncoghlan __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 06:07:54 2008 From: report at bugs.python.org (Neal Norwitz) Date: Fri, 21 Mar 2008 05:07:54 +0000 Subject: [issue1068881] TclError not a subclass of StandardError Message-ID: <1206076073.92.0.00958617975369.issue1068881@psf.upfronthosting.co.za> Neal Norwitz added the comment: StandardError has been removed from Python 3.0. It's use is deprecated. Instead of catching StandardError, do: try: # ... except Exception: # ... ---------- assignee: loewis -> nnorwitz nosy: +nnorwitz resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 21 07:06:09 2008 From: report at bugs.python.org (Ka-Ping Yee) Date: Fri, 21 Mar 2008 06:06:09 +0000 Subject: [issue2141] Pydoc interactive browser misses some docs In-Reply-To: <1203344335.25.0.229282723234.issue2141@psf.upfronthosting.co.za> Message-ID: <1206079569.27.0.952301701351.issue2141@psf.upfronthosting.co.za> Ka-Ping Yee added the comment: This is (currently) the intended behaviour. The rfc822 module has an __all__ attribute that lists its public functions and classes, so "pydoc rfc822" only shows these things. formatdate is not listed in __all__. If you'd like to discuss ideas for changing this behaviour, possible forums would be comp.lang.python or the python-dev list. ---------- resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 09:44:15 2008 From: report at bugs.python.org (Brett Cannon) Date: Fri, 21 Mar 2008 08:44:15 +0000 Subject: [issue2227] time.strptime too strict? should it assume current year? In-Reply-To: <1204580486.17.0.196786227347.issue2227@psf.upfronthosting.co.za> Message-ID: <1206089055.32.0.66038247519.issue2227@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 11:27:38 2008 From: report at bugs.python.org (Rolland Dudemaine) Date: Fri, 21 Mar 2008 10:27:38 +0000 Subject: [issue2443] uninitialized access to va_list In-Reply-To: <1206095258.5.0.538024401904.issue2443@psf.upfronthosting.co.za> Message-ID: <1206095258.5.0.538024401904.issue2443@psf.upfronthosting.co.za> New submission from Rolland Dudemaine : In many files, the following code is present (with slight variations, but the important part is there) : static PyObject * objargs_mktuple(va_list va) { int i, n = 0; va_list countva; PyObject *result, *tmp; #ifdef VA_LIST_IS_ARRAY memcpy(countva, va, sizeof(va_list)); #else #ifdef __va_copy __va_copy(countva, va); #else countva = va; #endif #endif ... memcpy() is accessing va_list before it is initialized. Before the first access to a va_list type variable, and after the last access to that variable, calls to va_start() and va_end() must be made to initialize and free the variable. Such behaviour should be corrected in the following files : - Objects/abstract.c, line 1901 - Objects/stringobject.c, line 162 - getargs.c, line 66 - getargs.c, line 1188 - modsupport.c, line 479 ---------- components: Build messages: 64234 nosy: rolland severity: normal status: open title: uninitialized access to va_list type: compile error versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 12:48:09 2008 From: report at bugs.python.org (Kent Johnson) Date: Fri, 21 Mar 2008 11:48:09 +0000 Subject: [issue1163367] correct/clarify documentation for super Message-ID: <1206100089.39.0.133713905595.issue1163367@psf.upfronthosting.co.za> Kent Johnson added the comment: This issue seems to have foundered on finding an explanation for the finer points of super(). Perhaps the glaring errors could at least be corrected, or the fine points could be omitted or glossed over? For example change the first sentence of the docs to "Returns a proxy for the type following 'type' in the method resolution order of 'object-or-type'." Perhaps link to these? http://chandlerproject.org/bin/view/Projects/UsingSuper http://fuhm.net/super-harmful/ ---------- nosy: +kjohnson _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 21 13:14:11 2008 From: report at bugs.python.org (=?utf-8?q?Hrvoje_Nik=C5=A1i=C4=87?=) Date: Fri, 21 Mar 2008 12:14:11 +0000 Subject: [issue2389] Array pickling exposes internal memory representation of elements In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za> Message-ID: <1206101651.53.0.712233613913.issue2389@psf.upfronthosting.co.za> Hrvoje Nik?i? added the comment: Here is an example that directly demonstrates the bug. Pickling on x86_64: Python 2.5.1 (r251:54863, Mar 21 2008, 13:06:31) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import array, cPickle as pickle >>> pickle.dumps(array.array('l', [1, 2, 3])) "carray\narray\np1\n(S'l'\nS'\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x02\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x03\\x00\\x00\\x00\\x00\\x00\\x00\\x00'\ntRp2\n." Unpickling on ia32: Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle as pickle >>> pickle.loads("carray\narray\np1\n(S'l'\nS'\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x02\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x03\\x00\\x00\\x00\\x00\\x00\\x00\\x00'\ntRp2\n.") array('l', [1, 0, 2, 0, 3, 0]) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 13:24:05 2008 From: report at bugs.python.org (Paul Moore) Date: Fri, 21 Mar 2008 12:24:05 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za> Message-ID: <1206102245.91.0.480177386953.issue2439@psf.upfronthosting.co.za> Paul Moore added the comment: Nick, thanks I now see the issue. I'll work up a test to check for this (and then correct it :-)). __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 13:35:09 2008 From: report at bugs.python.org (Phillip J. Eby) Date: Fri, 21 Mar 2008 12:35:09 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206102245.91.0.480177386953.issue2439@psf.upfronthosting. co.za> Message-ID: <20080321123505.DAE3B3A40B1@sparrow.telecommunity.com> Phillip J. Eby added the comment: An easy way to test it: just change your load_module() to raise an AssertionError if the module is already in sys.modules, and the main body of the test to make two get_data() calls for the same module. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 13:43:06 2008 From: report at bugs.python.org (Robert E.) Date: Fri, 21 Mar 2008 12:43:06 +0000 Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217 In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za> Message-ID: <1206103386.75.0.449687951428.issue2054@psf.upfronthosting.co.za> Robert E. added the comment: >> FWIW, m2crypto already provides an FTP-TLS facility with an >> ftplib-compatible API. See http://chandlerproject.org/Projects/MeTooCrypto Right but m2crypto is not part of the standard library (and is not going to be anytime soon). SSL is scheduled to be in 2.6. So it would be the natural choice to use that SSL binding to extend the ftp library. Of course we could have a look how ftps is implemented in m2crypto. Concerning the plain-text login. I think a FTPS class should default to encrypted login (you could use the ftp class if you dont want). In no way should the login credentials be sent unencrypted on default. Using another parameter might be a soulution to that, though I would prefer the library to raise an error if establishing an FTPS connection did not succeed. The main program could then catch it and decide how to proceed (using plain ftp or aborting according to a given policy). __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 14:07:06 2008 From: report at bugs.python.org (Paul Moore) Date: Fri, 21 Mar 2008 13:07:06 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za> Message-ID: <1206104826.09.0.760131605711.issue2439@psf.upfronthosting.co.za> Paul Moore added the comment: But that's not a valid loader. I'm still struggling here. I see what you're trying to get at, but I can't see how I can write a valid loader that does this. To test the problem you're suggesting (that the code calls load_module when the module is already loaded) I need a valid loader which does something detectably different of the module is already loaded when it runs. Obviously, I can fix the get_data code - that's not even remotely hard. But I'd rather create a failing test with the current code, so that I can confirm that the "problem" is fixed. At the moment, I can't even demonstrate a problem! __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 14:51:37 2008 From: report at bugs.python.org (Phillip J. Eby) Date: Fri, 21 Mar 2008 13:51:37 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206104826.09.0.760131605711.issue2439@psf.upfronthosting. co.za> Message-ID: <20080321135134.701413A40B0@sparrow.telecommunity.com> Phillip J. Eby added the comment: Why does it need to be a valid loader? It's a mock, not a real loader. But if it really bothers you, have it increment a global in the module or something, and put the assertion in the test proper. Heck, have it update a counter in the module it returns, making it into a loader that keeps track of how many times you reload the same module. Then it's a useful example loader. :) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 15:15:08 2008 From: report at bugs.python.org (Paul Moore) Date: Fri, 21 Mar 2008 14:15:08 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za> Message-ID: <1206108908.61.0.105609406839.issue2439@psf.upfronthosting.co.za> Paul Moore added the comment: It has to be a valid loader, as I see no reason to support loaders that aren't valid. In any case, I did try incrementing a counter and it doesn't demonstrate the problem. If you try the currently attached patch, you should see that. (I assume you've tried or at least read the current patch - but the fact that you're suggesting the approach I have implemented makes me wonder. I did re-upload the patch after you reported the issue - msg 64225 - maybe you didn't notice this, as I deleted the old patch?) If you do see what I mean, please tell me where my code is wrong. I don't want to add a fix without a test showing why the current behaviour is wrong. The test_alreadyloaded test is intended to do that, but the current pkgutil code doesn't fail the test - so either the test is wrong (and I'd appreciate help fixing the test) or the "problem" isn't real, and I can leave the code as is. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 16:04:55 2008 From: report at bugs.python.org (Phillip J. Eby) Date: Fri, 21 Mar 2008 15:04:55 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206108908.61.0.105609406839.issue2439@psf.upfronthosting. co.za> Message-ID: <20080321150452.505AC3A40FF@sparrow.telecommunity.com> Phillip J. Eby added the comment: But I'm getting a failure on that test, and the other one, too: $ ./python Lib/test/test_pkgutil.py test_alreadyloaded (__main__.PkgutilTests) ... FAIL test_getdata_filesys (__main__.PkgutilTests) ... FAIL test_getdata_pep302 (__main__.PkgutilTests) ... ok ====================================================================== FAIL: test_alreadyloaded (__main__.PkgutilTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_pkgutil.py", line 45, in test_alreadyloaded self.assertEqual(foo.loads, 1) AssertionError: 2 != 1 ====================================================================== FAIL: test_getdata_filesys (__main__.PkgutilTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_pkgutil.py", line 30, in test_getdata_filesys self.assert_('PkgutilTests' in this_file) AssertionError ---------------------------------------------------------------------- Ran 3 tests in 0.017s FAILED (failures=2) I'm rebuilding my entire 2.6 checkout to double-check there's not something else going on, but I know my Lib/ tree is up-to-date. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 16:41:37 2008 From: report at bugs.python.org (Guilherme Polo) Date: Fri, 21 Mar 2008 15:41:37 +0000 Subject: [issue2444] Adding __iter__ to class Values of module optparse In-Reply-To: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za> Message-ID: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za> New submission from Guilherme Polo : Hi, Doing (opts, args) = parser.parse_args(), supposing parser is an OptionParser instance, gets you an instance of class Values into opts. This patch adds the __iter__ method to the class Values so it is possible to iterate over the options you could have received. This is useful when all your options are required and you don't want to use a lot of if's to check if they are all there (for example). Right now it is possible to do this but you would have to iterate over opts.__dict__, an ugly way as I see. ---------- components: Library (Lib) files: optparse__iter__.diff keywords: patch messages: 64244 nosy: gpolo severity: normal status: open title: Adding __iter__ to class Values of module optparse versions: Python 2.6 Added file: http://bugs.python.org/file9801/optparse__iter__.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 16:48:54 2008 From: report at bugs.python.org (Guilherme Polo) Date: Fri, 21 Mar 2008 15:48:54 +0000 Subject: [issue2444] Adding __iter__ to class Values of module optparse In-Reply-To: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za> Message-ID: <1206114534.52.0.217470490247.issue2444@psf.upfronthosting.co.za> Changes by Guilherme Polo : Added file: http://bugs.python.org/file9802/optparse_py3k__iter__.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 17:41:38 2008 From: report at bugs.python.org (David Stanek) Date: Fri, 21 Mar 2008 16:41:38 +0000 Subject: [issue2445] Use The CygwinCCompiler Under Cygwin In-Reply-To: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za> Message-ID: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za> New submission from David Stanek : I was having an issue building extension with a fresh checkout of revision 61699. distutils was using the UnixCCompiler. This is not able to find thec correct libraries to link against. I made a few changes in this patch: * distutils now uses the CygwinCCompiler when building extensions on the Cygwin platform * CygwinCCompiler.static_lib_extension needed to be .lib.a instead of just .a * Added some files to the svn:ignore property on a handful of directories. ---------- components: Distutils files: cygwin.diff keywords: patch messages: 64245 nosy: dstanek severity: normal status: open title: Use The CygwinCCompiler Under Cygwin versions: Python 2.6 Added file: http://bugs.python.org/file9803/cygwin.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 17:42:57 2008 From: report at bugs.python.org (David Stanek) Date: Fri, 21 Mar 2008 16:42:57 +0000 Subject: [issue2445] Use The CygwinCCompiler Under Cygwin In-Reply-To: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za> Message-ID: <1206117777.52.0.812507285641.issue2445@psf.upfronthosting.co.za> Changes by David Stanek : ---------- type: -> compile error __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 18:25:57 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Mar 2008 17:25:57 +0000 Subject: [issue2445] Use The CygwinCCompiler Under Cygwin In-Reply-To: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za> Message-ID: <1206120357.28.0.308058576149.issue2445@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch contains lots of unrelated changes. Can you please provide a clean patch and some doc updates? The rest looks fine to me. ---------- nosy: +tiran priority: -> high resolution: -> accepted versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 18:59:42 2008 From: report at bugs.python.org (Bruce Frederiksen) Date: Fri, 21 Mar 2008 17:59:42 +0000 Subject: [issue2446] 2to3 translates "import foobar" to "import .foobar" rather than "from . import foobar" In-Reply-To: <1206122382.01.0.177794619684.issue2446@psf.upfronthosting.co.za> Message-ID: <1206122382.01.0.177794619684.issue2446@psf.upfronthosting.co.za> New submission from Bruce Frederiksen : 2to3 svn rev 61696 translates "import local_module" into "import .local_module" which isn't legal syntax. Should be "from . import local_module". ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 64247 nosy: collinwinter, dangyogi severity: normal status: open title: 2to3 translates "import foobar" to "import .foobar" rather than "from . import foobar" type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 19:17:16 2008 From: report at bugs.python.org (David Stanek) Date: Fri, 21 Mar 2008 18:17:16 +0000 Subject: [issue2445] Use The CygwinCCompiler Under Cygwin In-Reply-To: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za> Message-ID: <1206123436.84.0.822441370291.issue2445@psf.upfronthosting.co.za> David Stanek added the comment: As Christian suggested I removed the unrelated svn:ignore changes. Added file: http://bugs.python.org/file9804/cygwin-smaller.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 19:17:32 2008 From: report at bugs.python.org (David Stanek) Date: Fri, 21 Mar 2008 18:17:32 +0000 Subject: [issue2445] Use The CygwinCCompiler Under Cygwin In-Reply-To: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za> Message-ID: <1206123452.29.0.99923355095.issue2445@psf.upfronthosting.co.za> Changes by David Stanek : Removed file: http://bugs.python.org/file9803/cygwin.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 19:21:21 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Mar 2008 18:21:21 +0000 Subject: [issue2405] Drop w9xpopen and all dependencies In-Reply-To: <1205870969.55.0.774025556957.issue2405@psf.upfronthosting.co.za> Message-ID: <1206123681.21.0.595152992806.issue2405@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm not sure either but I like to consider the removal of w9xpopen wrapper for the 3.x series. The py3k project was started to remove old cruft and I view w9xpopen as such a cruft. ---------- components: +Windows nosy: +tiran priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 19:24:24 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Mar 2008 18:24:24 +0000 Subject: [issue2320] Race condition in subprocess using stdin In-Reply-To: <1205760712.39.0.906940637593.issue2320@psf.upfronthosting.co.za> Message-ID: <1206123864.42.0.578996404323.issue2320@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- priority: -> critical type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 19:24:54 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Mar 2008 18:24:54 +0000 Subject: [issue2442] Undocumented features added to 2.6 In-Reply-To: <1206065129.51.0.279261412991.issue2442@psf.upfronthosting.co.za> Message-ID: <1206123894.43.0.126021689793.issue2442@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- keywords: +easy priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 19:26:04 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Mar 2008 18:26:04 +0000 Subject: [issue2443] uninitialized access to va_list In-Reply-To: <1206095258.5.0.538024401904.issue2443@psf.upfronthosting.co.za> Message-ID: <1206123964.15.0.464569324106.issue2443@psf.upfronthosting.co.za> Christian Heimes added the comment: Can you provide a patch for 2.6 against the latest svn checkout of the trunk please? ---------- components: +Interpreter Core -Build nosy: +tiran priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 19:28:05 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Mar 2008 18:28:05 +0000 Subject: [issue2390] Merge 2.6 ACKS with 3.0 ACKS In-Reply-To: <1205854707.75.0.657591820184.issue2390@psf.upfronthosting.co.za> Message-ID: <1206124085.83.0.420000307191.issue2390@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks! :) ---------- assignee: -> tiran nosy: +tiran priority: -> normal type: -> feature request __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 19:28:37 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Mar 2008 18:28:37 +0000 Subject: [issue2399] Patches for Tools/msi In-Reply-To: <1205858738.04.0.681248681608.issue2399@psf.upfronthosting.co.za> Message-ID: <1206124117.13.0.303680126247.issue2399@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: -> loewis priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 19:29:52 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Mar 2008 18:29:52 +0000 Subject: [issue2408] types module can be implemented only in Python In-Reply-To: <1205874570.2.0.410256172712.issue2408@psf.upfronthosting.co.za> Message-ID: <1206124192.31.0.466285681666.issue2408@psf.upfronthosting.co.za> Christian Heimes added the comment: Please have a look at patch #1605, too. It implements a semi autogenerated _types module which exposes all types in from Include/*.h ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 19:31:29 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Mar 2008 18:31:29 +0000 Subject: [issue2310] Reorganize the 3.0 Misc/NEWS file In-Reply-To: <1205702758.46.0.979295500245.issue2310@psf.upfronthosting.co.za> Message-ID: <1206124289.61.0.313119894497.issue2310@psf.upfronthosting.co.za> Christian Heimes added the comment: > but skipping stuff merged from 3.0. Do you mean "skipping stuff merged from 2.6" ? ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 19:32:14 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Mar 2008 18:32:14 +0000 Subject: [issue2388] Compiler warnings when using UCS4 In-Reply-To: <1205848812.38.0.436275134314.issue2388@psf.upfronthosting.co.za> Message-ID: <1206124334.83.0.61222904261.issue2388@psf.upfronthosting.co.za> Christian Heimes added the comment: I'll check it out later. I haven't been testing UCS4 builds for more than a month. ---------- assignee: -> tiran keywords: +easy nosy: +tiran priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 19:36:17 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Mar 2008 18:36:17 +0000 Subject: [issue2422] Automatically disable pymalloc when running under valgrind In-Reply-To: <1205925069.41.0.603933745456.issue2422@psf.upfronthosting.co.za> Message-ID: <1206124577.23.0.422466140337.issue2422@psf.upfronthosting.co.za> Christian Heimes added the comment: Please provide a patch for Python 2.6 that includes a ./configure --with-valgrind option. We may consider such a patch for 2.6 and 3.0 but definitely not for 2.5. ---------- nosy: +tiran priority: -> normal versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 19:39:31 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Mar 2008 18:39:31 +0000 Subject: [issue2256] Install failure of 2.6a1 on Windows XP without VS8 installed In-Reply-To: <1204932826.89.0.672189283054.issue2256@psf.upfronthosting.co.za> Message-ID: <1206124771.81.0.918146531249.issue2256@psf.upfronthosting.co.za> Christian Heimes added the comment: We are still having trouble with msvcrt90.dll and SxS assemblies (side by side assembly dlls). Chris suggested to modify the manifest of the Python dlls (pyd) files to look for the private copy of msvcrt90.dll in the parent directory ..\. ---------- nosy: +loewis, tiran priority: -> critical __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 19:52:00 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Mar 2008 18:52:00 +0000 Subject: [issue2447] Python 2.6 refleak test issues In-Reply-To: <1206125520.14.0.711672473194.issue2447@psf.upfronthosting.co.za> Message-ID: <1206125520.14.0.711672473194.issue2447@psf.upfronthosting.co.za> New submission from Christian Heimes : linux-i686-2.6 Revision 61704. Ubuntu 7.10 on i586 machine gcc-Version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) trunk$ ./python Lib/test/regrtest.py -ubsddb,network -R:: [...] 311 tests OK. 7 tests failed: test_collections test_cprofile test_frozen test_logging test_pkg test_profile test_tcl 27 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_gl test_imageop test_imgfile test_linuxaudiodev test_macostools test_normalization test_ossaudiodev test_pep277 test_py3kwarn test_scriptpackages test_startfile test_sunaudiodev test_winreg test_winsound test_zipfile64 Those skips are all expected on linux2. trunk$ cat reflog.txt test_smtplib leaked [86, -86, 80, -80] references, sum=0 test_socket_ssl leaked [0, 123, -123, 0] references, sum=0 test_threading leaked [0, 0, 0, -86] references, sum=-86 test_urllib2_localnet leaked [3, 171, -165, 3] references, sum=12 ---------- components: Tests messages: 64257 nosy: tiran priority: high severity: normal status: open title: Python 2.6 refleak test issues type: crash versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 19:54:50 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Mar 2008 18:54:50 +0000 Subject: [issue2448] namedtuple breaks refleak tests In-Reply-To: <1206125690.78.0.550983870823.issue2448@psf.upfronthosting.co.za> Message-ID: <1206125690.78.0.550983870823.issue2448@psf.upfronthosting.co.za> New submission from Christian Heimes : trunk$ ./python Lib/test/regrtest.py -ubsddb,network -R:: test_collections test_collections beginning 9 repetitions 123456789 test test_collections failed -- Traceback (most recent call last): File "/home/heimes/dev/python/trunk/Lib/doctest.py", line 2131, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for collections.namedtuple File "/home/heimes/dev/python/trunk/Lib/collections.py", line 13, in namedtuple ---------------------------------------------------------------------- File "/home/heimes/dev/python/trunk/Lib/collections.py", line 16, in collections.namedtuple Failed example: Point = namedtuple('Point', 'x y') Exception raised: Traceback (most recent call last): File "/home/heimes/dev/python/trunk/Lib/doctest.py", line 1231, in __run compileflags, 1) in test.globs File "", line 1, in Point = namedtuple('Point', 'x y') NameError: name 'namedtuple' is not defined ---------- assignee: rhettinger components: Library (Lib), Tests messages: 64258 nosy: rhettinger, tiran priority: high severity: normal status: open title: namedtuple breaks refleak tests type: crash versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 20:02:48 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 21 Mar 2008 19:02:48 +0000 Subject: [issue2310] Reorganize the 3.0 Misc/NEWS file In-Reply-To: <1206124289.61.0.313119894497.issue2310@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > Do you mean "skipping stuff merged from 2.6" ? Yes :) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 20:30:43 2008 From: report at bugs.python.org (Paul Moore) Date: Fri, 21 Mar 2008 19:30:43 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za> Message-ID: <1206127843.18.0.325240467477.issue2439@psf.upfronthosting.co.za> Paul Moore added the comment: Thanks for the update. Something's seriously screwy here. I am getting no failures, so you can probably see why I was confused. Can you tell me what platform, etc (anything that might be relevant) and I'll try to see what's going on. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 20:38:18 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 19:38:18 +0000 Subject: [issue2442] Undocumented features added to 2.6 In-Reply-To: <1206065129.51.0.279261412991.issue2442@psf.upfronthosting.co.za> Message-ID: <1206128297.96.0.705157975496.issue2442@psf.upfronthosting.co.za> Georg Brandl added the comment: Added to the docs in r61708, r61709. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 20:42:39 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 19:42:39 +0000 Subject: [issue1775] filehandle.write() does not return None (Python 3.0a2) In-Reply-To: <1199883149.22.0.23332594805.issue1775@psf.upfronthosting.co.za> Message-ID: <1206128559.32.0.643780156985.issue1775@psf.upfronthosting.co.za> Georg Brandl added the comment: The docs for "io" are practically nonexistent :) I'll leave that for a separate issue, and fixed this one by adding a paragraph to the current file object docs (better than nothing) in r61710. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 20:43:11 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 19:43:11 +0000 Subject: [issue2420] Faq 4.28 -- Trailing comas In-Reply-To: <1205916647.4.0.701365283019.issue2420@psf.upfronthosting.co.za> Message-ID: <1206128591.92.0.886881017878.issue2420@psf.upfronthosting.co.za> Georg Brandl added the comment: I think AMK maintains the FAQLs. ---------- assignee: georg.brandl -> akuchling nosy: +akuchling __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 20:45:32 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 19:45:32 +0000 Subject: [issue2243] urllib2. strange behavior for getting chuncked transfer-ecnoded data In-Reply-To: <1204798625.87.0.148151937521.issue2243@psf.upfronthosting.co.za> Message-ID: <1206128732.82.0.167077427443.issue2243@psf.upfronthosting.co.za> Georg Brandl added the comment: I don't think we should change this -- it sounds like gratuitous breakage to me, and I also don't see the reason why httplib should throw away an HTTP header just because the user isn't likely to need it. ---------- resolution: -> wont fix status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 20:49:39 2008 From: report at bugs.python.org (Paul Moore) Date: Fri, 21 Mar 2008 19:49:39 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za> Message-ID: <1206128979.23.0.447243788782.issue2439@psf.upfronthosting.co.za> Paul Moore added the comment: By the way, for comparison, I'm running the test (under Windows) using rt -q -v test_pkgutil from the PCBuild directory. I can't see how test_getdata_filesys can fail, as long as you're running it from the correct place - it reads the test_pkgutil.py file relative to the test package, so it won't run outside of there (maybe I should change this, but that's a separate issue for now). Here's my output: >rt -q -v test_pkgutil .\\python -E -tt ../lib/test/regrtest.py -v test_pkgutil test_pkgutil test_alreadyloaded (test.test_pkgutil.PkgutilTests) ... ok test_getdata_filesys (test.test_pkgutil.PkgutilTests) ... ok test_getdata_pep302 (test.test_pkgutil.PkgutilTests) ... ok ---------------------------------------------------------------------- Ran 3 tests in 0.000s OK 1 test OK. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 20:52:51 2008 From: report at bugs.python.org (Paul Moore) Date: Fri, 21 Mar 2008 19:52:51 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za> Message-ID: <1206129171.04.0.146463223512.issue2439@psf.upfronthosting.co.za> Paul Moore added the comment: Ah, no. I see your command line. I get the same failure as you in that case. I can see why test_getdata_filesys fails in that case, I'll fix that. I'm confused as to why test_alreadyloaded fails there but not via rt.bat, but nevertheless I can fix that now I can see it. Thanks for your patience. Leave it with me. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 20:54:07 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 19:54:07 +0000 Subject: [issue2136] urllib2 basic auth handler doesn't handle realm names in single-quoted strings In-Reply-To: <1203296568.46.0.747126970867.issue2136@psf.upfronthosting.co.za> Message-ID: <1206129247.67.0.647165570179.issue2136@psf.upfronthosting.co.za> Georg Brandl added the comment: Huh, I'm not really an HTTP expert either :) But this seems reasonable to me. Implemented this (with a slightly different patch) in r61711. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 21:02:09 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 20:02:09 +0000 Subject: [issue2432] DictReader does not suport line_num In-Reply-To: <1206002820.55.0.716931876955.issue2432@psf.upfronthosting.co.za> Message-ID: <1206129729.48.0.422272385055.issue2432@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed by adding line_num attr to DictReader in r61712, r61713 (2.5). ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 21:12:01 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 20:12:01 +0000 Subject: [issue2358] Using sys.exc_clear should raise a Py3K warning In-Reply-To: <1205782771.08.0.305016984378.issue2358@psf.upfronthosting.co.za> Message-ID: <1206130321.05.0.228919383554.issue2358@psf.upfronthosting.co.za> Georg Brandl added the comment: Reformatted, added test case and committed in r61714. ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 21:13:50 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 20:13:50 +0000 Subject: [issue2337] Backport oct() and hex() to use __index__ In-Reply-To: <1205776266.64.0.297851457778.issue2337@psf.upfronthosting.co.za> Message-ID: <1206130430.64.0.234161284451.issue2337@psf.upfronthosting.co.za> Georg Brandl added the comment: Shouldn't we leave alone oct() and hex() (there is another issue for deprecation warning for __oct__ and __hex__), and let people use the versions from future_builtins? ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 21:22:20 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 20:22:20 +0000 Subject: [issue2346] Py3K warn against using __members__ In-Reply-To: <1205781355.97.0.143101300316.issue2346@psf.upfronthosting.co.za> Message-ID: <1206130940.05.0.455698863783.issue2346@psf.upfronthosting.co.za> Georg Brandl added the comment: Added test case and warning for another use of __methods__ and committed as r61715. ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 21:22:33 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 20:22:33 +0000 Subject: [issue2347] Py3K warn for using __methods__ In-Reply-To: <1205781395.77.0.22785481066.issue2347@psf.upfronthosting.co.za> Message-ID: <1206130953.76.0.554307230824.issue2347@psf.upfronthosting.co.za> Georg Brandl added the comment: Patch for #2346 included this. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 21:22:41 2008 From: report at bugs.python.org (Collin Winter) Date: Fri, 21 Mar 2008 20:22:41 +0000 Subject: [issue2446] 2to3 translates "import foobar" to "import .foobar" rather than "from . import foobar" In-Reply-To: <1206122382.01.0.177794619684.issue2446@psf.upfronthosting.co.za> Message-ID: <1206130961.29.0.0749410917177.issue2446@psf.upfronthosting.co.za> Changes by Collin Winter : ---------- assignee: collinwinter -> David Wolever nosy: +David Wolever __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 21:23:40 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 21 Mar 2008 20:23:40 +0000 Subject: [issue2446] 2to3 translates "import foobar" to "import .foobar" rather than "from . import foobar" In-Reply-To: <1206122382.01.0.177794619684.issue2446@psf.upfronthosting.co.za> Message-ID: <1206131020.81.0.901932167084.issue2446@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 21:28:47 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Fri, 21 Mar 2008 20:28:47 +0000 Subject: [issue1577] shutil.move() does not use os.rename() if dst is a directory In-Reply-To: <1197242604.93.0.919654384861.issue1577@psf.upfronthosting.co.za> Message-ID: <1206131327.3.0.692496717333.issue1577@psf.upfronthosting.co.za> Changes by Raghuram Devarakonda : ---------- resolution: accepted -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 21:30:03 2008 From: report at bugs.python.org (Raghuram Devarakonda) Date: Fri, 21 Mar 2008 20:30:03 +0000 Subject: [issue2047] shutil.destinsrc returns wrong result when source path matches beginning of destination path In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za> Message-ID: <1206131403.81.0.167672826947.issue2047@psf.upfronthosting.co.za> Changes by Raghuram Devarakonda : ---------- keywords: +easy __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 21:35:15 2008 From: report at bugs.python.org (Guilherme Polo) Date: Fri, 21 Mar 2008 20:35:15 +0000 Subject: [issue467384] provide a documented serialization func Message-ID: <1206131715.49.0.738094220619.issue467384@psf.upfronthosting.co.za> Changes by Guilherme Polo : ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 21 21:35:16 2008 From: report at bugs.python.org (Guilherme Polo) Date: Fri, 21 Mar 2008 20:35:16 +0000 Subject: [issue467384] provide a documented serialization func Message-ID: <1206131716.9.0.679362514408.issue467384@psf.upfronthosting.co.za> Changes by Guilherme Polo : ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 21 21:39:09 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 20:39:09 +0000 Subject: [issue2348] Py3K warn using file.softspace In-Reply-To: <1205781454.44.0.267838748773.issue2348@psf.upfronthosting.co.za> Message-ID: <1206131949.78.0.103874677334.issue2348@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed a simpler patch (the file object already had a getsetlist) in r61716. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 21:39:48 2008 From: report at bugs.python.org (Christopher Blunck) Date: Fri, 21 Mar 2008 20:39:48 +0000 Subject: [issue2449] Improved serialization error logging in xmlrpclib In-Reply-To: <1206131988.04.0.901893858067.issue2449@psf.upfronthosting.co.za> Message-ID: <1206131988.04.0.901893858067.issue2449@psf.upfronthosting.co.za> New submission from Christopher Blunck : When xmlrpclib fails to serialize objects into XML a generic "failed to serialize output" error is returned to the client and no log messages are produced to give insight into the true cause of the problem. In real-world scenarios where lots of data moves along the wire it can be difficult to determine the cause of the serialization problem. I propose the attached patch as an initial cut at improving xmlrpclib under circumstances where serialization fails. ---------- components: Library (Lib) files: Python-2.4.4.all.patch04 messages: 64274 nosy: blunck2 severity: normal status: open title: Improved serialization error logging in xmlrpclib type: feature request versions: Python 2.4 Added file: http://bugs.python.org/file9805/Python-2.4.4.all.patch04 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 21:42:28 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 20:42:28 +0000 Subject: [issue984219] hotspot.stats.load is very slow Message-ID: <1206132148.16.0.364723548487.issue984219@psf.upfronthosting.co.za> Georg Brandl added the comment: Turning into a feature request. ---------- nosy: +georg.brandl type: performance -> feature request ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 21 21:43:30 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 20:43:30 +0000 Subject: [issue2300] make html fails In-Reply-To: <1205670838.75.0.758086838639.issue2300@psf.upfronthosting.co.za> Message-ID: <1206132210.68.0.259481163344.issue2300@psf.upfronthosting.co.za> Georg Brandl added the comment: I assume that it is fixed for Christian too, so am closing it. ---------- keywords: +patch resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 21:45:48 2008 From: report at bugs.python.org (Guilherme Polo) Date: Fri, 21 Mar 2008 20:45:48 +0000 Subject: [issue467384] provide a documented serialization func Message-ID: <1206132348.61.0.181803302231.issue467384@psf.upfronthosting.co.za> Guilherme Polo added the comment: Sorry, but is the feature request related to constructing a safe unpickler ? If yes, then I suppose this issue should be closed and an appropriate one be created. Nevertheless, reading the following comment at pickletools.py (trunk) makes me think this feature request won't be done, not in the pickle module at least: "Another independent change with Python 2.3 is the abandonment of any pretense that it might be safe to load pickles received from untrusted parties -- no sufficient security analysis has been done to guarantee this and there isn't a use case that warrants the expense of such an analysis." ---------- nosy: +gpolo ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 21 21:47:16 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 20:47:16 +0000 Subject: [issue2298] Patch for "string without null bytes" check in getargs.c In-Reply-To: <1205647240.0.0.304059938651.issue2298@psf.upfronthosting.co.za> Message-ID: <1206132436.45.0.634145378421.issue2298@psf.upfronthosting.co.za> Georg Brandl added the comment: I've added XXX comments to the code, so this is now tracked by #2322. ---------- nosy: +georg.brandl resolution: -> duplicate status: open -> closed superseder: -> Clean up getargs.c and its formatting possibilities __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 21:48:39 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 20:48:39 +0000 Subject: [issue1737127] re.findall hangs python completely Message-ID: <1206132519.62.0.543152736694.issue1737127@psf.upfronthosting.co.za> Georg Brandl added the comment: Closing as fixed, then. ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 21 21:53:25 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 20:53:25 +0000 Subject: [issue2162] unittest.findTestCases undocumented In-Reply-To: <1203690921.5.0.9443371245.issue2162@psf.upfronthosting.co.za> Message-ID: <1206132805.53.0.908158908928.issue2162@psf.upfronthosting.co.za> Georg Brandl added the comment: Certainly. ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 21:55:52 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 21 Mar 2008 20:55:52 +0000 Subject: [issue2160] Document PyImport_GetImporter In-Reply-To: <1203658497.27.0.656206451092.issue2160@psf.upfronthosting.co.za> Message-ID: <1206132952.95.0.31100001761.issue2160@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, committed as r61718. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 22:09:18 2008 From: report at bugs.python.org (Paul Moore) Date: Fri, 21 Mar 2008 21:09:18 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za> Message-ID: <1206133758.14.0.497449508178.issue2439@psf.upfronthosting.co.za> Paul Moore added the comment: OK, I found it. There were 2 problems, the double-loading one, and a problem with adding my importer to sys.meta_path - if the test failed, I wasn't removing it (so it was there for the next test, and interfering with it). Here's a fixed patch. Thanks, Phillip, for persevering! Added file: http://bugs.python.org/file9806/pkgutil.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 22:09:32 2008 From: report at bugs.python.org (Paul Moore) Date: Fri, 21 Mar 2008 21:09:32 +0000 Subject: [issue2439] Patch to add a get_data function to pkgutil In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za> Message-ID: <1206133772.45.0.296877625245.issue2439@psf.upfronthosting.co.za> Changes by Paul Moore : Removed file: http://bugs.python.org/file9799/pkgutil.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 22:24:55 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 21 Mar 2008 21:24:55 +0000 Subject: [issue1605] Semi autogenerated _types module In-Reply-To: <1197510011.31.0.0381617184937.issue1605@psf.upfronthosting.co.za> Message-ID: <1206134695.22.0.0919651169407.issue1605@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think this is a really good idea. It's in stride with DRY, clean, and sure beats the Python acrobatics that types currently does to find them. ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 22:32:08 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 21 Mar 2008 21:32:08 +0000 Subject: [issue1605] Semi autogenerated _types module In-Reply-To: <1197510011.31.0.0381617184937.issue1605@psf.upfronthosting.co.za> Message-ID: <1206135128.88.0.76566722919.issue1605@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm still resounding -1 on this. Grouping types together because they happen to be implemented in C is a silly thing to do. Groupings should be based on usage, not on implementation style. I successfully argued against the inclusion of all metaclasses in the abc.py module. This proposal would be even more wrong. You might as well insist that all decorators need to be placed in one module. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 22:53:57 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 21 Mar 2008 21:53:57 +0000 Subject: [issue467384] provide a documented serialization func Message-ID: <1206136437.82.0.866292195003.issue467384@psf.upfronthosting.co.za> Guido van Rossum added the comment: There isn't anything actionable in this bug request. It makes much more sense to start a discussion about requirements etc. on python-ideas. ---------- resolution: -> out of date status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 21 23:03:04 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 21 Mar 2008 22:03:04 +0000 Subject: [issue1605] Semi autogenerated _types module In-Reply-To: <1197510011.31.0.0381617184937.issue1605@psf.upfronthosting.co.za> Message-ID: <1206136984.4.0.374453196898.issue1605@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Okay. How about we use this like it is for 2.x, and split it out into different modules in Py3k. We could have execution_types and core_types. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 23:05:34 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 21 Mar 2008 22:05:34 +0000 Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za> Message-ID: <1206137134.33.0.947028495558.issue1657@psf.upfronthosting.co.za> Guido van Rossum added the comment: pyepoll for static names sounds fine (assuming you want some consistency). Given all the rave reviews, what are the chances that you'll be checking this in soon? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 23:06:45 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 21 Mar 2008 22:06:45 +0000 Subject: [issue2248] quit() method of SMTP instance (of smtplib) doesn't return it's result In-Reply-To: <1204875778.72.0.769426067571.issue2248@psf.upfronthosting.co.za> Message-ID: <1206137205.86.0.284235711375.issue2248@psf.upfronthosting.co.za> Guido van Rossum added the comment: No time to review, but making a function return something useful instead of None seems a good idea. ---------- assignee: gvanrossum -> __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 23:07:33 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 21 Mar 2008 22:07:33 +0000 Subject: [issue799428] tk_focusNext() fails Message-ID: <1206137253.76.0.49901635652.issue799428@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- assignee: -> loewis nosy: +loewis ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 21 23:27:19 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 21 Mar 2008 22:27:19 +0000 Subject: [issue1605] Semi autogenerated _types module In-Reply-To: <1206136984.4.0.374453196898.issue1605@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: On Fri, Mar 21, 2008 at 3:03 PM, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > Okay. How about we use this like it is for 2.x, and split it out into > different modules in Py3k. We could have execution_types and core_types. No. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 23:32:49 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 21 Mar 2008 22:32:49 +0000 Subject: [issue1605] Semi autogenerated _types module In-Reply-To: <1197510011.31.0.0381617184937.issue1605@psf.upfronthosting.co.za> Message-ID: <1206138769.26.0.389208549836.issue1605@psf.upfronthosting.co.za> Benjamin Peterson added the comment: > No Well, okay. I still think we should expose these core interpreter types somehow, so people can identify types easily. I don't want to be forced to finding the type of sys._getframe to tell if I have a frame object on my hands. Where would you put them? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 21 23:58:09 2008 From: report at bugs.python.org (John J Lee) Date: Fri, 21 Mar 2008 22:58:09 +0000 Subject: [issue2450] urllib2.Request constructor has no timeout parameter In-Reply-To: <1206140289.07.0.166217155748.issue2450@psf.upfronthosting.co.za> Message-ID: <1206140289.07.0.166217155748.issue2450@psf.upfronthosting.co.za> New submission from John J Lee : r55792 added timeout support to urllib2. A timeout parameter was added to urllib2.OpenerDirector.open(), but there is no corresponding Request constructor parameter. timeout is unique in that respect. Instead, OpenerDirector.open() sets req.timeout on request instances. The parameter "timeout" should behave in the same way as existing parameter "data". ---------- components: Library (Lib) messages: 64291 nosy: jjlee severity: normal status: open title: urllib2.Request constructor has no timeout parameter versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 00:00:27 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Mar 2008 23:00:27 +0000 Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za> Message-ID: <1206140427.39.0.630149577423.issue1657@psf.upfronthosting.co.za> Christian Heimes added the comment: Say "Go" and I'll check the patch in ASAP. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 00:16:18 2008 From: report at bugs.python.org (John J Lee) Date: Fri, 21 Mar 2008 23:16:18 +0000 Subject: [issue2451] No way to disable socket timeouts in httplib, etc. In-Reply-To: <1206141378.11.0.857343736887.issue2451@psf.upfronthosting.co.za> Message-ID: <1206141378.11.0.857343736887.issue2451@psf.upfronthosting.co.za> New submission from John J Lee : The new timeout support in 2.6 makes use of new function socket.create_connection(). socket.create_connection() provides no way to disable timeouts, other than by relying on socket.getdefaulttimeout() returning None. This is unfortunate, because it was the purpose of the new timeout support to allow control of timeouts without reliance on global state. setdefaultsocket.create_connection() should always call sock.settimeout() with the timeout passed to create_connection(), unless a special non-None value is passed indicating that the global default is to be used. Specific modules may then use that special non-None value where required, to preserve backwards-compatibility. ---------- components: Library (Lib) messages: 64293 nosy: jjlee severity: normal status: open title: No way to disable socket timeouts in httplib, etc. versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 00:17:42 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 21 Mar 2008 23:17:42 +0000 Subject: [issue2450] urllib2.Request constructor has no timeout parameter In-Reply-To: <1206140289.07.0.166217155748.issue2450@psf.upfronthosting.co.za> Message-ID: <1206141462.18.0.260548978976.issue2450@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 00:21:50 2008 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 21 Mar 2008 23:21:50 +0000 Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za> Message-ID: <1206141710.58.0.0307933176228.issue1657@psf.upfronthosting.co.za> Guido van Rossum added the comment: Go. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 00:23:27 2008 From: report at bugs.python.org (John J Lee) Date: Fri, 21 Mar 2008 23:23:27 +0000 Subject: [issue2452] inaccuracy in httplib timeout documentation In-Reply-To: <1206141807.24.0.299665473683.issue2452@psf.upfronthosting.co.za> Message-ID: <1206141807.24.0.299665473683.issue2452@psf.upfronthosting.co.za> New submission from John J Lee : The documentation for the new timeout support in 2.6 states that "If the optional timeout parameter is given, connection attempts will timeout after that many seconds". In fact, other non-blocking. The only operation that might block for longer than the requested timeout is the getaddrinfo() in socket.create_connection(). There may be similar inaccuracies in the docs of other modules to which timeout support was added. ---------- assignee: georg.brandl components: Documentation, Library (Lib) messages: 64295 nosy: georg.brandl, jjlee severity: normal status: open title: inaccuracy in httplib timeout documentation versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 00:25:23 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 21 Mar 2008 23:25:23 +0000 Subject: [issue2452] inaccuracy in httplib timeout documentation In-Reply-To: <1206141807.24.0.299665473683.issue2452@psf.upfronthosting.co.za> Message-ID: <1206141923.57.0.456878147319.issue2452@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 00:28:38 2008 From: report at bugs.python.org (Bill Janssen) Date: Fri, 21 Mar 2008 23:28:38 +0000 Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217 In-Reply-To: <1206103386.75.0.449687951428.issue2054@psf.upfronthosting.co.za> Message-ID: <4b3e516a0803211628v34e75ea2pbfaba5beec566501@mail.gmail.com> Bill Janssen added the comment: On Fri, Mar 21, 2008 at 5:43 AM, Robert E. wrote: > > Robert E. added the comment: > > Concerning the plain-text login. I think a FTPS class should default to > encrypted login (you could use the ftp class if you dont want). In no > way should the login credentials be sent unencrypted on default. Using > another parameter might be a soulution to that, though I would prefer > the library to raise an error if establishing an FTPS connection did not > succeed. The main program could then catch it and decide how to proceed > (using plain ftp or aborting according to a given policy). Sounds reasonable to me. Note that FTP is an old and somewhat gnarly protocol, and doesn't work the way more recent application protocols do. The SSL module is designed for TCP-based single-connection call-response protocols, more or less. Doing FTPS right might mean we'd have to extend it. Added file: http://bugs.python.org/file9807/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080321/231759a2/attachment.txt From report at bugs.python.org Sat Mar 22 00:30:34 2008 From: report at bugs.python.org (Facundo Batista) Date: Fri, 21 Mar 2008 23:30:34 +0000 Subject: [issue2451] No way to disable socket timeouts in httplib, etc. In-Reply-To: <1206141378.11.0.857343736887.issue2451@psf.upfronthosting.co.za> Message-ID: <1206142234.9.0.668293410508.issue2451@psf.upfronthosting.co.za> Facundo Batista added the comment: When the semantics of timout in htmllib (and the other libraries) were discussed, the community approved the following behaviour: - setdefaulttimeout() was a hack to allow to set the timeout when nothing else is available. - Now that you can pass the timeout when creating the connection, you shouldn't use the default setting. So, as to enhance practicality and ease to use, when you pass a timeout value it will set up the timeout in the socket. When you don't pass anything, or pass None, it will not set anything. And if you set previously a default value, you can not override it through this parameter: you shouldn't been setting the default in first place. Regards, ---------- nosy: +facundobatista resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 00:36:13 2008 From: report at bugs.python.org (John J Lee) Date: Fri, 21 Mar 2008 23:36:13 +0000 Subject: [issue2452] inaccuracy in httplib timeout documentation In-Reply-To: <1206141807.24.0.299665473683.issue2452@psf.upfronthosting.co.za> Message-ID: <1206142572.95.0.171284072017.issue2452@psf.upfronthosting.co.za> John J Lee added the comment: Oops, un-finished sentence in my opening comment ("In fact, other non-blocking.") should have read: In fact, other blocking operations will also time out. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 00:45:55 2008 From: report at bugs.python.org (Facundo Batista) Date: Fri, 21 Mar 2008 23:45:55 +0000 Subject: [issue2450] urllib2.Request constructor has no timeout parameter In-Reply-To: <1206140289.07.0.166217155748.issue2450@psf.upfronthosting.co.za> Message-ID: <1206143155.63.0.571836005681.issue2450@psf.upfronthosting.co.za> Changes by Facundo Batista : ---------- assignee: -> facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 00:51:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 21 Mar 2008 23:51:10 +0000 Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za> Message-ID: <1206143470.46.0.205229710072.issue1657@psf.upfronthosting.co.za> Christian Heimes added the comment: I've applied the patch in r61722. TODO: finish the documentation, any help is appreciated ---------- components: +Documentation -Extension Modules resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 01:00:18 2008 From: report at bugs.python.org (John J Lee) Date: Sat, 22 Mar 2008 00:00:18 +0000 Subject: [issue2451] No way to disable socket timeouts in httplib, etc. In-Reply-To: <1206141378.11.0.857343736887.issue2451@psf.upfronthosting.co.za> Message-ID: <1206144018.88.0.817603696104.issue2451@psf.upfronthosting.co.za> John J Lee added the comment: I see this thread: http://www.gossamer-threads.com/lists/python/dev/552292 But I don't see an explanation of this API decision there that I understand. *Because* socket.setdefaulttimeout() is a hack for when nothing else is available, there should be a way to avoid that global state. You say that "Now that you can pass the timeout when creating the connection, you shouldn't use the default setting.". That's true, for new code, and for code is able to immediately change -- indeed, that always has been true. Code exists that makes use of socket.setdefaulttimeout(), or requires use of it in order to set a timeout. Can you explain why this state of affairs makes it necessary to force this global state on users of httplib? __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 01:27:26 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 22 Mar 2008 00:27:26 +0000 Subject: [issue2451] No way to disable socket timeouts in httplib, etc. In-Reply-To: <1206141378.11.0.857343736887.issue2451@psf.upfronthosting.co.za> Message-ID: <1206145646.16.0.870543227852.issue2451@psf.upfronthosting.co.za> Facundo Batista added the comment: Two or three threads run in parallel at that time for this issue, don't remember exactly where this was decided. > *Because* socket.setdefaulttimeout() is a hack for when nothing else is > available, there should be a way to avoid that global state. Yes: don't call setdefaulttimeout(). > socket.setdefaulttimeout(), or requires use of it in order to set a > timeout. Can you explain why this state of affairs makes it necessary > to force this global state on users of httplib? The issue is that to allow caller to override the default state you should pass it None, but None is for default timeout value in the call, so you should be passing a specific object to mean "override default timeout", etc... all this is well explained in that thread. Lot of suggestions were handled, and the final decision was that all that behaviours will complicate unnecessarily the semantics here (with the cost of not being able to override the global default). I suggest you to raise the discussion again in python-dev if you want this decided behaviour to change. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 01:37:14 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 22 Mar 2008 00:37:14 +0000 Subject: [issue908441] default index for __getslice__ is not sys.maxint Message-ID: <1206146234.87.0.970993675748.issue908441@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This has been fixed around r42454. ---------- nosy: +belopolsky ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Mar 22 01:49:33 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 22 Mar 2008 00:49:33 +0000 Subject: [issue2453] fix_except needs to allow for empty excepts In-Reply-To: <1206146973.79.0.293123214296.issue2453@psf.upfronthosting.co.za> Message-ID: <1206146973.79.0.293123214296.issue2453@psf.upfronthosting.co.za> New submission from Martin v. L?wis : The code try: f() except X,a: g() except: h() currently doesn't get changed, but should be converted to try: f() except X as a: g() except: h() ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 64303 nosy: collinwinter, loewis severity: normal status: open title: fix_except needs to allow for empty excepts type: behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 01:50:48 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 22 Mar 2008 00:50:48 +0000 Subject: [issue2450] urllib2.Request constructor has no timeout parameter In-Reply-To: <1206140289.07.0.166217155748.issue2450@psf.upfronthosting.co.za> Message-ID: <1206147048.53.0.414423635813.issue2450@psf.upfronthosting.co.za> Facundo Batista added the comment: The argument timeout can not have the same semantics than data, see the following cases: - r = Request(url) - urlopen(r, data="foo") - # data is "foo" - r = Request(url, data="foo") - urlopen(r) - # data is "foo" - r = Request(url, data="foo") - urlopen(r, data="bar") - # data is "bar" So, what would happen if you put timeout in Request: - r = Request(url, timeout=3) - urlopen(r, timeout=10) - # here, the final timeout can be 10, no problem! - r = Request(url, timeout=3) - urlopen(r) - # Oops! In this last one, which the final timeout should be? None, as you passed that to urlopen()? Or the original 3 from the Request? With data you can do it, because None has no meaning, so only you replace the Request value if actually you passed something in urlopen(). But for timeout, None *has* a meaning... ---------- resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 02:00:45 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 22 Mar 2008 01:00:45 +0000 Subject: [issue2454] md5 fixer In-Reply-To: <1206147643.89.0.60936055638.issue2454@psf.upfronthosting.co.za> Message-ID: <1206147643.89.0.60936055638.issue2454@psf.upfronthosting.co.za> New submission from Martin v. L?wis : Usages of the md5 module could be fixed, as it's unavailable in 3k. In particular: import md5 -> import hashlib md5.new(...) -> hashlib.md5(...) md5.md5(...) -> hashlib.md5(...) Notice that users could already change this manually in 2.6, since hashlib is available since 2.5, so the fixer is not strictly needed, but would be convenient. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 64305 nosy: collinwinter, loewis severity: normal status: open title: md5 fixer __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 02:02:20 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 22 Mar 2008 01:02:20 +0000 Subject: [issue2454] md5 fixer In-Reply-To: <1206147643.89.0.60936055638.issue2454@psf.upfronthosting.co.za> Message-ID: <1206147740.7.0.744710485682.issue2454@psf.upfronthosting.co.za> Gregory P. Smith added the comment: And do the same for: sha.sha1 -> hashlib.sha1 sha.new -> hashlib.sha1 ---------- nosy: +gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 02:03:27 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 22 Mar 2008 01:03:27 +0000 Subject: [issue2454] sha and md5 fixer In-Reply-To: <1206147643.89.0.60936055638.issue2454@psf.upfronthosting.co.za> Message-ID: <1206147807.67.0.801053851975.issue2454@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- title: md5 fixer -> sha and md5 fixer __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 02:05:18 2008 From: report at bugs.python.org (John J Lee) Date: Sat, 22 Mar 2008 01:05:18 +0000 Subject: [issue2450] urllib2.Request constructor has no timeout parameter In-Reply-To: <1206140289.07.0.166217155748.issue2450@psf.upfronthosting.co.za> Message-ID: <1206147918.34.0.73980083067.issue2450@psf.upfronthosting.co.za> John J Lee added the comment: This should be solved by introducing a "not set" value other than None. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 02:11:19 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 22 Mar 2008 01:11:19 +0000 Subject: [issue2450] urllib2.Request constructor has no timeout parameter In-Reply-To: <1206140289.07.0.166217155748.issue2450@psf.upfronthosting.co.za> Message-ID: <1206148279.21.0.423575139984.issue2450@psf.upfronthosting.co.za> Facundo Batista added the comment: As I wrote in the other bug that you opened (#2451), introducing this will complicate the usage and semantics of what is already established and working. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 02:19:07 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 22 Mar 2008 01:19:07 +0000 Subject: [issue974635] Slice indexes passed to __getitem__ are wrapped Message-ID: <1206148747.42.0.790172098586.issue974635@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This looks like a duplicate of issue723806 which was closed as "won't fix." ---------- components: +Interpreter Core -None nosy: +belopolsky type: -> behavior ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Mar 22 03:25:16 2008 From: report at bugs.python.org (Andrey Skvortsov) Date: Sat, 22 Mar 2008 02:25:16 +0000 Subject: [issue2455] stat.ST_CTIME and stat.ST_ATIME problem In-Reply-To: <1206152716.81.0.392707028584.issue2455@psf.upfronthosting.co.za> Message-ID: <1206152716.81.0.392707028584.issue2455@psf.upfronthosting.co.za> New submission from Andrey Skvortsov : stat.ST_CTIME and stat.ST_ATIME are mixed up. ST_CTIME gives access time and should be ST_ATIME and vice versa ST_ATIME gives creation time. Linux. ---------- components: Library (Lib) messages: 64310 nosy: sassas severity: normal status: open title: stat.ST_CTIME and stat.ST_ATIME problem versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 03:28:25 2008 From: report at bugs.python.org (John J Lee) Date: Sat, 22 Mar 2008 02:28:25 +0000 Subject: [issue2450] urllib2.Request constructor has no timeout parameter In-Reply-To: <1206140289.07.0.166217155748.issue2450@psf.upfronthosting.co.za> Message-ID: <1206152905.07.0.428169208403.issue2450@psf.upfronthosting.co.za> John J Lee added the comment: I don't buy the "API complication" argument. I might accept an argument that the timeout isn't really anything to do with the request, so I won't bother to continue with this bug report. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 03:40:03 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 22 Mar 2008 02:40:03 +0000 Subject: [issue2351] Using __(get|set|del)slice__ needs a Py3K warning In-Reply-To: <1205781950.27.0.373262403041.issue2351@psf.upfronthosting.co.za> Message-ID: <1206153603.74.0.0660241009152.issue2351@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Here's a patch for that. It gives warnings on use of __getslice__, __delslice__, and __setslice__ and includes tests. But it only works on new style classes. I don't think this is a big problem because users will see the warnings when they switch their classes to new-style. ---------- keywords: +patch nosy: +benjamin.peterson Added file: http://bugs.python.org/file9808/slice_methods_py3kwarn.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 03:46:06 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 22 Mar 2008 02:46:06 +0000 Subject: [issue2273] test_decimal: possible thread lockup in test case In-Reply-To: <1205253975.75.0.189662720786.issue2273@psf.upfronthosting.co.za> Message-ID: <1206153966.25.0.298807632291.issue2273@psf.upfronthosting.co.za> Facundo Batista added the comment: Commited in r61731. Thank you both! ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 04:19:40 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sat, 22 Mar 2008 03:19:40 +0000 Subject: [issue2281] Enhanced cPython profiler with high-resolution timer In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za> Message-ID: <1206155980.62.0.689012687779.issue2281@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: I don't think this should be added to 2.5. Only bugfixes are admissible to the backporting process (see PEP 6). Finally, could you post the diff of your changes as described at http://www.python.org/dev/patches/. Thanks! ---------- components: +Extension Modules -None keywords: +patch nosy: +alexandre.vassalotti priority: -> normal type: -> performance __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 05:06:29 2008 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 22 Mar 2008 04:06:29 +0000 Subject: [issue1605] Semi autogenerated _types module In-Reply-To: <1206138769.26.0.389208549836.issue1605@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > Well, okay. I still think we should expose these core interpreter types > somehow, so people can identify types easily. I don't want to be forced > to finding the type of sys._getframe to tell if I have a frame object on > my hands. Where would you put them? Perhaps that one belongs together with sys._getframe? You don't seem to be getting my point (or you are purposely ignoring it), and this is frustrating for me. If these types must be exposed they should be each be exposed in a a module (new or existing) that defines other objects (types, functions, constants, what have you) with a related purpose. So maybe dict views etc. can be in collections. And maybe module, function, class, properties, some standard decorators (classmethod, staticmethod) and various types of methods and method wrappers can be in a module that packages code structures. OTOH code, frame, traceback may be more suitable for a low-level module (although I'm not sure about traceback, perhaps it is closer exceptions). Many types of iterators may best be placed in itertools (which defines them in the first place, many operations there already *are* their own type). But the iterators over the built-in collection types (list, dict etc.) should probably live in collections again. You see, coming up with a meaningful grouping is not all that easy -- but that's no reason to lump them all together in a "built-in-types" module. Another criterion for grouping is whether the types make sense for other implementations like Jython, IronPython or PyPy, or not. I'm all for exposing these. But I'm 100% against just collecting all those types and putting them in a single grab-bag module. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 09:13:07 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Mar 2008 08:13:07 +0000 Subject: [issue908441] default index for __getslice__ is not sys.maxint Message-ID: <1206173587.01.0.572831254484.issue908441@psf.upfronthosting.co.za> Georg Brandl added the comment: Closing as Fixed. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Mar 22 11:07:42 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Mar 2008 10:07:42 +0000 Subject: [issue1918] weak references are removed before __del__ is called. In-Reply-To: <1201113256.5.0.101842324307.issue1918@psf.upfronthosting.co.za> Message-ID: <1206180462.45.0.254434468912.issue1918@psf.upfronthosting.co.za> Georg Brandl added the comment: Done in r61733. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 12:23:19 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 22 Mar 2008 11:23:19 +0000 Subject: [issue2349] Py3K warn against assigning to True/False In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za> Message-ID: <1206184999.43.0.789089878629.issue2349@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Keep what you've got but don't lose sleep if some offbeat case is not covered. ---------- assignee: rhettinger -> brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 13:14:21 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 22 Mar 2008 12:14:21 +0000 Subject: [issue1721812] A subclass of set doesn't always have __init__ called. Message-ID: <1206188061.92.0.766328083584.issue1721812@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Attaching a possible fix (untested). ---------- keywords: +patch Added file: http://bugs.python.org/file9809/set.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 22 13:56:48 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sat, 22 Mar 2008 12:56:48 +0000 Subject: [issue1943] improved allocation of PyUnicode objects In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za> Message-ID: <1206190608.8.0.299031855222.issue1943@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I wasn't clear enough: my point was that your free list patch would probably benefit from some tuning of the cut-off parameters. 15 characters appears to be too small (see the HISTORY file histogram). You'll likely get better results for 32 and 256 as cut-off values and by increasing the max list sizes to higher values, e.g. 1024 for the 32 character slots and 146 for the 256 character slots (see the counts in the histograms). __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 14:18:42 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 22 Mar 2008 13:18:42 +0000 Subject: [issue1605] Semi autogenerated _types module In-Reply-To: Message-ID: <1afaf6160803220618q4cc97f98s4a30463c870f5ed4@mail.gmail.com> Benjamin Peterson added the comment: On Fri, Mar 21, 2008 at 11:06 PM, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > > Well, okay. I still think we should expose these core interpreter types > > somehow, so people can identify types easily. I don't want to be forced > > to finding the type of sys._getframe to tell if I have a frame object > on > > my hands. Where would you put them? > > Perhaps that one belongs together with sys._getframe? > > You don't seem to be getting my point (or you are purposely ignoring > it), and this is frustrating for me. If these types must be exposed > they should be each be exposed in a a module (new or existing) that > defines other objects (types, functions, constants, what have you) > with a related purpose. So maybe dict views etc. can be in > collections. And maybe module, function, class, properties, some > standard decorators (classmethod, staticmethod) and various types of > methods and method wrappers can be in a module that packages code > structures. OTOH code, frame, traceback may be more suitable for a > low-level module (although I'm not sure about traceback, perhaps it is > closer exceptions). Many types of iterators may best be placed in > itertools (which defines them in the first place, many operations > there already *are* their own type). But the iterators over the > built-in collection types (list, dict etc.) should probably live in > collections again. I understand your point; I just didn't understand the extent that you want to go to. > > > You see, coming up with a meaningful grouping is not all that easy -- > but that's no reason to lump them all together in a "built-in-types" > module. Another criterion for grouping is whether the types make sense > for other implementations like Jython, IronPython or PyPy, or not. It is indeed hard. > > > I'm all for exposing these. But I'm 100% against just collecting all > those types and putting them in a single grab-bag module. > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file9810/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080322/2e60587a/attachment.txt From report at bugs.python.org Sat Mar 22 15:34:58 2008 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Sat, 22 Mar 2008 14:34:58 +0000 Subject: [issue1477] UnicodeDecodeError that cannot be caught in narrow unicode builds In-Reply-To: <1195593459.02.0.388666867716.issue1477@psf.upfronthosting.co.za> Message-ID: <1206196497.98.0.219750346056.issue1477@psf.upfronthosting.co.za> Walter D?rwald added the comment: The patch looks goog to me now. Go ahead and check it in. ---------- assignee: doerwalter -> amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 15:42:02 2008 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Sat, 22 Mar 2008 14:42:02 +0000 Subject: [issue1328] Force BOM option in UTF output. In-Reply-To: <1193353176.1.0.485065586233.issue1328@psf.upfronthosting.co.za> Message-ID: <1206196922.38.0.525541881254.issue1328@psf.upfronthosting.co.za> Walter D?rwald added the comment: If you want to use UTF-8-sig for decoding and UTF-8 for encoding and have this available as one codec you can define your owen codec for this: import codecs def search_function(name): if name == "myutf8": utf8 = codecs.lookup("utf-8") utf8_sig = codecs.lookup("utf-8-sig") return codecs.CodecInfo( name='myutf8', encode=utf8.encode, decode=utf8_sig.decode, incrementalencoder=utf8.IncrementalEncoder, incrementaldecoder=utf8_sig.IncrementalDecoder, streamreader=utf8_sig.StreamReader, streamwriter=utf8.StreamWriter, ) codecs.register(search_function) Closing the issue as "wont fix" ---------- resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 15:44:53 2008 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Sat, 22 Mar 2008 14:44:53 +0000 Subject: [issue1328] Force BOM option in UTF output. In-Reply-To: <1193353176.1.0.485065586233.issue1328@psf.upfronthosting.co.za> Message-ID: <1206197093.52.0.326797711838.issue1328@psf.upfronthosting.co.za> Walter D?rwald added the comment: Oops, that code was supposed to read: import codecs def search_function(name): if name == "myutf8": utf8 = codecs.lookup("utf-8") utf8_sig = codecs.lookup("utf-8-sig") return codecs.CodecInfo( name='myutf8', encode=utf8.encode, decode=utf8_sig.decode, incrementalencoder=utf8.incrementalencoder, incrementaldecoder=utf8_sig.incrementaldecoder, streamreader=utf8_sig.streamreader, streamwriter=utf8.streamwriter, ) codecs.register(search_function) __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 15:51:30 2008 From: report at bugs.python.org (Guilherme Polo) Date: Sat, 22 Mar 2008 14:51:30 +0000 Subject: [issue1054434] automatic XMLRPC boxcarring via multicall for xmlrpclib Message-ID: <1206197490.8.0.654630734639.issue1054434@psf.upfronthosting.co.za> Guilherme Polo added the comment: I see these multicall classes (including tests) in python-trunk, except for the threaded one. So, should this remain open ? If yes, what has to be done here ? ---------- nosy: +gpolo _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 22 15:53:27 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 22 Mar 2008 14:53:27 +0000 Subject: [issue2456] Make sysmodule.c compatible with Bazaar In-Reply-To: <1206197607.7.0.946463718632.issue2456@psf.upfronthosting.co.za> Message-ID: <1206197607.7.0.946463718632.issue2456@psf.upfronthosting.co.za> New submission from Barry A. Warsaw : For the Bazaar experiment , sysmodule.c needs to be made compatible with Bazaar, for build number display. ---------- assignee: barry components: Interpreter Core messages: 64327 nosy: barry priority: normal severity: normal status: open title: Make sysmodule.c compatible with Bazaar type: crash versions: Python 2.5, Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 15:59:25 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Sat, 22 Mar 2008 14:59:25 +0000 Subject: [issue2385] run_setup can fail if the setup script uses __file__ In-Reply-To: <1205835874.17.0.090976046813.issue2385@psf.upfronthosting.co.za> Message-ID: <1206197964.94.0.935088081109.issue2385@psf.upfronthosting.co.za> Tarek Ziad? added the comment: new patch that adds __main__ and __file__, and make a chdir, so the function is called in a realistic way. this patch also adds test_core.py for this change. Added file: http://bugs.python.org/file9811/2008-03-28-distutils.core.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 15:59:31 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Sat, 22 Mar 2008 14:59:31 +0000 Subject: [issue2385] run_setup can fail if the setup script uses __file__ In-Reply-To: <1205835874.17.0.090976046813.issue2385@psf.upfronthosting.co.za> Message-ID: <1206197971.3.0.402100519345.issue2385@psf.upfronthosting.co.za> Changes by Tarek Ziad? : Removed file: http://bugs.python.org/file9724/distutils.core.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 16:00:02 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Sat, 22 Mar 2008 15:00:02 +0000 Subject: [issue1858] Make .pypirc handle multiple servers In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za> Message-ID: <1206198002.79.0.193388063386.issue1858@psf.upfronthosting.co.za> Changes by Tarek Ziad? : Removed file: http://bugs.python.org/file9489/distutils.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 16:00:09 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Sat, 22 Mar 2008 15:00:09 +0000 Subject: [issue1858] Make .pypirc handle multiple servers In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za> Message-ID: <1206198009.17.0.371346874812.issue1858@psf.upfronthosting.co.za> Changes by Tarek Ziad? : Removed file: http://bugs.python.org/file9503/bugday.distutils.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 16:00:06 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Sat, 22 Mar 2008 15:00:06 +0000 Subject: [issue1858] Make .pypirc handle multiple servers In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za> Message-ID: <1206198006.0.0.509030699963.issue1858@psf.upfronthosting.co.za> Changes by Tarek Ziad? : Removed file: http://bugs.python.org/file9500/bugday-distutils.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 16:00:15 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Sat, 22 Mar 2008 15:00:15 +0000 Subject: [issue1858] Make .pypirc handle multiple servers In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za> Message-ID: <1206198015.15.0.0424217727178.issue1858@psf.upfronthosting.co.za> Changes by Tarek Ziad? : Removed file: http://bugs.python.org/file9652/distutils.2008.03.11.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 16:00:20 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Sat, 22 Mar 2008 15:00:20 +0000 Subject: [issue1858] Make .pypirc handle multiple servers In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za> Message-ID: <1206198020.64.0.258392792702.issue1858@psf.upfronthosting.co.za> Changes by Tarek Ziad? : Removed file: http://bugs.python.org/file9653/distutils.2008.03.11.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 16:00:12 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Sat, 22 Mar 2008 15:00:12 +0000 Subject: [issue1858] Make .pypirc handle multiple servers In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za> Message-ID: <1206198012.59.0.932860523667.issue1858@psf.upfronthosting.co.za> Changes by Tarek Ziad? : Removed file: http://bugs.python.org/file9614/distutils.2008-03-05.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 16:02:54 2008 From: report at bugs.python.org (Guilherme Polo) Date: Sat, 22 Mar 2008 15:02:54 +0000 Subject: [issue1613573] xmlrpclib ServerProxy uses old httplib interface Message-ID: <1206198174.35.0.128886364527.issue1613573@psf.upfronthosting.co.za> Guilherme Polo added the comment: There is another patch regarding the use of HTTP/1.1 for xmlrpclib at http://bugs.python.org/issue1767370. The other issue could be update with some comments from this issue and then this issue could be closed, I believe. ---------- nosy: +gpolo _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 22 17:45:04 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 22 Mar 2008 16:45:04 +0000 Subject: [issue2013] Long object free list optimization In-Reply-To: <1202180868.04.0.23342807926.issue2013@psf.upfronthosting.co.za> Message-ID: <1206204304.36.0.0530168742105.issue2013@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here are some updated timings against the current py3k branch: $ ./python -m timeit "sum(range(10000))" Without patch: 1000 loops, best of 3: 675 usec per loop With patch: 1000 loops, best of 3: 462 usec per loop $ ./python -m timeit -s "n=1000000" "sum(range(n, n+10000))" Without patch: 1000 loops, best of 3: 1.36 msec per loop With patch: 1000 loops, best of 3: 1.38 msec per loop $ ./python -m timeit "min(range(255))" Without patch: 10000 loops, best of 3: 18.7 usec per loop With patch: 10000 loops, best of 3: 19.4 usec per loop As you can see the patch makes things quite a bit better for 1-digit long objects, and there is only a small slowdown for longer or tiny ints. Given that 1-digit long objects should be prevalent in most code I think it's probably a winner overall. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 18:42:39 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 22 Mar 2008 17:42:39 +0000 Subject: [issue2456] Make sysmodule.c compatible with Bazaar In-Reply-To: <1206197607.7.0.946463718632.issue2456@psf.upfronthosting.co.za> Message-ID: <1206207759.65.0.939398034959.issue2456@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 19:01:18 2008 From: report at bugs.python.org (Jean Brouwers) Date: Sat, 22 Mar 2008 18:01:18 +0000 Subject: [issue2281] Enhanced cPython profiler with high-resolution timer In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za> Message-ID: <1206208878.01.0.0414175547903.issue2281@psf.upfronthosting.co.za> Jean Brouwers added the comment: Here are 2 forward diff files against _lspprof.c rev 59564. One _lsprof2.6.diff for Python 2.6a1 and _lsprof3.0.diff for 3.0. Added file: http://bugs.python.org/file9812/_lsprof2.6.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 19:02:49 2008 From: report at bugs.python.org (Jean Brouwers) Date: Sat, 22 Mar 2008 18:02:49 +0000 Subject: [issue2281] Enhanced cPython profiler with high-resolution timer In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za> Message-ID: <1206208969.63.0.282071728623.issue2281@psf.upfronthosting.co.za> Changes by Jean Brouwers : ---------- versions: +Python 3.0 -Python 2.5 Added file: http://bugs.python.org/file9813/_lsprof3.0.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 19:07:49 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 22 Mar 2008 18:07:49 +0000 Subject: [issue1762940] struni: test_urllib2, test_cookielib Message-ID: <1206209266.82.0.881082909558.issue1762940@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think the patch was wrong. I question whether urllib *should* work on str at all, given that URLs are byte strings. In any case, the quoting is incorrect for str; it should implement rfc 3987, but currently does a mixture of Latin-1 and UTF-8. ---------- nosy: +loewis _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 22 20:04:30 2008 From: report at bugs.python.org (Guilherme Polo) Date: Sat, 22 Mar 2008 19:04:30 +0000 Subject: [issue1081824] Rewrite of docs for compiler.visitor Message-ID: <1206212670.35.0.752449915179.issue1081824@psf.upfronthosting.co.za> Guilherme Polo added the comment: I have done some changes and did a patch against python-trunk ---------- nosy: +gpolo Added file: http://bugs.python.org/file9814/compiler.visitor_doc_update.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 22 20:31:31 2008 From: report at bugs.python.org (Jean Brouwers) Date: Sat, 22 Mar 2008 19:31:31 +0000 Subject: [issue2218] Enhanced hotshot profiler with high-resolution timer In-Reply-To: <1204501511.28.0.993763550383.issue2218@psf.upfronthosting.co.za> Message-ID: <1206214291.76.0.523922088115.issue2218@psf.upfronthosting.co.za> Jean Brouwers added the comment: Here are the forward diffs of the 3 files against the version in the trunk. ---------- versions: +Python 2.6 -Python 2.5 Added file: http://bugs.python.org/file9815/hires_hotshot_2.6.diffs.tgz __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 20:41:12 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 22 Mar 2008 19:41:12 +0000 Subject: [issue2457] add --help and -h options to pdb In-Reply-To: <1206214872.65.0.48935135608.issue2457@psf.upfronthosting.co.za> Message-ID: <1206214872.65.0.48935135608.issue2457@psf.upfronthosting.co.za> New submission from Benjamin Peterson : If --help or -h are used as options for pdb, pdb unhelpfully exits with "file -h cannot be found." This makes it more user friendly and prints the usage if those options are passed. ---------- components: Demos and Tools, Library (Lib) files: pdb_help.patch keywords: patch messages: 64336 nosy: benjamin.peterson severity: normal status: open title: add --help and -h options to pdb type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file9816/pdb_help.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 20:54:15 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 22 Mar 2008 19:54:15 +0000 Subject: [issue2013] Long object free list optimization In-Reply-To: <1202180868.04.0.23342807926.issue2013@psf.upfronthosting.co.za> Message-ID: <1206215655.51.0.875985179843.issue2013@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I'm attaching a slightly improved version of the longfreelist2 patch. It moves the important test to be first and removes the unneeded ? : conditional. ........................ Here are some more benchmarks: ........................ --- issue2013-without-patch.txt 2008-03-22 12:18:37.000000000 -0700 +++ issue2013-longfreelist2-gps01-size-first.txt 2008-03-22 12:34:44.000000000 -0700 @@ -1,43 +1,43 @@ -3.0a3+ (py3k:61746M, Mar 22 2008, 12:12:29) +3.0a3+ (py3k:61746M, Mar 22 2008, 12:33:47) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] ./python.exe -m timeit min(range(255)) -100000 loops, best of 3: 17.2 usec per loop +100000 loops, best of 3: 15.8 usec per loop ./python.exe -m timeit -s n=1000000 sum(range(n,n+10000)) -1000 loops, best of 3: 1.21 msec per loop +1000 loops, best of 3: 1.22 msec per loop ./python.exe -m timeit sum(range(-32768,32768)) -100 loops, best of 3: 3.98 msec per loop +100 loops, best of 3: 2.63 msec per loop ./python.exe -m timeit sum(range(-1000000,1000000)) -10 loops, best of 3: 296 msec per loop +10 loops, best of 3: 273 msec per loop ./python.exe -m timeit sum(range(4000)) -1000 loops, best of 3: 239 usec per loop +10000 loops, best of 3: 151 usec per loop ./python.exe -m timeit sum(list(range(4000))) -1000 loops, best of 3: 360 usec per loop +1000 loops, best of 3: 274 usec per loop ./python.exe -m timeit sum(range(10000)) -1000 loops, best of 3: 615 usec per loop +1000 loops, best of 3: 382 usec per loop ./python.exe -m timeit sum(list(range(10000))) -1000 loops, best of 3: 887 usec per loop +1000 loops, best of 3: 802 usec per loop ./python.exe -m timeit sum(range(40000)) -100 loops, best of 3: 2.55 msec per loop +100 loops, best of 3: 1.79 msec per loop ./python.exe -m timeit sum(range(80000)) -100 loops, best of 3: 6.4 msec per loop +100 loops, best of 3: 5.77 msec per loop ........................ And a benchmarks of the longfreelist2 patch before my improvement: ........................ --- issue2013-without-patch.txt 2008-03-22 12:18:37.000000000 -0700 +++ issue2013-longfreelist2.txt 2008-03-22 12:19:46.000000000 -0700 @@ -1,43 +1,43 @@ -3.0a3+ (py3k:61746M, Mar 22 2008, 12:12:29) +3.0a3+ (py3k:61746M, Mar 22 2008, 12:18:57) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] ./python.exe -m timeit min(range(255)) -100000 loops, best of 3: 17.2 usec per loop +100000 loops, best of 3: 16.1 usec per loop ./python.exe -m timeit -s n=1000000 sum(range(n,n+10000)) -1000 loops, best of 3: 1.21 msec per loop +1000 loops, best of 3: 1.25 msec per loop ./python.exe -m timeit sum(range(-32768,32768)) -100 loops, best of 3: 3.98 msec per loop +100 loops, best of 3: 2.95 msec per loop ./python.exe -m timeit sum(range(-1000000,1000000)) -10 loops, best of 3: 296 msec per loop +10 loops, best of 3: 283 msec per loop ./python.exe -m timeit sum(range(4000)) -1000 loops, best of 3: 239 usec per loop +1000 loops, best of 3: 177 usec per loop ./python.exe -m timeit sum(list(range(4000))) -1000 loops, best of 3: 360 usec per loop +1000 loops, best of 3: 276 usec per loop ./python.exe -m timeit sum(range(10000)) -1000 loops, best of 3: 615 usec per loop +1000 loops, best of 3: 453 usec per loop ./python.exe -m timeit sum(list(range(10000))) -1000 loops, best of 3: 887 usec per loop +1000 loops, best of 3: 792 usec per loop ./python.exe -m timeit sum(range(40000)) -100 loops, best of 3: 2.55 msec per loop +100 loops, best of 3: 2.03 msec per loop ./python.exe -m timeit sum(range(80000)) -100 loops, best of 3: 6.4 msec per loop +100 loops, best of 3: 6.01 msec per loop ........................ And diffs of longfreelist2 vs longfreelist2-gps01: ........................ --- issue2013-longfreelist2.txt 2008-03-22 12:19:46.000000000 -0700 +++ issue2013-longfreelist2-gps01-size-first.txt 2008-03-22 12:34:44.000000000 -0700 @@ -1,43 +1,43 @@ -3.0a3+ (py3k:61746M, Mar 22 2008, 12:18:57) +3.0a3+ (py3k:61746M, Mar 22 2008, 12:33:47) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] ./python.exe -m timeit min(range(255)) -100000 loops, best of 3: 16.1 usec per loop +100000 loops, best of 3: 15.8 usec per loop ./python.exe -m timeit -s n=1000000 sum(range(n,n+10000)) -1000 loops, best of 3: 1.25 msec per loop +1000 loops, best of 3: 1.22 msec per loop ./python.exe -m timeit sum(range(-32768,32768)) -100 loops, best of 3: 2.95 msec per loop +100 loops, best of 3: 2.63 msec per loop ./python.exe -m timeit sum(range(-1000000,1000000)) -10 loops, best of 3: 283 msec per loop +10 loops, best of 3: 273 msec per loop ./python.exe -m timeit sum(range(4000)) -1000 loops, best of 3: 177 usec per loop +10000 loops, best of 3: 151 usec per loop ./python.exe -m timeit sum(list(range(4000))) -1000 loops, best of 3: 276 usec per loop +1000 loops, best of 3: 274 usec per loop ./python.exe -m timeit sum(range(10000)) -1000 loops, best of 3: 453 usec per loop +1000 loops, best of 3: 382 usec per loop ./python.exe -m timeit sum(list(range(10000))) -1000 loops, best of 3: 792 usec per loop +1000 loops, best of 3: 802 usec per loop ./python.exe -m timeit sum(range(40000)) -100 loops, best of 3: 2.03 msec per loop +100 loops, best of 3: 1.79 msec per loop ./python.exe -m timeit sum(range(80000)) -100 loops, best of 3: 6.01 msec per loop +100 loops, best of 3: 5.77 msec per loop ---------- nosy: +gregory.p.smith type: feature request -> performance versions: -Python 2.6 Added file: http://bugs.python.org/file9817/py3k_longfreelist2-gps01.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 21:36:35 2008 From: report at bugs.python.org (David Wolever) Date: Sat, 22 Mar 2008 20:36:35 +0000 Subject: [issue2446] 2to3 translates "import foobar" to "import .foobar" rather than "from . import foobar" In-Reply-To: <1206122382.01.0.177794619684.issue2446@psf.upfronthosting.co.za> Message-ID: <1206218195.43.0.829581847327.issue2446@psf.upfronthosting.co.za> David Wolever added the comment: Ok, I've fixed this in r61755. I _think_ it does the right thing, but it might be good if someone else checks out the test cases to make sure. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 22:29:05 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 22 Mar 2008 21:29:05 +0000 Subject: [issue2458] Allow Python code to change Py3k warning flag In-Reply-To: <1206221345.67.0.966605700107.issue2458@psf.upfronthosting.co.za> Message-ID: <1206221345.67.0.966605700107.issue2458@psf.upfronthosting.co.za> New submission from Benjamin Peterson : This patch removed sys.py3kwarning and adds sys.getpy3kwarn, sys.enablepy3kwarn, and sys.disablepy3kwarn with docs. I also changed the places in the Lib which used sys.py3kwarning. ---------- files: change_py3kwarning.patch keywords: patch messages: 64339 nosy: benjamin.peterson severity: normal status: open title: Allow Python code to change Py3k warning flag type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file9818/change_py3kwarning.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 22:35:26 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 22 Mar 2008 21:35:26 +0000 Subject: [issue1081824] Rewrite of docs for compiler.visitor Message-ID: <1206221726.86.0.804491518325.issue1081824@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: jhylton -> georg.brandl nosy: +georg.brandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 22 22:35:54 2008 From: report at bugs.python.org (Guilherme Polo) Date: Sat, 22 Mar 2008 21:35:54 +0000 Subject: [issue964437] idle help is modal Message-ID: <1206221754.24.0.510703857446.issue964437@psf.upfronthosting.co.za> Guilherme Polo added the comment: Hi, This patch makes Help dialog executes as nonmodal. I added a new button at textView.py to demonstrate the behavior, also, I created a decorator called _singledialog at EditorWindow so just one Help window executes at a time, trying to start a new brings the current one to the front. I hope this issue is not totally dead, so someone could review and possible apply. ---------- keywords: +patch nosy: +gpolo Added file: http://bugs.python.org/file9819/help_nonmodal.diff ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Mar 22 23:08:32 2008 From: report at bugs.python.org (Guilherme Polo) Date: Sat, 22 Mar 2008 22:08:32 +0000 Subject: [issue1691411] Duplicate "preferences" menu item/Tk Aqua 8.4.14 Message-ID: <1206223712.88.0.694708552827.issue1691411@psf.upfronthosting.co.za> Guilherme Polo added the comment: Someone should close this as it has been fixed already. ---------- nosy: +gpolo _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 22 23:25:05 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 22 Mar 2008 22:25:05 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224705.13.0.0890165071291.issue2459@psf.upfronthosting.co.za> Message-ID: <1206224705.13.0.0890165071291.issue2459@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This is a preliminary patch to speedup for and while loops (it will also be able to speedup list comps and gen comps, if I get to do it). The patch works by putting the loop condition test at the end of loop, which allows removing one JUMP_ABSOLUTE byte code out of the critical path. For this two new opcodes are introduced: - FOR_ITER2 is the same as FOR_ITER except that it does an /absolute/ jump if the iterator is /not/ exhausted (when other uses of FOR_ITER are replaced with FOR_ITER2, we can of course restore the original naming) - JUMP_ABS_IF_TRUE /pops/ the top of the stack and does an absolute jump if its value is true Some micro-benchmarks: ./python -m timeit "for x in xrange(10000): pass" Before: 1000 loops, best of 3: 782 usec per loop After: 1000 loops, best of 3: 412 usec per loop ./python -m timeit -s "x=10000" "while x: x -= 1" Before: 1000000 loops, best of 3: 0.237 usec per loop After: 10000000 loops, best of 3: 0.176 usec per loop ./python Tools/pybench/pybench.py -t ForLoops Before: 365ms per round After: 234ms per round Also, pystone gets 5% faster (from 43300 to 45800). Now for the less shiny things: 1. I'm having problems modifying the pure Python compiler module. For some reasons it seems to have stricter requirements than compile.c itself does (!); I get some assertion error in compiler.pyassem.FlowGraph.fixupOrderHonorNext as soon as a loop gets non-trivial. 2. Line numbers probably need to be fixed. The lnotab format may even have to be adapted in order to accomodate non-monotonically increasing line numbers. Is there some interest in this patch? If yes, I'd like to have your input on the two bullet points above :) ---------- components: Interpreter Core files: loops.patch keywords: patch messages: 64342 nosy: pitrou severity: normal status: open title: speedup loops with better bytecode type: performance versions: Python 2.6 Added file: http://bugs.python.org/file9820/loops.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 23:28:29 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 22 Mar 2008 22:28:29 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224705.13.0.0890165071291.issue2459@psf.upfronthosting.co.za> Message-ID: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is a preliminary patch to speedup for and while loops (it will also be able to speedup list comps and gen comps, if I get to do it). The patch works by putting the loop condition test at the end of loop, which allows removing one JUMP_ABSOLUTE byte code out of the critical path. For this two new opcodes are introduced: - FOR_ITER2 is the same as FOR_ITER except that it does an /absolute/ jump if the iterator is /not/ exhausted (when other uses of FOR_ITER are replaced with FOR_ITER2, we can of course restore the original naming) - JUMP_ABS_IF_TRUE /pops/ the top of the stack and does an absolute jump if its value is true Some micro-benchmarks: ./python -m timeit "for x in xrange(10000): pass" Before: 1000 loops, best of 3: 782 usec per loop After: 1000 loops, best of 3: 412 usec per loop ./python -m timeit "x=100" "while x: x -= 1" Before: 10000 loops, best of 3: 22.1 usec per loop After: 100000 loops, best of 3: 16.6 usec per loop ./python Tools/pybench/pybench.py -t ForLoops Before: 365ms per round After: 234ms per round Also, pystone gets 5% faster (from 43300 to 45800). Now for the less shiny things: 1. I'm having problems modifying the pure Python compiler module. For some reasons it seems to have stricter requirements than compile.c itself does (!); I get some assertion error in compiler.pyassem.FlowGraph.fixupOrderHonorNext as soon as a loop gets non-trivial. 2. Line numbers probably need to be fixed. The lnotab format may even have to be adapted in order to accomodate non-monotonically increasing line numbers. Is there some interest in this patch? If yes, I'd like to have your input on the two bullet points above :) __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 22 23:45:05 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 22 Mar 2008 22:45:05 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224705.13.0.0890165071291.issue2459@psf.upfronthosting.co.za> Message-ID: <1206225905.2.0.713771594853.issue2459@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Sorry for the double post, the second message contains fixed benchmark numbers. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 00:03:55 2008 From: report at bugs.python.org (Armin Ronacher) Date: Sat, 22 Mar 2008 23:03:55 +0000 Subject: [issue1810] AST compile() patch In-Reply-To: <1200095922.65.0.677669960272.issue1810@psf.upfronthosting.co.za> Message-ID: <1206227035.51.0.484142641394.issue1810@psf.upfronthosting.co.za> Changes by Armin Ronacher : ---------- nosy: +aronacher __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 00:12:27 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 22 Mar 2008 23:12:27 +0000 Subject: [issue2343] Raise a Py3K warning when using a float where an int is expected In-Reply-To: <1205777778.13.0.206701956987.issue2343@psf.upfronthosting.co.za> Message-ID: <1206227547.08.0.669730781825.issue2343@psf.upfronthosting.co.za> Benjamin Peterson added the comment: This is already implemented: >>> [].insert(.5, 0) __main__:1: DeprecationWarning: integer argument expected, got float ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 00:23:10 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 22 Mar 2008 23:23:10 +0000 Subject: [issue2402] get rid of warnings in regrtest with -3 Message-ID: <1206228190.48.0.552961386155.issue2402@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 00:23:27 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 22 Mar 2008 23:23:27 +0000 Subject: [issue2402] get rid of warnings in regrtest with -3 Message-ID: <1206228207.75.0.862844164759.issue2402@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- components: +Tests __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 00:29:22 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 22 Mar 2008 23:29:22 +0000 Subject: [issue1616] compiler warnings In-Reply-To: <1197577517.45.0.829785777717.issue1616@psf.upfronthosting.co.za> Message-ID: <1206228562.27.0.248622659905.issue1616@psf.upfronthosting.co.za> Benjamin Peterson added the comment: While we're at it, see 2388. ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 00:32:55 2008 From: report at bugs.python.org (Armin Ronacher) Date: Sat, 22 Mar 2008 23:32:55 +0000 Subject: [issue2460] Ellipsis not copyable In-Reply-To: <1206228775.23.0.695866830268.issue2460@psf.upfronthosting.co.za> Message-ID: <1206228775.23.0.695866830268.issue2460@psf.upfronthosting.co.za> New submission from Armin Ronacher : Currently python raises an exception if one tries to copy or deepcopy Ellpisis. The former is usually no problem but if an ellipsis ends up on an object and becomes deepcopied this is pretty annoying. The patch provided adds Ellipsis to the copy.py registry with the same treatment None and other immutable types get. ---------- components: Library (Lib) files: ellipsis.diff keywords: patch messages: 64347 nosy: aronacher severity: normal status: open title: Ellipsis not copyable type: behavior versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9821/ellipsis.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 00:34:01 2008 From: report at bugs.python.org (Brett Cannon) Date: Sat, 22 Mar 2008 23:34:01 +0000 Subject: [issue2343] Raise a Py3K warning when using a float where an int is expected In-Reply-To: <1205777778.13.0.206701956987.issue2343@psf.upfronthosting.co.za> Message-ID: <1206228841.1.0.0761077299184.issue2343@psf.upfronthosting.co.za> Brett Cannon added the comment: Is there any other place where this might be an issue? That's the real question; are all reasonable cases covered. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 00:36:36 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 22 Mar 2008 23:36:36 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224705.13.0.0890165071291.issue2459@psf.upfronthosting.co.za> Message-ID: <1206228996.28.0.201099047268.issue2459@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Added file: http://bugs.python.org/file9822/loops2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 00:36:41 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 22 Mar 2008 23:36:41 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224705.13.0.0890165071291.issue2459@psf.upfronthosting.co.za> Message-ID: <1206229001.68.0.447557885266.issue2459@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file9820/loops.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 00:38:45 2008 From: report at bugs.python.org (Andy Harrington) Date: Sat, 22 Mar 2008 23:38:45 +0000 Subject: [issue1038909] pydoc method documentation lookup enhancement Message-ID: <1206229125.88.0.265147840265.issue1038909@psf.upfronthosting.co.za> Andy Harrington added the comment: Several points: Additional note in pydoc output: I thought that 'inherited' docs should be marked, so I chose to add to the note for any function that gets docs displayed from an inherited function: ', docs from inherited ' Alternate verbiage could certainly be used, but I strongly believe that the substitution should be marked and its source indicated. This addition occurs in HTMLDoc.docroutine and TextDoc.docroutine. Elaboration? If a user just calls help() or help(), this patch is certainly appropriate. On the other hand, if the call is help(), and the module includes the definitions of the inherited classes from which documentation is 'inherited', then there is duplication within the output, which the user might or might not desire. To allow a choice would require a change in parameters or a global flag in pydoc. A global flag like allow_doc_redundancy could be set to False to block inherited documentation when the ancestor function is already putting a copy of the documentation in the output. I would be happy to add this change if requested, but I thought it would be presumptuous of me to just add it to the requested patch. Testing I added a test specifically for the inherited docs, test.test_pydoc_inheritance, generating documentaton on test.test_pydoc_sample and comparing results to previously generated results files test/test_pydoc.txt and test/test_pydoc.html. If further changes to pydoc cause outward change to the documentation format, run test_pydoc_inheritance.regenerateData() to replace the result files. Nothing in the patch in 2.6 dependent. Users could choose to upgrade pydoc for 2.5.x Added file: http://bugs.python.org/file9823/pydoc.PATCH _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 23 00:43:49 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 22 Mar 2008 23:43:49 +0000 Subject: [issue2343] Raise a Py3K warning when using a float where an int is expected In-Reply-To: <1205777778.13.0.206701956987.issue2343@psf.upfronthosting.co.za> Message-ID: <1206229429.1.0.561553989149.issue2343@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think so. The warning is implemented in getargs.c, so any conversion from a float to int will result in a warning. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 00:44:32 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 22 Mar 2008 23:44:32 +0000 Subject: [issue2343] Raise a Py3K warning when using a float where an int is expected In-Reply-To: <1205777778.13.0.206701956987.issue2343@psf.upfronthosting.co.za> Message-ID: <1206229472.19.0.599206240284.issue2343@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 02:15:01 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 23 Mar 2008 01:15:01 +0000 Subject: [issue2460] Ellipsis not copyable In-Reply-To: <1206228775.23.0.695866830268.issue2460@psf.upfronthosting.co.za> Message-ID: <1206234901.89.0.365499750939.issue2460@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger type: behavior -> feature request versions: -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 02:24:21 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 23 Mar 2008 01:24:21 +0000 Subject: [issue2013] Long object free list optimization In-Reply-To: <1202180868.04.0.23342807926.issue2013@psf.upfronthosting.co.za> Message-ID: <1206235461.21.0.316781650669.issue2013@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Looking at how much memory was actually used by PyLongObjects the way our code allocates them... we can use this freelist for 2 digit PyLongs on 32-bit systems and for 4 digit PyLongs on 64-bit systems. Doing this speeds things up even more as numbers > 32767 are still quite common. why? sizeof(PyVarObject) == 12, sizeof(digit) == 2. Objects/obmalloc.c allocates on 8, 16 and 32 byte boundaries. Theres no such thing as a 14 byte allocation, its 16 byte aligned. The same applies for 64-bit platforms where the sizeof(PyVarObject) == 24, our allocation size is 32 bytes there. patch attached as -gps02. Added file: http://bugs.python.org/file9824/py3k_longfreelist2-gps02.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 03:04:47 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 23 Mar 2008 02:04:47 +0000 Subject: [issue2013] Long object free list optimization In-Reply-To: <1202180868.04.0.23342807926.issue2013@psf.upfronthosting.co.za> Message-ID: <1206237887.22.0.261512171256.issue2013@psf.upfronthosting.co.za> Gregory P. Smith added the comment: And the benchmarks of gps02... see the attached file. At the end I had it run pybench rather than these microbenchmarks that obviously show the speedup, the -gps02 patch ran 1.3% faster best case a 0.5% faster on average (32-bit; my mac's toolchain can't build enough of py3k 64-bit to run pybench). Things left for someone to do? Determine what a good size for the PyLong free list is. 4096 was a magic number chosen by tiran. Added file: http://bugs.python.org/file9825/issue2013-benchmarks-gps02.txt __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 03:41:56 2008 From: report at bugs.python.org (Brett Cannon) Date: Sun, 23 Mar 2008 02:41:56 +0000 Subject: [issue2343] Raise a Py3K warning when using a float where an int is expected In-Reply-To: <1205777778.13.0.206701956987.issue2343@psf.upfronthosting.co.za> Message-ID: <1206240116.05.0.384927588397.issue2343@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 07:18:43 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 23 Mar 2008 06:18:43 +0000 Subject: [issue1691411] Duplicate "preferences" menu item/Tk Aqua 8.4.14 Message-ID: <1206253123.79.0.463125242559.issue1691411@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 23 10:57:49 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 23 Mar 2008 09:57:49 +0000 Subject: [issue1477] UnicodeDecodeError that cannot be caught in narrow unicode builds In-Reply-To: <1195593459.02.0.388666867716.issue1477@psf.upfronthosting.co.za> Message-ID: <1206266269.6.0.784284594311.issue1477@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Committed r61793. Will backport. ---------- resolution: -> fixed status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 12:16:47 2008 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Sun, 23 Mar 2008 11:16:47 +0000 Subject: [issue2461] test_util.py for distutils In-Reply-To: <1206271007.7.0.519259374853.issue2461@psf.upfronthosting.co.za> Message-ID: <1206271007.7.0.519259374853.issue2461@psf.upfronthosting.co.za> New submission from Tarek Ziad? : this patch adds a test module for util, to improve distutils test coverage. It does not yet test byte_compile, but the other ones are covered. ---------- components: Distutils files: 2008-03-23.distutils.util.patch keywords: patch messages: 64354 nosy: tarek severity: normal status: open title: test_util.py for distutils versions: Python 2.6 Added file: http://bugs.python.org/file9826/2008-03-23.distutils.util.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 14:30:52 2008 From: report at bugs.python.org (djc) Date: Sun, 23 Mar 2008 13:30:52 +0000 Subject: [issue2444] Adding __iter__ to class Values of module optparse In-Reply-To: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za> Message-ID: <1206279052.13.0.554300102388.issue2444@psf.upfronthosting.co.za> djc added the comment: I'd like this. I had one instance where a number of options where dynamically added to the OptionParser based on loadable modules, so that I wanted to dynamically iterate over the Values returned as well. ---------- nosy: +djc __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 14:32:59 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 23 Mar 2008 13:32:59 +0000 Subject: [issue1681432] Add triangular distribution to random Message-ID: <1206279179.92.0.182926237066.issue1681432@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Applied in r61796 ---------- resolution: -> accepted status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 23 15:00:40 2008 From: report at bugs.python.org (ryan) Date: Sun, 23 Mar 2008 14:00:40 +0000 Subject: [issue2462] python.exe slowing my system In-Reply-To: <1206280840.65.0.43552605768.issue2462@psf.upfronthosting.co.za> Message-ID: <1206280840.65.0.43552605768.issue2462@psf.upfronthosting.co.za> New submission from ryan : Hello! First of all, i'm not a programmer. I'm running Windows XP Pro. For the past two/three weeks, every once in a while, my machine runs extremely slow, and the only strange thing i see in the task manager is a python.exe. When i stop that process, my machine runs fine again. It's using 112,000k of memory...i don't know what python is or does, all i have been able to ascertain is that when it runs, it slows down my machine. please make it stop. i'm guessing that i'm running an earlier version of Python, as my computer is older, i'm guessing it's version 2.1.2,2.2, or 2.2.1. I'd really like to trash all python files, yet they must be in my machine for a reason. Thank you, in advance. ---------- messages: 64357 nosy: FireSnake severity: normal status: open title: python.exe slowing my system __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 15:05:26 2008 From: report at bugs.python.org (Guilherme Polo) Date: Sun, 23 Mar 2008 14:05:26 +0000 Subject: [issue2462] python.exe slowing my system In-Reply-To: <1206280840.65.0.43552605768.issue2462@psf.upfronthosting.co.za> Message-ID: <1206281126.42.0.766678354381.issue2462@psf.upfronthosting.co.za> Guilherme Polo added the comment: You have some application installed that uses Python, be sure to check that. If you believe that application is using way too much memory, be sure to report it at the appropriate place. If you have any other questions, python users mail list would be more appropriate. This should be closed as it is not a bug in Python. ---------- nosy: +gpolo __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 15:18:13 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 23 Mar 2008 14:18:13 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224705.13.0.0890165071291.issue2459@psf.upfronthosting.co.za> Message-ID: <1206281893.4.0.676684290504.issue2459@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This new patch includes surgery to the compiler package (especially flowgraph trickery) in order to make it work with the new opcodes. I think my changes are sane but since the package seems basically untested, unmaintained and almost unused, there may be some glitches. However, test_compiler passes. (test_dis will need to be updated for the new opcodes, not a big deal) Added file: http://bugs.python.org/file9827/loops3.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 15:20:32 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 23 Mar 2008 14:20:32 +0000 Subject: [issue2462] python.exe slowing my system In-Reply-To: <1206280840.65.0.43552605768.issue2462@psf.upfronthosting.co.za> Message-ID: <1206282032.85.0.0969423365454.issue2462@psf.upfronthosting.co.za> Georg Brandl added the comment: Agreed. ---------- nosy: +georg.brandl resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 15:33:37 2008 From: report at bugs.python.org (ryan) Date: Sun, 23 Mar 2008 14:33:37 +0000 Subject: [issue2463] python.exe slowing my system In-Reply-To: <1206282816.94.0.500091037786.issue2463@psf.upfronthosting.co.za> Message-ID: <1206282816.94.0.500091037786.issue2463@psf.upfronthosting.co.za> New submission from ryan : Hello! First of all, I'm nor a programmer. Running WinXPpro. Python.exe runs, using 112,000k mem, according to task manager. This problem started about 3 weeks ago, have had machine for 3 years without issues like this. Please help me make this problem go away. How do i figure out which program is using python, do i even need python on my machine? Thank you in advance. ---------- messages: 64361 nosy: FireSnake severity: normal status: open title: python.exe slowing my system __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 15:36:57 2008 From: report at bugs.python.org (Christian Heimes) Date: Sun, 23 Mar 2008 14:36:57 +0000 Subject: [issue2463] python.exe slowing my system In-Reply-To: <1206282816.94.0.500091037786.issue2463@psf.upfronthosting.co.za> Message-ID: <1206283017.17.0.294316889959.issue2463@psf.upfronthosting.co.za> Christian Heimes added the comment: Duplicate of #2462 ---------- nosy: +tiran resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 15:41:10 2008 From: report at bugs.python.org (Koh Wei Jie) Date: Sun, 23 Mar 2008 14:41:10 +0000 Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za> Message-ID: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za> New submission from Koh Wei Jie : Try the following code: import urllib2 gmail = urllib2.urlopen("https://www.gmail.com").read() wikispaces = urllib2.urlopen("http://www.wikispaces.com").read() Getting the html over HTTPS from gmail.com works, but not over HTTP from wikispaces. Here's the traceback: >>> wikispaces = urllib2.urlopen("http://www.wikispaces.com").read() Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/urllib2.py", line 121, in urlopen return _opener.open(url, data) File "/usr/lib/python2.5/urllib2.py", line 380, in open response = meth(req, response) File "/usr/lib/python2.5/urllib2.py", line 491, in http_response 'http', request, response, code, msg, hdrs) File "/usr/lib/python2.5/urllib2.py", line 412, in error result = self._call_chain(*args) File "/usr/lib/python2.5/urllib2.py", line 353, in _call_chain result = func(*args) File "/usr/lib/python2.5/urllib2.py", line 575, in http_error_302 return self.parent.open(new) File "/usr/lib/python2.5/urllib2.py", line 380, in open response = meth(req, response) File "/usr/lib/python2.5/urllib2.py", line 491, in http_response 'http', request, response, code, msg, hdrs) File "/usr/lib/python2.5/urllib2.py", line 412, in error result = self._call_chain(*args) File "/usr/lib/python2.5/urllib2.py", line 353, in _call_chain result = func(*args) File "/usr/lib/python2.5/urllib2.py", line 575, in http_error_302 return self.parent.open(new) File "/usr/lib/python2.5/urllib2.py", line 374, in open response = self._open(req, data) File "/usr/lib/python2.5/urllib2.py", line 392, in _open '_open', req) File "/usr/lib/python2.5/urllib2.py", line 353, in _call_chain result = func(*args) File "/usr/lib/python2.5/urllib2.py", line 1100, in http_open return self.do_open(httplib.HTTPConnection, req) File "/usr/lib/python2.5/urllib2.py", line 1075, in do_open raise URLError(err) urllib2.URLError: Note the two 302 redirects. I tried accessing wikispaces.com with SSL turned off in Firefox 2.0.0.12, which didn't work because SSL was required, perhaps in between the redirects that wikispaces uses. Why doesn't urllib2 handle the "hidden" SSL properly? (Not to be rude, but httplib2 works.) Thanks! WJ ---------- components: Library (Lib) messages: 64363 nosy: weijie90 severity: normal status: open title: urllib2 can't handle http://www.wikispaces.com type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 15:44:14 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 23 Mar 2008 14:44:14 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224705.13.0.0890165071291.issue2459@psf.upfronthosting.co.za> Message-ID: <1206283454.15.0.942993029957.issue2459@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file9827/loops3.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 15:44:39 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 23 Mar 2008 14:44:39 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224705.13.0.0890165071291.issue2459@psf.upfronthosting.co.za> Message-ID: <1206283479.35.0.965016158266.issue2459@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Removed latest patch, it was half-baked. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 15:45:08 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 23 Mar 2008 14:45:08 +0000 Subject: [issue2462] python.exe slowing my system In-Reply-To: <1206280840.65.0.43552605768.issue2462@psf.upfronthosting.co.za> Message-ID: <1206283508.0.0.860487799258.issue2462@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Have you seen the FAQs about this? http://www.python.org/doc/faq/installed/ ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 15:52:21 2008 From: report at bugs.python.org (Robin Stocker) Date: Sun, 23 Mar 2008 14:52:21 +0000 Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6 In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za> Message-ID: <1206283941.15.0.216303434019.issue1745@psf.upfronthosting.co.za> Robin Stocker added the comment: I've updated the patch to apply cleanly again. Added file: http://bugs.python.org/file9828/backport-keyword-only-arguments-full-2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 16:51:04 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 23 Mar 2008 15:51:04 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224705.13.0.0890165071291.issue2459@psf.upfronthosting.co.za> Message-ID: <1206287464.8.0.856311803143.issue2459@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This new patch should be ok. The block ordering algorithm in compiler.pyassem looks entirely clean now, to the extent that the previous "fixup" hacks have been disabled. Attaching loops3.py. Added file: http://bugs.python.org/file9829/loops3.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 17:17:12 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 23 Mar 2008 16:17:12 +0000 Subject: [issue1251748] compiler package: "global a; a=5" Message-ID: <1206289032.27.0.491710169705.issue1251748@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Armin, if you still care about the compiler package, could you (or some other pypy coder) take a look at #2459? As part of the patch, it rewrites the flow graph block ordering algorithm in a cleaner way (IMHO). ---------- nosy: +pitrou _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 23 17:52:48 2008 From: report at bugs.python.org (Atul Varma) Date: Sun, 23 Mar 2008 16:52:48 +0000 Subject: [issue2465] sphinx-quickstart.py still creates makefile even if user tells it not to In-Reply-To: <1206291168.51.0.981395069683.issue2465@psf.upfronthosting.co.za> Message-ID: <1206291168.51.0.981395069683.issue2465@psf.upfronthosting.co.za> New submission from Atul Varma : If the user chooses not to have Sphinx create a Makefile, Sphinx still behaves as though the user wants it to create one. This patch provides a simple fix. ---------- assignee: georg.brandl components: Documentation tools (Sphinx) files: sphinx-quickstart-makefile.patch keywords: patch messages: 64369 nosy: georg.brandl, varmaa severity: normal status: open title: sphinx-quickstart.py still creates makefile even if user tells it not to type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9830/sphinx-quickstart-makefile.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 18:30:29 2008 From: report at bugs.python.org (Ross Burton) Date: Sun, 23 Mar 2008 17:30:29 +0000 Subject: [issue2466] os.path.ismount doesn't work for NTFS mounts In-Reply-To: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za> Message-ID: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za> New submission from Ross Burton : I'm not sure why this is, but ismount doesn't always work for me. It appears to fail on NTFS mounts. $ mount ... /dev/sda1 on /media/windows type ntfs (ro,noexec,nosuid,nodev,user=ross) redbeard.local:/home on /media/home type nfs (rw,user=ross,noatime,rsize=65536,wsize=65536,retry=1,nfsvers=3,posix,intr,addr=192.168.1.67) $ python Python 2.4.5 (#2, Mar 12 2008, 00:15:51) [GCC 4.2.3 (Debian 4.2.3-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> ismount("/media/windows") False >>> ismount("/media/home") True ---------- components: Library (Lib) messages: 64370 nosy: rossburton severity: normal status: open title: os.path.ismount doesn't work for NTFS mounts type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 18:33:58 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 23 Mar 2008 17:33:58 +0000 Subject: [issue2465] sphinx-quickstart.py still creates makefile even if user tells it not to In-Reply-To: <1206291168.51.0.981395069683.issue2465@psf.upfronthosting.co.za> Message-ID: <1206293638.77.0.510724542802.issue2465@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, committed as r61801. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 18:49:34 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Sun, 23 Mar 2008 17:49:34 +0000 Subject: [issue2467] gc.DEBUG_STATS reports invalid "elapsed" times In-Reply-To: <1206294574.77.0.365865271112.issue2467@psf.upfronthosting.co.za> Message-ID: <1206294574.77.0.365865271112.issue2467@psf.upfronthosting.co.za> New submission from Jean-Paul Calderone : If gc.set_debug(gc.DEBUG_STATS) is enabled, collection will report elapsed time as it progresses through collection. However, the reporting code clobbers the value it uses to compute the elapsed time, so the value alternates between an almost correct valid and a completely incorrect value. ---------- components: Interpreter Core files: debug-stats.patch keywords: patch messages: 64372 nosy: exarkun severity: normal status: open title: gc.DEBUG_STATS reports invalid "elapsed" times type: behavior versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9831/debug-stats.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 20:05:34 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 23 Mar 2008 19:05:34 +0000 Subject: [issue2013] Long object free list optimization In-Reply-To: <1202180868.04.0.23342807926.issue2013@psf.upfronthosting.co.za> Message-ID: <1206299134.66.0.0612444192968.issue2013@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The problem with choosing a sensible freelist size is that we don't have any reference workloads. However, I just tested with 10000 and it doesn't seem to slow anything down anyway. It doesn't make our microbenchmarks I thought the patch to compact freelists at each full gc collection had been committed, but it doesn't seem there. Perhaps it will change matters quite a bit. On the one hand, it will allow for bigger freelists with less worries of degrading memory footprint (but still, potential cache pollution). On the other hand, the bigger the freelists, the more expensive it is to deallocate them. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 20:51:20 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 23 Mar 2008 19:51:20 +0000 Subject: [issue2466] os.path.ismount doesn't work for NTFS mounts In-Reply-To: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za> Message-ID: <1206301880.88.0.580895038791.issue2466@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I cannot reproduce that; it works fine for me, with the same Python version, on Linux 2.6.22. Can you please debug through ismount, and report which of the calls fail? The code of ismount reads def ismount(path): """Test whether a path is a mount point""" try: s1 = os.stat(path) s2 = os.stat(join(path, '..')) except os.error: return False # It doesn't exist -- so not a mount point :-) dev1 = s1.st_dev dev2 = s2.st_dev if dev1 != dev2: return True # path/.. on a different device as path ino1 = s1.st_ino ino2 = s2.st_ino if ino1 == ino2: return True # path/.. is the same i-node as path return False ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 21:39:03 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 23 Mar 2008 20:39:03 +0000 Subject: [issue2468] izip fixer generates incorrect import statement In-Reply-To: <1206304742.87.0.65595125742.issue2468@psf.upfronthosting.co.za> Message-ID: <1206304742.87.0.65595125742.issue2468@psf.upfronthosting.co.za> New submission from Martin v. L?wis : Currently (r61811), the code from itertools import izip gets fixed to from itertools import This is incorrect; the import statement should be removed altogether. ---------- assignee: David Wolever components: 2to3 (2.x to 3.0 conversion tool) messages: 64375 nosy: David Wolever, loewis severity: normal status: open title: izip fixer generates incorrect import statement __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 22:25:26 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 23 Mar 2008 21:25:26 +0000 Subject: [issue2444] Adding __iter__ to class Values of module optparse In-Reply-To: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za> Message-ID: <1206307526.52.0.454731630944.issue2444@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This seems to be a reasonable request. ---------- assignee: -> gward nosy: +gward, rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 22:25:54 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 23 Mar 2008 21:25:54 +0000 Subject: [issue2444] Adding __iter__ to class Values of module optparse In-Reply-To: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za> Message-ID: <1206307554.18.0.176567434316.issue2444@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- type: -> feature request __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 22:28:11 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 23 Mar 2008 21:28:11 +0000 Subject: [issue1700821] audioop module - request to add a note Message-ID: <1206307691.52.0.747221554005.issue1700821@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> georg.brandl nosy: +georg.brandl _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 23 22:37:18 2008 From: report at bugs.python.org (Steven Bethard) Date: Sun, 23 Mar 2008 21:37:18 +0000 Subject: [issue2444] Adding __iter__ to class Values of module optparse In-Reply-To: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za> Message-ID: <1206308238.79.0.187066081442.issue2444@psf.upfronthosting.co.za> Steven Bethard added the comment: Why can't you just iterate over ``vars(opts)``? ---------- nosy: +bethard __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 22:47:45 2008 From: report at bugs.python.org (Guilherme Polo) Date: Sun, 23 Mar 2008 21:47:45 +0000 Subject: [issue2444] Adding __iter__ to class Values of module optparse In-Reply-To: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za> Message-ID: <1206308865.56.0.944022474414.issue2444@psf.upfronthosting.co.za> Guilherme Polo added the comment: I consider iterating over opts to be nicer and more pythonic than using vars(opts), since the latter is just a mask over the ugly opts.__dict__ __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 22:53:34 2008 From: report at bugs.python.org (Steven Bethard) Date: Sun, 23 Mar 2008 21:53:34 +0000 Subject: [issue2444] Adding __iter__ to class Values of module optparse In-Reply-To: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za> Message-ID: <1206309214.5.0.0683674657209.issue2444@psf.upfronthosting.co.za> Steven Bethard added the comment: But ``vars()`` is the standard Python mechanism for doing this sort of thing (that is, treating an object like a dictionary). So, while I understand that you find "iterating over opts to be nicer", calling it more Pythonic is probably a misuse of the term. ;-) Anyway, I should point out that optparse is maintained separately from the standard library, and any modifications to it usually need to go through the tracker at http://optik.sourceforge.net/ first. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 23:01:07 2008 From: report at bugs.python.org (Brad Miller) Date: Sun, 23 Mar 2008 22:01:07 +0000 Subject: [issue1513695] new turtle module Message-ID: <1206309667.53.0.445044884268.issue1513695@psf.upfronthosting.co.za> Changes by Brad Miller : ---------- nosy: +bmiller _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 23 23:07:37 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 23 Mar 2008 22:07:37 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224705.13.0.0890165071291.issue2459@psf.upfronthosting.co.za> Message-ID: <1206310057.03.0.874850679115.issue2459@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file9822/loops2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 23:12:48 2008 From: report at bugs.python.org (Guilherme Polo) Date: Sun, 23 Mar 2008 22:12:48 +0000 Subject: [issue2444] Adding __iter__ to class Values of module optparse In-Reply-To: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za> Message-ID: <1206310368.42.0.838156840284.issue2444@psf.upfronthosting.co.za> Guilherme Polo added the comment: There is another reason for considering __iter__ as a more pythonic solution here. If you print opts, it may lead you to believe that it is just a regular dict, while it is not. If you were just able to iterate over it, I think it would be more natural. I know you could check it and then you would know it is not a dict, but I still prefer adding a__iter__ method over using vars here. About optparse being maintained separately.. isn't there someone responsible that possibly checks this bugtracker ? If it is not the case, and if __iter__ is agreed as a good solution, I could send this to its own bugtracker then (if that is the best thing to do). __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 23:17:23 2008 From: report at bugs.python.org (Steven Bethard) Date: Sun, 23 Mar 2008 22:17:23 +0000 Subject: [issue2444] Adding __iter__ to class Values of module optparse In-Reply-To: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za> Message-ID: <1206310643.42.0.58833135958.issue2444@psf.upfronthosting.co.za> Steven Bethard added the comment: My experience in the past has been that the optik/optparse maintainer doesn't often respond to tickets in this tracker, though perhaps that has changed recently. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 23 23:46:09 2008 From: report at bugs.python.org (Ross Burton) Date: Sun, 23 Mar 2008 22:46:09 +0000 Subject: [issue2466] os.path.ismount doesn't work for NTFS mounts In-Reply-To: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za> Message-ID: <1206312369.73.0.6420589167.issue2466@psf.upfronthosting.co.za> Ross Burton added the comment: Aha. The contents of the mount point are only accessible by root: $ stat /media/windows/.. stat: cannot stat `/media/windows/..': Permission denied This falls into the except block, so false is returned. If ismount() used os.path.dirname() instead of appending "..", then this wouldn't happen. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 00:02:42 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 23 Mar 2008 23:02:42 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224705.13.0.0890165071291.issue2459@psf.upfronthosting.co.za> Message-ID: <1206313362.45.0.0209255411774.issue2459@psf.upfronthosting.co.za> Antoine Pitrou added the comment: loops4.patch adds a mechanism to avoid blocking signal catching in empty loops (such as "for x in it: pass" or "while x: pass"). Much of the speedup is still retained. ./python -m timeit "for x in xrange(10000): pass" Before: 1000 loops, best of 3: 737 usec per loop After: 1000 loops, best of 3: 438 usec per loop ./python -m timeit "x=100" "while x: x -= 1" Before: 10000 loops, best of 3: 21.7 usec per loop After: 100000 loops, best of 3: 16.6 usec per loop ./python Tools/pybench/pybench.py -t ForLoops Before: 364ms per round After: 242ms per round Added file: http://bugs.python.org/file9832/loops4.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 00:40:54 2008 From: report at bugs.python.org (Andy Harrington) Date: Sun, 23 Mar 2008 23:40:54 +0000 Subject: [issue1038909] pydoc method documentation lookup enhancement Message-ID: <1206315654.84.0.914450414534.issue1038909@psf.upfronthosting.co.za> Changes by Andy Harrington : Removed file: http://bugs.python.org/file9823/pydoc.PATCH _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 00:50:18 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 23 Mar 2008 23:50:18 +0000 Subject: [issue2469] Fix build error in unicodeobject.c UCS4 In-Reply-To: <1206316218.52.0.325688774899.issue2469@psf.upfronthosting.co.za> Message-ID: <1206316218.52.0.325688774899.issue2469@psf.upfronthosting.co.za> New submission from Benjamin Peterson : For a time, the USC4 Python build was broken because of a typo in unicodeobject.c. Here's the simple fix. ---------- components: Unicode files: unicode_error_fix.patch keywords: patch messages: 64384 nosy: benjamin.peterson severity: normal status: open title: Fix build error in unicodeobject.c UCS4 type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file9833/unicode_error_fix.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 01:25:16 2008 From: report at bugs.python.org (Andy Harrington) Date: Mon, 24 Mar 2008 00:25:16 +0000 Subject: [issue1038909] pydoc method documentation lookup enhancement Message-ID: <1206318316.04.0.0652441166324.issue1038909@psf.upfronthosting.co.za> Andy Harrington added the comment: HM, before writing my patch I tested pydoc to see the issue was still there. I did not look at the 2004 patch from aschmolck since it was so old and was clearly not implemented, and brett just listed this issue as one to deal with in 2008. Now I see pydoc.py.PATCH does address the same issue. Comments on the differences: 1. I allow for the case that an ancestor uses the name but not as a method. That *should* stop the search. 2. The 2004 patch does not use inspect.ismethod, but creates its own test. 3. I stuck with the original pydoc convention that comments could substitute for docs. The 2004 patch does not look for comments in ancestors and only uses comments in the current method if no ancestor has docs. That is a difference in design that could be discussed. I am OK with either. 4. The 2004 patch makes its substitution silently. I prefer explicitly noting that the docs are 'inherited'. 5. There is nothing to add to the test package in the 2004 patch. Before looking at the 2004 patch, I replaced my last patch. I just reread the Python source and documentation conventions and changed names and documentation to match. The only change to my previous comments is that test_pydoc_inheritance.regenerateData was renamed test_pydoc_inheritance.regenerate_data One related comment after thinking about the style guides: Should this pydoc change affect the style guide? Is duplication in the source code recommended for 'inherited' docs? Rather than say absolutely nothing in the overriding method, would a standard comment #inherit docs make sense in the source code? In that case a further change to pydoc is needed to recognize this as a special case, where the 'inherited' docs should be substituted. Alternately the search sequence followed in the 2004 patch could be used, which would find the inherited docs before the comment, whatever the comment. Added file: http://bugs.python.org/file9834/pydoc2.PATCH _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 01:30:59 2008 From: report at bugs.python.org (David Wolever) Date: Mon, 24 Mar 2008 00:30:59 +0000 Subject: [issue2468] izip fixer generates incorrect import statement In-Reply-To: <1206304742.87.0.65595125742.issue2468@psf.upfronthosting.co.za> Message-ID: <17FABDF4-BE42-41F0-8437-20F7E8BEFF1E@cs.toronto.edu> David Wolever added the comment: Ah, nuts -- I had a test case for this, but it was testing with 'from itertools import izip, imap'... But not the single node >_< It has been fixed, and appropriate test has been added, in r61824. On 23-Mar-08, at 4:39 PM, Martin v. L?wis wrote: > > New submission from Martin v. L?wis : > > Currently (r61811), the code > > from itertools import izip > > gets fixed to > > from itertools import > > This is incorrect; the import statement should be removed altogether. > > ---------- > assignee: David Wolever > components: 2to3 (2.x to 3.0 conversion tool) > messages: 64375 > nosy: David Wolever, loewis > severity: normal > status: open > title: izip fixer generates incorrect import statement > > __________________________________ > Tracker > > __________________________________ __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 01:32:45 2008 From: report at bugs.python.org (David Wolever) Date: Mon, 24 Mar 2008 00:32:45 +0000 Subject: [issue2468] izip fixer generates incorrect import statement In-Reply-To: <1206304742.87.0.65595125742.issue2468@psf.upfronthosting.co.za> Message-ID: <1206318765.6.0.0453970698122.issue2468@psf.upfronthosting.co.za> Changes by David Wolever : ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 01:35:10 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 24 Mar 2008 00:35:10 +0000 Subject: [issue1038909] pydoc method documentation lookup enhancement Message-ID: <1206318910.95.0.469090301934.issue1038909@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Andy, I haven't looked at your patch in great detail but your approach sounds good to me. Probably other people will want to study it and pick on details :) I don't think the "#inherit docs" proposal brings any added value over the straightforward approach taken in your patch. The fact that the documentation output states when the docstring is inherited seems clear enough. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 02:21:04 2008 From: report at bugs.python.org (Brad Miller) Date: Mon, 24 Mar 2008 01:21:04 +0000 Subject: [issue1513695] new turtle module Message-ID: <1206321664.79.0.692947037423.issue1513695@psf.upfronthosting.co.za> Brad Miller added the comment: I have xturtle 0.95a0 running under Python 3.0. Mostly the 2to3 program just worked for everything except in three places: 1. in __forward methods I had to change: fromClass.__dict__[method] = d[method] to setattr(fromClass,method,d[method]) 2. in getmethparlist The line: if type(ob)==types.MethodType: does not evaluate to true even when ob is a method. In 3.0 it seems that ob always evaluates to a function. 3. in the _pointlist method I changed cl = self.cv.coords(item) to cl = list(self.cv.coords(item)) There is probably a more elegant way to use the results from the coords call than converting to a list, but I'm confused. The canvas coords function now returns an itertools.imap object. This confuses me because the documentation on python.org does not mention the imap function in the itertools module documentation. So I'm not sure if imap is going away or is just missing documentation. I would like to propose two additional features that I have added to my copy of xturtle and have used extensively in my classes: 1. exitOnClick() --- This function simply hides the call to mainloop() from beginners. It makes life much easier for beginning programers to run xturtle from IDLE. 2. setWorldCoordinates(llx,lly,ulx,uly) This maps a given set of real world coordinates to window coordinates and allows programmers to run the turtle using real world coordinates. Again for beginning programmers this makes it easy for them to use the turtle to graph functions, make bar charts, etc. without needing to scale everything themselves. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 03:03:12 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 24 Mar 2008 02:03:12 +0000 Subject: [issue2456] Make sysmodule.c compatible with Bazaar In-Reply-To: <1206197607.7.0.946463718632.issue2456@psf.upfronthosting.co.za> Message-ID: <1206324192.38.0.181790745109.issue2456@psf.upfronthosting.co.za> Brett Cannon added the comment: Is there a short-term solution we can come up with? Unfortunately stat'ing for the existence of .bzr is not easy since there is no platform-independent solution (as posixmodule.c shows). Should some default values be used? ---------- nosy: +brett.cannon __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 03:59:24 2008 From: report at bugs.python.org (Lauro Moura) Date: Mon, 24 Mar 2008 02:59:24 +0000 Subject: [issue2422] Automatically disable pymalloc when running under valgrind In-Reply-To: <1205925069.41.0.603933745456.issue2422@psf.upfronthosting.co.za> Message-ID: <1206327564.04.0.942971407747.issue2422@psf.upfronthosting.co.za> Lauro Moura added the comment: Here's a patch with James changes to obmalloc and a --with-valgrind option in configure.in. ---------- nosy: +lauromoura Added file: http://bugs.python.org/file9835/disable-pymalloc-on-valgrind-26.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 04:05:20 2008 From: report at bugs.python.org (ryan) Date: Mon, 24 Mar 2008 03:05:20 +0000 Subject: [issue2462] python.exe slowing my system In-Reply-To: <1206283508.0.0.860487799258.issue2462@psf.upfronthosting.co.za> Message-ID: <949499.55211.qm@web33408.mail.mud.yahoo.com> ryan added the comment: Dear Mr Peterson: The FAQ did help somewhat...i figured that it was some 3rd party app, yet i have not downloaded any new programming recently, and it seems that python.exe runs when it wants to, unrelated to a unique program that i use rarely. I did receive a new Java update as well as a new version of spybot, which included teatimer, that is all. thank you for your input, all the FAQs at different websites merely informed me of what python was, not what programs use it. Ryan --------------------------------- Never miss a thing. Make Yahoo your homepage. Added file: http://bugs.python.org/file9836/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080324/6a34a3fb/attachment.txt From report at bugs.python.org Mon Mar 24 05:06:31 2008 From: report at bugs.python.org (Alexander Schmolck) Date: Mon, 24 Mar 2008 04:06:31 +0000 Subject: [issue1038909] pydoc method documentation lookup enhancement Message-ID: <1206331591.89.0.138712313142.issue1038909@psf.upfronthosting.co.za> Alexander Schmolck added the comment: Ah, well nice to see this finally going somewhere, although I'm a bit puzzled as to why my patch was "clearly not implemented" :) Andy, wrt. to your points: 1. Yes, but see below. 2. Are you sure using inspect.ismethod is an improvement? I'm pretty sure I was aware of it and didn't use it for a reason -- from a superficial glance it appears to me that inspect.getmethod is just broken for this purpose. Or do you have a good reason why you'd like to exclude e.g. methods inherited from a builtin? I have no time to check right now, maybe the behavior of ismethod has changed or I remember it wrongly, but in general I think doc-lookup should be oblivious to changes that are transparent at the interface level and whether something is inherited from a builtin or not is should be considered as a mere implementation detail and not at all affect the documentation lookup. 3. I don't feel strongly about this but I'm personally not that keen on using comments as a substitute for docs -- I see no point in conflating these two mechanisms which serve quite different purposes (implementation elucidation vs interface description), especially if the comment is taken from *some other implementation*. 4. Certainly fine by me. 'as _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 05:45:02 2008 From: report at bugs.python.org (James Henstridge) Date: Mon, 24 Mar 2008 04:45:02 +0000 Subject: [issue2422] Automatically disable pymalloc when running under valgrind In-Reply-To: <1205925069.41.0.603933745456.issue2422@psf.upfronthosting.co.za> Message-ID: <1206333902.89.0.228923867636.issue2422@psf.upfronthosting.co.za> James Henstridge added the comment: Here's the updated version of my patch (the obmalloc.c bits applied without conflicts to the newer source tree). The configure changes are a bit different to Lauro's ones, in that they check for the existence of the header if Valgrind support was requested. Added file: http://bugs.python.org/file9837/disable-pymalloc-on-valgrind-py26.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 07:24:35 2008 From: report at bugs.python.org (Neal Norwitz) Date: Mon, 24 Mar 2008 06:24:35 +0000 Subject: [issue2470] Need fixer for dl (removed) -> ctypes module In-Reply-To: <1206339875.66.0.189262293555.issue2470@psf.upfronthosting.co.za> Message-ID: <1206339875.66.0.189262293555.issue2470@psf.upfronthosting.co.za> New submission from Neal Norwitz : r61837 removed the dl module. It needs a 2to3 fixer written to use ctypes. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 64394 nosy: collinwinter, nnorwitz priority: critical severity: normal status: open title: Need fixer for dl (removed) -> ctypes module __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 07:59:37 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 24 Mar 2008 06:59:37 +0000 Subject: [issue2471] imp.get_magic() should return bytes, not bytearray In-Reply-To: <1206341976.98.0.341393013827.issue2471@psf.upfronthosting.co.za> Message-ID: <1206341976.98.0.341393013827.issue2471@psf.upfronthosting.co.za> New submission from Brett Cannon : The magic cookie as returned by imp.get_magic() should be of the bytes type, not bytearray as the magic cookie will not ever change during the execution of the interpreter. ---------- components: Extension Modules messages: 64395 nosy: brett.cannon priority: normal severity: normal status: open title: imp.get_magic() should return bytes, not bytearray type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 09:04:34 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 24 Mar 2008 08:04:34 +0000 Subject: [issue1162363] Heap class for heapq module Message-ID: <1206345874.1.0.941445011989.issue1162363@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Overall, I'm not in favor of the patch or the basic idea. The heapq module is somewhat usable as-is with apps typically inserting tuples linking a priority level and a record. Also, the attached code is not yet mature, nor does it evidence compelling use cases or user demand. This may make a good ASPN recipe but would be premature for inclusion in the standard library. One quick comment on the API, it would be better to have just a key function and to drop the cmp function as Python itself has done throughout the language in Py3.0. Recommend rejecting the feature request, leaving the module as clean as possible. If the code is published separately (perhaps as an ASPN recipe or third-party module), it may yet mature and gather a fan club. ---------- resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 09:13:41 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 24 Mar 2008 08:13:41 +0000 Subject: [issue1904] Add key argument to heapq functions In-Reply-To: <1200999243.33.0.342848472968.issue1904@psf.upfronthosting.co.za> Message-ID: <1206346421.05.0.0301842124744.issue1904@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Rejecting the key-function patch in favor of the current typical approach of heapifying tuples that link a priority level with individual records. I've been a heavy user of the module and one of its principal maintainers. To date, I've seen very little need for key- function argument. Use cases aside, there is another design issue in that the key-function approach doesn't work well with the heap functions on regular lists. Successive calls to heap functions will of necessity call the key- function multiple times for any given element. This contrasts with sort () where the whole purpose of the key function was to encapsulate the decorate-sort-undecorate pattern which was desirable because the key- function called exactly once per element. ---------- resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 09:17:56 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 24 Mar 2008 08:17:56 +0000 Subject: [issue2460] Ellipsis not copyable In-Reply-To: <1206228775.23.0.695866830268.issue2460@psf.upfronthosting.co.za> Message-ID: <1206346676.14.0.524082384979.issue2460@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks for the patch. Applied in r61841. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 09:18:01 2008 From: report at bugs.python.org (Andy Harrington) Date: Mon, 24 Mar 2008 08:18:01 +0000 Subject: [issue1038909] pydoc method documentation lookup enhancement Message-ID: <1206346681.88.0.915131574332.issue1038909@psf.upfronthosting.co.za> Andy Harrington added the comment: Alexander, I have no idea why your patch languished. On the one hand I might have skipped this if I realized that before. On the other hand, I did add something extra, and I might not have had an open mind if I had looked at yours. Plus, maybe I got it moving! :) You made a good enhancement suggestion. From the continuing interchange below, it looks like two minds are better than either one. Comments on your comments on mine: 2. Hm, good point. I do not think pydoc should substitute for PyLint, but it only makes sense to copy the docs from the same type of function in an ancestor class: static, class or method, though you are right it need not matter whether the ancestor is built-in or not, though the assumption is made that you know about built-in docs - you might only note the inheritance. And again, as I did it, finding any ancestor of the wrong type should stop the search. There is one inconsistency with static method docs: If we are given a class, and have a static method in it, we can search the inheritance chain for docs. Neither of us does this at present, though it looks easier to add through my access point in docroutine. On the other hand, if the top-level request is just to document a static function, there is a problem, since you cannot identify the class it comes from, not having an im_class attribute, and hence the documentation may look different from when it was just a part of the documentation for the class. I do not see this as a reason to skip the inheritance chain for a static method when given it's class: better information in -> better information out. 3. I agree people should use doc strings not comments, but if everyone did that, our versions would have the same effect. The only difference is if the coder *does* want to use comments for some reason. Hence the question is: do you want to document what people do or push them to code the way you want? Ping apparently chose the former approach, so I am not suggesting changing it. Thanks, Andy _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 09:20:32 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 24 Mar 2008 08:20:32 +0000 Subject: [issue1462228] custom comparison function for bisect module Message-ID: <1206346832.09.0.127898769017.issue1462228@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thank you for the patch but must close due the rejection of the original RFE. ---------- resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 09:26:42 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 24 Mar 2008 08:26:42 +0000 Subject: [issue1451588] bisect should support a custom comparison function Message-ID: <1206347202.09.0.574423771557.issue1451588@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry, am closing this RFE because its not the best way to use the bisect tools. The cmp function is going away in Py3.0 in favor of key functions. Yet, even those do not play nicely with bisect because the function results are not stored between successive calls to bisect. Accordingly, it is almost always better to arrange the records in a decorated style so that they can be compared directly and not through a cmp or key function. The one misgiving is that is feels odd to be able to sort by a key function but not maintain that order or search that ordering using the bisect module. Yet, there is a simple reason for the difference -- sort () works on the entire sequence at once and can take advantage of the single key function call per element -- in contrast, the bisect functions have finer granularity and the cmp/key functions no longer make sense. ---------- nosy: +rhettinger resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 09:31:05 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 24 Mar 2008 08:31:05 +0000 Subject: [issue1619060] bisect on presorted list Message-ID: <1206347465.07.0.670725593945.issue1619060@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks for the thoughtful reply. Am going to close for the reasons agreed by most of the respondants. See additional explanation in the closing of issue 1451588 . That all-at-once action of sort() allows it to take advantage of a single key-function call per element; in contrast, successive calls to bisect functions are more finely grained and the key-function doesn't make sense anymore. ---------- resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 09:40:38 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 24 Mar 2008 08:40:38 +0000 Subject: [issue2354] cmp argument to list.sort()/sorted() should raise a Py3K warning In-Reply-To: <1205782211.6.0.934088370296.issue2354@psf.upfronthosting.co.za> Message-ID: <1206348038.32.0.15248408805.issue2354@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 09:46:01 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 24 Mar 2008 08:46:01 +0000 Subject: [issue2126] BaseHTTPServer.py fails long POST from IE In-Reply-To: <1203167938.11.0.556138107236.issue2126@psf.upfronthosting.co.za> Message-ID: <1206348361.42.0.0103669801131.issue2126@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Unassigning. I don't have more thoughts on this one. ---------- assignee: rhettinger -> __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 09:53:20 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 24 Mar 2008 08:53:20 +0000 Subject: [issue2172] Add doc-string to UserDict and DictMixin In-Reply-To: <1203829772.14.0.952967629651.issue2172@psf.upfronthosting.co.za> Message-ID: <1206348800.91.0.18759646695.issue2172@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'm not sure the class docstring approach is suitable for a mixin. It seems fine to me that pydoc strips the commentary on the mixin as a standalone class; instead it appropriately focuses on the client class that uses the mixin as part of its API. FWIW, all of this code goes away in Py3.0. ---------- resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 10:02:39 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 24 Mar 2008 09:02:39 +0000 Subject: [issue1569291] Speed-up in array_repeat() Message-ID: <1206349359.59.0.612725896636.issue1569291@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This one is easy if someone wants to take a crack at it. ---------- keywords: +easy -patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 10:04:08 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 24 Mar 2008 09:04:08 +0000 Subject: [issue762920] API Functions for PyArray Message-ID: <1206349448.86.0.079105685596.issue762920@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Raising priority as a reminder to myself or anyone who wants to apply, test, and document. ---------- priority: normal -> high ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 24 10:12:49 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 24 Mar 2008 09:12:49 +0000 Subject: [issue2470] Need fixer for dl (removed) -> ctypes module In-Reply-To: <1206339875.66.0.189262293555.issue2470@psf.upfronthosting.co.za> Message-ID: <1206349969.17.0.022928803548.issue2470@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Is it possible to write one? I'm skeptical. ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 10:34:52 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 24 Mar 2008 09:34:52 +0000 Subject: [issue1700821] audioop module - request to add a note Message-ID: <1206351292.63.0.275621621871.issue1700821@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r61842. ---------- resolution: accepted -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 11:22:39 2008 From: report at bugs.python.org (Armin Rigo) Date: Mon, 24 Mar 2008 10:22:39 +0000 Subject: [issue1251748] compiler package: "global a; a=5" Message-ID: <1206354159.19.0.651337131376.issue1251748@psf.upfronthosting.co.za> Armin Rigo added the comment: Sorry, I don't think many PyPy coders care about microoptimizations in the bytecode. To be honest we've stopped worrying about the stdlib compiler package because no one seemed to care. I'm closing the present patch as incomplete and outdated; if someone is interested in reviving the stdlib compiler package, my offer to extract from PyPy an up-to-date diff for the compiler package still stands. ---------- resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 13:09:41 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 24 Mar 2008 12:09:41 +0000 Subject: [issue2472] Fixed block ordering code in compiler.pyassem In-Reply-To: <1206360580.92.0.370388118897.issue2472@psf.upfronthosting.co.za> Message-ID: <1206360580.92.0.370388118897.issue2472@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This is a rewrite of the block ordering code in the compiler package (specifically, the flowgraph part). The previous code was littered with self-admitted "hacks", "fixups" and "XXX" :-) They are all removed and replaced with a clean ``order_blocks`` function which does the right thing from the start. The patch also replaces a wrong startBlock() with a nextBlock() in compiler.pycodegen (startBlock can only be used when the previous block does an unconditional transfer to another one, otherwise the two adjacent blocks may not be emitted in order). I've run test_compiler a couple of times, and tested execution of several functions. They all run fine. Unless someone has specific reasons to reject the patch, I'd recommend applying it even if not many people use the compiler package :) I needed the fixes for my work on #2459. ---------- components: Library (Lib) files: fixcompiler.patch keywords: patch messages: 64410 nosy: pitrou severity: normal status: open title: Fixed block ordering code in compiler.pyassem type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9838/fixcompiler.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 13:11:21 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 24 Mar 2008 12:11:21 +0000 Subject: [issue2472] Fixed block ordering code in compiler.pyassem In-Reply-To: <1206360580.92.0.370388118897.issue2472@psf.upfronthosting.co.za> Message-ID: <1206360681.53.0.678496062185.issue2472@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file9838/fixcompiler.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 13:11:31 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 24 Mar 2008 12:11:31 +0000 Subject: [issue2472] Fixed block ordering code in compiler.pyassem In-Reply-To: <1206360580.92.0.370388118897.issue2472@psf.upfronthosting.co.za> Message-ID: <1206360691.27.0.604780719011.issue2472@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Added file: http://bugs.python.org/file9839/fixcompiler.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 13:15:54 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 24 Mar 2008 12:15:54 +0000 Subject: [issue1251748] compiler package: "global a; a=5" Message-ID: <1206360954.2.0.409573089228.issue1251748@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Armin, this is not about micro-optimizations per se, but about fixing some parts of the compiler package. To make it easier, I've created a separate entry for the fixing part in #2472 :) This was the first time I was using the compiler package and I think it can be useful in order to experiment with bytecode ideas (of course you probably prefer to do that with PyPy). That's why I tried to fix what was failing for me. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 13:24:32 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 24 Mar 2008 12:24:32 +0000 Subject: [issue2472] Fixed block ordering code in compiler.pyassem In-Reply-To: <1206360580.92.0.370388118897.issue2472@psf.upfronthosting.co.za> Message-ID: <1206361472.78.0.365705215819.issue2472@psf.upfronthosting.co.za> Antoine Pitrou added the comment: By enabling TEST_ALL I've just run ``test_compiler.CompilerTest.testCompileLibrary`` against the whole stdlib, and there were no errors. It's a good sign :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 14:40:47 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 24 Mar 2008 13:40:47 +0000 Subject: [issue2240] setitimer, getitimer wrapper In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za> Message-ID: <1206366047.01.0.461440238515.issue2240@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch. Committed as r61847 and r61848 ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 14:56:01 2008 From: report at bugs.python.org (Lorenz Quack) Date: Mon, 24 Mar 2008 13:56:01 +0000 Subject: [issue2250] rlcompleter raises Exception on bad input In-Reply-To: <1204886997.65.0.75088007868.issue2250@psf.upfronthosting.co.za> Message-ID: <1206366961.03.0.863157460553.issue2250@psf.upfronthosting.co.za> Lorenz Quack added the comment: I have no idea what or who NAS is but comments are always welcome :) concerning the documentation: I?ve never done it before but there is a first time for everything, right? I?m currently on vacation so I won?t look into it for at least another 2 weeks. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 14:56:06 2008 From: report at bugs.python.org (Will Maier) Date: Mon, 24 Mar 2008 13:56:06 +0000 Subject: [issue2473] logging.LogRecord should know how to handle dict-like args In-Reply-To: <1206366966.49.0.127979087555.issue2473@psf.upfronthosting.co.za> Message-ID: <1206366966.49.0.127979087555.issue2473@psf.upfronthosting.co.za> New submission from Will Maier : In (at least) Python 2.5.2, logging.logRecord provides a very useful facility to interpolate formatted strings. This feature expands an *args sequence; if that sequence has only one element and that element is a dictionary, LogRecord uses the dictionary to interpolate keyword formatted strings. This is incredibly useful, but the LogRecord __init__() method includes a rather arbitrary type-specific check that prevents users from passing dict-like objects to the log methods: logging.__init__.py:204..238 class LogRecord: [...] def __init__(self, name, level, pathname, lineno, msg, args, exc_info, func=None): [...] if args and (len(args) == 1) and args[0] and (type(args[0]) == types.DictType): args = args[0] This restriction prevents the user from passing eg a subclass of UserDict.DictMixin. Now, __init__() clearly does need to do _some_ checking of args, but it would be nice if that checking accepted dict-like objects. I haven't come up with a good way to do this myself yet, but I figured I'd submit the request now. Thanks! ---------- components: Library (Lib) messages: 64415 nosy: wcmaier severity: normal status: open title: logging.LogRecord should know how to handle dict-like args type: feature request versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 15:58:56 2008 From: report at bugs.python.org (Michael Becker) Date: Mon, 24 Mar 2008 14:58:56 +0000 Subject: [issue1202] zlib.crc32() and adler32() return value In-Reply-To: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za> Message-ID: <1206370736.92.0.367296385497.issue1202@psf.upfronthosting.co.za> Michael Becker added the comment: In case it isn't obvious the work around for pre 3.0 to get the right sum is something like: x=zlib.adler32(str) if x < 0: x=(long(x) + 4294967296L) # 2^32, long may or may not be needed here ---------- nosy: +mbecker __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 17:08:34 2008 From: report at bugs.python.org (Collin Winter) Date: Mon, 24 Mar 2008 16:08:34 +0000 Subject: [issue2470] Need fixer for dl (removed) -> ctypes module In-Reply-To: <1206339875.66.0.189262293555.issue2470@psf.upfronthosting.co.za> Message-ID: <1206374914.52.0.981786026602.issue2470@psf.upfronthosting.co.za> Collin Winter added the comment: Can you list the mapping you'd like to see? I've never used dl or ctypes, so I'm not immediately sure how to port from one to the other. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 17:37:17 2008 From: report at bugs.python.org (L. Peter Deutsch) Date: Mon, 24 Mar 2008 16:37:17 +0000 Subject: [issue1733184] slice type is unhashable Message-ID: <1206376637.12.0.423572171908.issue1733184@psf.upfronthosting.co.za> L. Peter Deutsch added the comment: Having now read messages 63380 and 63384, I agree with them: I would have withdrawn my proposal if it hadn't gotten rejected first. I do have a use case, but the workaround is pretty easy. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 17:41:38 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 24 Mar 2008 16:41:38 +0000 Subject: [issue2470] Need fixer for dl (removed) -> ctypes module In-Reply-To: <1206339875.66.0.189262293555.issue2470@psf.upfronthosting.co.za> Message-ID: <1206376898.67.0.57487519334.issue2470@psf.upfronthosting.co.za> Martin v. L?wis added the comment: In the simplest case, convert import dl libc = dl.open("libc.so.6") iconv = libc.call("iconv_open", "ISO-8859-1", "ISO-8859-2") print(iconv) to import ctypes libc = ctypes.CDLL("libc.so.6") iconv = libc.iconv_open("ISO-8859-1", "ISO-8859-2") print(iconv) Notice that .call has up to 11 arguments, the first one being the function name. Thomas, is it the case that all calls to dl.call can be converted to a ctypes call without parameter conversion? dl supports these parameter types: - byte string, passed as char* - integers, passed as int - None, passed as NULL ---------- nosy: +theller __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 17:57:03 2008 From: report at bugs.python.org (Tom Culliton) Date: Mon, 24 Mar 2008 16:57:03 +0000 Subject: [issue1731717] race condition in subprocess module In-Reply-To: <1206031211.3.0.660181022947.issue1731717@psf.upfronthosting.co.za> Message-ID: <47E7DCEE.10705@oracle.com> Tom Culliton added the comment: I'm not sure what the POSIX standards say on this (and MS-Windows may go it's own contrary way), but for most real systems the PID is a running count (generally 32 bit or larger today) which would have to cycle all the way around to repeat. It's actually done this way on purpose to provide the longest possible time between IDs getting reused. I suspect that having it cycle and reuse an ID isn't an issue in practice, and keeping a list of results leaves you with the problem of figuring out which PID 55367 they're talking about... Not to mention that if you're leaving child process results unchecked for long enough for the PID counter to cycle, there are other problems with the application. ;-) Gregory P. Smith wrote: > Gregory P. Smith added the comment: > > """Basically it's OK to collect > all the child exit codes if you record the results and return them when > requested. This would mean that waitpid and the like would have to check > a cached list of PIDs and exit statuses before actually waiting.""" > > note that this would still have problems. PIDs are recycled by the OS > so as soon as you've waited on one and the process dies, the OS is free > to launch a new process using it. If the new process happens to be > another one of ours launched by subprocess that would be a problem. > Make the cached map of pids -> exit codes be a map of pids -> [list of > exit codes] instead? > > _____________________________________ > Tracker > > _____________________________________ > _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 18:03:38 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Mon, 24 Mar 2008 17:03:38 +0000 Subject: [issue1731717] race condition in subprocess module Message-ID: <1206378218.39.0.915272883232.issue1731717@psf.upfronthosting.co.za> Jean-Paul Calderone added the comment: Which system uses a 32 bit PID? Not Linux, or FreeBSD, or OS X - they all use 16 bit PIDs. ---------- nosy: +exarkun _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 17:55:20 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 24 Mar 2008 16:55:20 +0000 Subject: [issue1202] zlib.crc32() and adler32() return value In-Reply-To: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za> Message-ID: <1206377720.04.0.0511284251692.issue1202@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The workaround I prefer to use is: x = zlib.adler32(mystr) & 0xffffffffL __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 18:19:16 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 24 Mar 2008 17:19:16 +0000 Subject: [issue2172] Add doc-string to UserDict and DictMixin In-Reply-To: <1206348800.91.0.18759646695.issue2172@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Mon, Mar 24, 2008 at 4:53 AM, Raymond Hettinger wrote: > I'm not sure the class docstring approach is suitable for a mixin. It > seems fine to me that pydoc strips the commentary on the mixin as a > standalone class; My main point was not that some commentary was stripped by pydoc, but that the commentary that is not stripped is misleading: The beginning of pydoc UserDict.DictMixin is rendered as follows: UserDict.DictMixin = class DictMixin | Methods defined here: | | __cmp__(self, other) | | __contains__(self, key) | | __iter__(self) | # second level definitions support higher levels | | __len__(self) .. What does "second level definitions support higher levels" comment below __iter__ means? Does it apply to all methods above or all methods below but above the "third level ..." comment or just to __iter__? All of these plausible interpretations are wrong. Furthemore, pydoc UserDict is rendered as follows: NAME UserDict - A more or less complete user-defined wrapper around dictionary objects. FILE /bnv/home/abelopolsky/Work/python-svn/trunk/Lib/UserDict.py CLASSES DictMixin UserDict IterableUserDict class DictMixin ... Which is not helpful at all in understanding of what DictMixin is for. > instead it appropriately focuses on the client class > that uses the mixin as part of its API. I assume you refer to UserDict as the "client class". In what sense does it use "mixin as part of its API"? In 2.x, UserDict does not derive from DictMixin. To the contrary, UserDict and DictMixin present quite different APIs to the users of derived classes. For example, overriding __getitem__ does not affect has_key, __contains__ or iter* methods of the class deriving from UserDict, which is different from the way DictMixin descendants work. .. that's why I selected version 2.6 when I submitted this issue. :-) However, AFAICT, not all this code goes away, just UserDict is moved to collections and DictMixin functionality is replaced with ABCs. This is a welcome change because with abstract methods the classes become self-documenting, but I have to note that UserDict will behave differently in 3.0: the following code print 1 in 2.x and 42 in 3.0: class X(UserDict): def __getitem__(self, _): return 42 print(X(a=1).pop('a')) This change should probably be reflected in the docs somewhere. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 18:24:31 2008 From: report at bugs.python.org (Tom Culliton) Date: Mon, 24 Mar 2008 17:24:31 +0000 Subject: [issue1731717] race condition in subprocess module In-Reply-To: <1206378218.39.0.915272883232.issue1731717@psf.upfronthosting.co.za> Message-ID: <47E7E3C2.9070904@oracle.com> Tom Culliton added the comment: AIX, HP-UX, Solaris, 64 bit Linux, ... Even in the Linux x86 header files there's a mix of int and short. The last time I had to do the math on how long it would take the PID to cycle was probably on an AIX box and it was a very long time. Jean-Paul Calderone wrote: > Jean-Paul Calderone added the comment: > > Which system uses a 32 bit PID? Not Linux, or FreeBSD, or OS X - they > all use 16 bit PIDs. > > ---------- > nosy: +exarkun > > _____________________________________ > Tracker > > _____________________________________ > _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 18:29:22 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 24 Mar 2008 17:29:22 +0000 Subject: [issue1733184] slice type is unhashable Message-ID: <1206379762.22.0.0476323865389.issue1733184@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I hate to flip-flop like this, but please consider my new arguments at issue2268. In short, slices being unhashable prevents storing them in the code object's const dictionary and thus prevents optimizing code involving const slices. Unless I hear strong opposition from the bug tracker forum, I plan to present some ideas on python-dev on how to make slices hashable while not enabling d[:]. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 18:35:21 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Mon, 24 Mar 2008 17:35:21 +0000 Subject: [issue1731717] race condition in subprocess module Message-ID: <1206380121.61.0.989628347765.issue1731717@psf.upfronthosting.co.za> Jean-Paul Calderone added the comment: PIDs cycle quite frequently. You must be thinking of something else. Even 64 bit Linux has a maximum PID of 2 ** 15 - 1. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 19:27:14 2008 From: report at bugs.python.org (Ryan Sturmer) Date: Mon, 24 Mar 2008 18:27:14 +0000 Subject: [issue2474] fset not working In-Reply-To: <1206383234.11.0.783869540468.issue2474@psf.upfronthosting.co.za> Message-ID: <1206383234.11.0.783869540468.issue2474@psf.upfronthosting.co.za> New submission from Ryan Sturmer : Using the attached module, There's an asymmetry between fget and fset in my properties. fget works fine, but fset isn't getting called. I'm fairly sure I'm creating the property correctly. Try the following code: a = EWAssayIntParam('myparam', 4) a.value a.value = 10 a.value I've seen this same issue flare up and die out several times in the tracker, is this a commonly made programming mistake rather than a bug? ---------- components: None files: params.py messages: 64427 nosy: ryansturmer severity: normal status: open title: fset not working type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9840/params.py __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 19:36:37 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 24 Mar 2008 18:36:37 +0000 Subject: [issue1731717] race condition in subprocess module Message-ID: <1206383797.0.0.904752074188.issue1731717@psf.upfronthosting.co.za> Gregory P. Smith added the comment: fwiw, I see pids cycle in a reasonable amount of time on modern production linux systems today. its a fact of life, we should deal with it. :) _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 19:42:52 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 24 Mar 2008 18:42:52 +0000 Subject: [issue1569291] Speed-up in array_repeat() Message-ID: <1206384172.37.0.585512229666.issue1569291@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Looking at stringobject.c:1034: i = 0; if (i < size) { Py_MEMCPY(op->ob_sval, a->ob_sval, Py_SIZE(a)); i = Py_SIZE(a); } while (i < size) { j = (i <= size-i) ? i : size-i; Py_MEMCPY(op->ob_sval+i, op->ob_sval, j); i += j; } return (PyObject *) op; Do I miss something or the first condition "if (i < size)" is a fancy way to check for size > 0? Wouldn't it be clearer to write if (size == 0) return (PyObject *) op; Py_MEMCPY(op->ob_sval, a->ob_sval, Py_SIZE(a)); i = Py_SIZE(a); .. ---------- nosy: +belopolsky _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 19:58:25 2008 From: report at bugs.python.org (Paul Pogonyshev) Date: Mon, 24 Mar 2008 18:58:25 +0000 Subject: [issue2474] fset not working In-Reply-To: <1206383234.11.0.783869540468.issue2474@psf.upfronthosting.co.za> Message-ID: <1206385105.03.0.386212861815.issue2474@psf.upfronthosting.co.za> Paul Pogonyshev added the comment: This is caused by EWAssayParam being an old-style class. Dunno if it is a bug in Python or not. ---------- nosy: +_doublep __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 20:04:49 2008 From: report at bugs.python.org (Georg Brandl) Date: Mon, 24 Mar 2008 19:04:49 +0000 Subject: [issue2474] fset not working In-Reply-To: <1206383234.11.0.783869540468.issue2474@psf.upfronthosting.co.za> Message-ID: <1206385489.66.0.51750611577.issue2474@psf.upfronthosting.co.za> Georg Brandl added the comment: It's not a bug in Python. Properties, being descriptors, only work fully with new-style classes. ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 20:18:38 2008 From: report at bugs.python.org (Ross) Date: Mon, 24 Mar 2008 19:18:38 +0000 Subject: [issue2271] msi installs to the incorrect location (C drive) In-Reply-To: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za> Message-ID: <1206386318.28.0.986348048123.issue2271@psf.upfronthosting.co.za> Ross added the comment: Checking Progress. This is a big of a show-stopper as it prevents me from using a number of python dependent packages. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 20:33:40 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 24 Mar 2008 19:33:40 +0000 Subject: [issue1569291] Speed-up in array_repeat() Message-ID: <1206387220.22.0.821285592311.issue1569291@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Attached patch (issue1569291.diff) reimplements the optimization by following Objects/stringobject.c logic as Raymond suggested. I see two remaining issues which in my view should be addressed separately: 1. There is no check for overflow after the multiplication computing the size of the resulting array. Note that while newarrayobject checks that size*itemsize does not overflow internally, there is no such check for Py_SIZE(a) * n. A decision needs to be made whether Overflow or NoMemory error should be raised because currently string_repeat and newarrayobject treat overflow differently. 2. See msg64429 above. I think both string and (patched) array codes can be simplified. ---------- keywords: +patch type: -> performance Added file: http://bugs.python.org/file9841/issue1569291.diff _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 20:34:18 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 24 Mar 2008 19:34:18 +0000 Subject: [issue2271] msi installs to the incorrect location (C drive) In-Reply-To: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za> Message-ID: <1206387258.71.0.963903871656.issue2271@psf.upfronthosting.co.za> Martin v. L?wis added the comment: No progress so far; may not proceed at all during April (IOW, I haven't even looked at the log file yet). Contributions are welcome. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 20:35:07 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 24 Mar 2008 19:35:07 +0000 Subject: [issue1569291] Speed-up in array_repeat() Message-ID: <1206387307.16.0.264514054232.issue1569291@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I forgot to mention that I added a unit test to cover the special case of repeating a single-byte array. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 20:40:39 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 24 Mar 2008 19:40:39 +0000 Subject: [issue2271] msi installs to the incorrect location (C drive) In-Reply-To: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za> Message-ID: <1206387639.67.0.842289098666.issue2271@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As a further follow-up, I have now looked at the log file, and the problematic lines are MSI (s) (DC:40) [10:44:39:425]: Ignoring disallowed property TARGETDIR MSI (s) (DC:40) [10:44:39:425]: Ignoring disallowed property DLLDIR Try setting SecureCustomProperties (through orca.exe) and report whether that helps. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 20:40:57 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 24 Mar 2008 19:40:57 +0000 Subject: [issue1736190] asyncore/asynchat patches Message-ID: <1206387657.58.0.161654123771.issue1736190@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Are there news about this issue? ---------- nosy: +gvanrossum _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 21:16:03 2008 From: report at bugs.python.org (Ross) Date: Mon, 24 Mar 2008 20:16:03 +0000 Subject: [issue2271] msi installs to the incorrect location (C drive) In-Reply-To: <1205192031.56.0.450495581231.issue2271@psf.upfronthosting.co.za> Message-ID: <1206389763.23.0.121081784109.issue2271@psf.upfronthosting.co.za> Ross added the comment: using Orca, I modified the .msi file and python now appears to be working. I made the following change: Property -> SecureCustomProperty Changed value from REMOVEOLDSNAPSHOT;REMOVEOLDVERSION to REMOVEOLDSNAPSHOT;REMOVEOLDVERSION;TARGETDIR;DLLDIR Running the modified .msi file resulted in Python being installed in C:\Python25 (the correct location). Currently, the installation appears to work properly. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 21:59:09 2008 From: report at bugs.python.org (Josh Cogliati) Date: Mon, 24 Mar 2008 20:59:09 +0000 Subject: [issue2475] Popen.poll always returns None In-Reply-To: <1206392349.51.0.854683862843.issue2475@psf.upfronthosting.co.za> Message-ID: <1206392349.51.0.854683862843.issue2475@psf.upfronthosting.co.za> New submission from Josh Cogliati : I was trying to use subprocess to run multiple processes, and then wait until one was finished. I was using poll() to do this and created the following test case: #BEGIN import subprocess,os procs = [subprocess.Popen(["sleep",str(x)]) for x in range(1,11)] while len(procs) > 0: os.wait() print [(p.pid,p.poll()) for p in procs] procs = [p for p in procs if p.poll() == None] #END I would have expected that as this program was run, it would remove the processes that finished from the procs list, but instead, they stay in it and I got the following output: #Output [(7426, None), (7427, None), (7428, None), (7429, None), (7430, None), (7431, None), (7432, None), (7433, None), (7434, None), (7435, None)] #above line repeats 8 more times [(7426, None), (7427, None), (7428, None), (7429, None), (7430, None), (7431, None), (7432, None), (7433, None), (7434, None), (7435, None)] Traceback (most recent call last): File "./test_poll.py", line 9, in os.wait() OSError: [Errno 10] No child processes #End output Basically, even for finished processes, poll returns None. Version of python used: Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Relevant documentation in Library reference manual 17.1.2 poll( ) ... Returns returncode attribute. ... A None value indicates that the process hasn't terminated yet. ---------- messages: 64439 nosy: jjcogliati severity: normal status: open title: Popen.poll always returns None type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 22:06:00 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 24 Mar 2008 21:06:00 +0000 Subject: [issue2469] Fix build error in unicodeobject.c UCS4 In-Reply-To: <1206316218.52.0.325688774899.issue2469@psf.upfronthosting.co.za> Message-ID: <1206392760.84.0.700142986986.issue2469@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Oops, I made this error while correcting #2469. Thanks for catching it! committed as r61853. There is no buildbot configured with UCS4... ---------- nosy: +amaury.forgeotdarc resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 22:29:25 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 24 Mar 2008 21:29:25 +0000 Subject: [issue1477] UnicodeDecodeError that cannot be caught in narrow unicode builds In-Reply-To: <1195593459.02.0.388666867716.issue1477@psf.upfronthosting.co.za> Message-ID: <1206394165.01.0.20693080168.issue1477@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: backported to 2.5 branch as r61854 ---------- status: pending -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 22:35:19 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 24 Mar 2008 21:35:19 +0000 Subject: [issue2471] imp.get_magic() should return bytes, not bytearray In-Reply-To: <1206341976.98.0.341393013827.issue2471@psf.upfronthosting.co.za> Message-ID: <1206394519.36.0.916459105223.issue2471@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Attaching patch... ---------- keywords: +patch nosy: +benjamin.peterson Added file: http://bugs.python.org/file9842/get_magic_bytes.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 23:17:19 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 24 Mar 2008 22:17:19 +0000 Subject: [issue1054434] automatic XMLRPC boxcarring via multicall for xmlrpclib Message-ID: <1206397039.09.0.00844220714738.issue1054434@psf.upfronthosting.co.za> Ralf Schmitt added the comment: this issue is about the threaded one. I think it should be rejected. It does not work: ~/ python2.5 xmlrpclib_multicall.py ralf at rat64 failed 1 Traceback (most recent call last): File "xmlrpclib_multicall.py", line 12, in from log.StdLogger import logger ImportError: No module named log.StdLogger and the code uses lot's of unused imports. ---------- nosy: +schmir _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 24 23:21:06 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Mon, 24 Mar 2008 22:21:06 +0000 Subject: [issue730938] Python bsddb docs need update Message-ID: <1206397266.89.0.376105778252.issue730938@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Done in the pybssdb module (the external one, not the included in python distribution). Online docs available at http://www.argo.es/~jcea/programacion/pybsddb_doc/ The source "rst" files should be directly usable in the stock 2.6 documentation. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 24 23:33:05 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Mon, 24 Mar 2008 22:33:05 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1206397985.46.0.860142967204.issue2159@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 23:42:00 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 24 Mar 2008 22:42:00 +0000 Subject: [issue2413] os.strerror does not check for out of range argument In-Reply-To: <1205889895.08.0.168690164912.issue2413@psf.upfronthosting.co.za> Message-ID: <1206398520.6.0.643878367145.issue2413@psf.upfronthosting.co.za> Ralf Schmitt added the comment: The current behaviour (without your patch) seems ok to me. I just wanted to point out that the patch in its current form could break on some platforms. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 23:45:08 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 24 Mar 2008 22:45:08 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1206398708.37.0.210366228727.issue2159@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- type: resource usage -> performance __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 23:46:50 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Mon, 24 Mar 2008 22:46:50 +0000 Subject: [issue2159] dbmmodule inquiry function is performance prohibitive In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za> Message-ID: <1206398810.02.0.209688033348.issue2159@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I think that "-1" is a sanity check. If the count is updated in the database, but it is not transactional (or there are bugs, or the DB is updated by a not up-to-date library, and so on), the cached counter and the real data can diverge. Anybody using "Berkeley DB" related databases knows that "length" is costly. By good reasons, actually :-). Checking for empty databases should be fast, nevertheless (just iterate over the first item in the database). We could simply define a "__nonzero__()" method for that. That would solve the "if" issue. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 23:48:04 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 24 Mar 2008 22:48:04 +0000 Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za> Message-ID: <1206398884.18.0.245318788768.issue2375@psf.upfronthosting.co.za> Ralf Schmitt added the comment: I once even had the need for a PYTHON24PATH or PYTHON25PATH. (And I think this would be the right approach, i.e. even using the minor version number). However, now I am a happy user of virtualenv, and I do not even have to set PYTHONPATH anymore... ---------- nosy: +schmir __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 23:49:43 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 24 Mar 2008 22:49:43 +0000 Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za> Message-ID: <1206398983.78.0.0143213719139.issue2375@psf.upfronthosting.co.za> Ralf Schmitt added the comment: c modules cannot be used when the minor version number changes. If I remember correctly c modules where the problem for me, when I ran python 2.4 and 2.5 in parallel. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 24 23:51:49 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 24 Mar 2008 22:51:49 +0000 Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za> Message-ID: <1206399109.68.0.522752227861.issue2375@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- type: -> feature request __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 00:29:59 2008 From: report at bugs.python.org (Brodie Rao) Date: Mon, 24 Mar 2008 23:29:59 +0000 Subject: [issue2476] optparse docs should mention %default being new in 2.4 In-Reply-To: <1206401399.57.0.922863750504.issue2476@psf.upfronthosting.co.za> Message-ID: <1206401399.57.0.922863750504.issue2476@psf.upfronthosting.co.za> New submission from Brodie Rao : The %default option help string feature doesn't exist in Python 2.3, but the documentation for Python 2.4 and 2.5 don't mention that it was added in 2.4. It should mention this so people developing for 2.3 and 2.4/2.5 can be aware of this. http://docs.python.org/lib/optparse-generating-help.html is the page describing the %default feature. I would imagine the bullet point about the feature being prefixed with "New in 2.4: ..." ---------- assignee: georg.brandl components: Documentation messages: 64450 nosy: brodierao, georg.brandl severity: normal status: open title: optparse docs should mention %default being new in 2.4 type: feature request versions: Python 2.4, Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 01:14:09 2008 From: report at bugs.python.org (Eric Ries) Date: Tue, 25 Mar 2008 00:14:09 +0000 Subject: [issue1054434] automatic XMLRPC boxcarring via multicall for xmlrpclib Message-ID: <1206404049.73.0.329559307284.issue1054434@psf.upfronthosting.co.za> Eric Ries added the comment: This code is more than three years old, so the attached version has gone stale. Still, here at IMVU we have continued to use the xmlrpc boxcarring, and could probably provide an updated diff if desired. Let us know if this is a feature of interest. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Mar 25 03:50:44 2008 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 25 Mar 2008 02:50:44 +0000 Subject: [issue1251748] compiler package: "global a; a=5" In-Reply-To: <1206289032.27.0.491710169705.issue1251748@psf.upfronthosting.co.za> Message-ID: <20080325025039.GA12731@arctrix.com> Neil Schemenauer added the comment: On Sun, Mar 23, 2008 at 04:17:12PM +0000, Antoine Pitrou wrote: > Armin, if you still care about the compiler package, could you (or some > other pypy coder) take a look at #2459? As part of the patch, it > rewrites the flow graph block ordering algorithm in a cleaner way (IMHO). I'm interested to update the compiler package but I'm short of time at the moment. If you want to assign bugs and patches to me, I will try to get to them. Neil _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Mar 25 03:51:34 2008 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 25 Mar 2008 02:51:34 +0000 Subject: [issue2250] rlcompleter raises Exception on bad input In-Reply-To: <1206046172.37.0.368714954386.issue2250@psf.upfronthosting.co.za> Message-ID: <20080325025131.GB12731@arctrix.com> Neil Schemenauer added the comment: On Thu, Mar 20, 2008 at 08:49:32PM +0000, Sean Reifschneider wrote: > Is a straightforward patch, but I'd like NAS to comment on the change in > behavior. Probably would also need a documentation change, are you up > for doing that Lorenz? I doubt that people are relying on complete() to raise NameError or Attribute error. I think it would be okay just to trap them and not change the docs. A note in NEWS should be good enough. Neil __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 04:11:09 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 25 Mar 2008 03:11:09 +0000 Subject: [issue762920] API Functions for PyArray Message-ID: <1206414669.55.0.224771158704.issue762920@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I think this issue is largely superseded by PEP 3118 , which is being backported to 2.6 (see issue2393). AFAICT, the only functionality not available from the new buffer protocol is the ability to create new array objects from C code, but this patch does not provide such functionality either. Travis, can you weigh in on this? I think it may be useful to expose newarrayobject() through some C API compatible with PEP 3118, but otherwise this proposal seems redundant. ---------- nosy: +belopolsky, teoliphant ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Mar 25 05:23:10 2008 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 25 Mar 2008 04:23:10 +0000 Subject: [issue2467] gc.DEBUG_STATS reports invalid "elapsed" times In-Reply-To: <1206294574.77.0.365865271112.issue2467@psf.upfronthosting.co.za> Message-ID: <1206418990.38.0.221128787112.issue2467@psf.upfronthosting.co.za> Neil Schemenauer added the comment: The original code is pretty icky. I'm attaching a patch that improves it, IMO. Before the elapsed time was only shown if garbage was found. I think it should always be shown if DEBUG_STATS is set. ---------- nosy: +nas Added file: http://bugs.python.org/file9843/gc_timestat.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 05:42:53 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 25 Mar 2008 04:42:53 +0000 Subject: [issue2448] namedtuple breaks refleak tests In-Reply-To: <1206125690.78.0.550983870823.issue2448@psf.upfronthosting.co.za> Message-ID: <1206420173.01.0.38652041801.issue2448@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This is a duplicate of issue2223. (See msg63244.) ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 05:46:30 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 25 Mar 2008 04:46:30 +0000 Subject: [issue2447] Python 2.6 refleak test issues In-Reply-To: <1206125520.14.0.711672473194.issue2447@psf.upfronthosting.co.za> Message-ID: <1206420390.05.0.970436214407.issue2447@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This is a duplicate of issue2223. ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 07:15:49 2008 From: report at bugs.python.org (Neal Norwitz) Date: Tue, 25 Mar 2008 06:15:49 +0000 Subject: [issue2477] parser support for future import of unicode_strings In-Reply-To: <1206425748.68.0.392615437966.issue2477@psf.upfronthosting.co.za> Message-ID: <1206425748.68.0.392615437966.issue2477@psf.upfronthosting.co.za> New submission from Neal Norwitz : This is a patch that modifies the parser to allow getting the future import flags into the AST. There are 2 approaches that are embedded within the patch. Both approaches can be seen in Python/pythonrun.c. 1) update_flags_from_node() - this pulls the __future__ import out of the parser nodes. It is not complete, but should give an idea of how this approach could be generalized. 2) Add APIS such as PyParser_ParseFileFlagsEx that returns the flags from the parser The first approach is somewhat fragile and kinda breaks encapsulation. It's nice that all the changes are internal and localized. The second approach is probably a better long term solution, but adds even more APIs where there are already too many. ---------- components: Interpreter Core files: uni-strs.diff keywords: patch messages: 64458 nosy: nnorwitz priority: critical severity: normal status: open title: parser support for future import of unicode_strings versions: Python 2.6 Added file: http://bugs.python.org/file9844/uni-strs.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 08:22:39 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 25 Mar 2008 07:22:39 +0000 Subject: [issue868845] Need unit tests for <...> reprs Message-ID: <1206429759.3.0.113600169442.issue868845@psf.upfronthosting.co.za> Georg Brandl added the comment: Applied doc patch in r61871, r61872 (3.0). ---------- nosy: +georg.brandl ____________________________________ Tracker ____________________________________ From report at bugs.python.org Tue Mar 25 08:25:14 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 25 Mar 2008 07:25:14 +0000 Subject: [issue1054434] automatic XMLRPC boxcarring via multicall for xmlrpclib Message-ID: <1206429914.86.0.322704835898.issue1054434@psf.upfronthosting.co.za> Ralf Schmitt added the comment: I personally have no need for it (not even for non-automatic boxcarring). Note that you would also have to write documentation. ---------- type: -> feature request versions: +Python 2.6 -Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Mar 25 08:45:54 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 25 Mar 2008 07:45:54 +0000 Subject: [issue2330] Update PEP 3000 with new release schedule In-Reply-To: <1205775123.38.0.0848585015118.issue2330@psf.upfronthosting.co.za> Message-ID: <1206431154.01.0.502360175048.issue2330@psf.upfronthosting.co.za> Georg Brandl added the comment: PEP 3000 refers to PEP 361 which has the schedule for both 2.6 and 3.0. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 08:56:34 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 25 Mar 2008 07:56:34 +0000 Subject: [issue2355] Using buffer() should raise a Py3K warning In-Reply-To: <1205782256.14.0.33369210051.issue2355@psf.upfronthosting.co.za> Message-ID: <1206431794.8.0.126315788307.issue2355@psf.upfronthosting.co.za> Georg Brandl added the comment: Added test and committed as r61878. ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 09:01:27 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 25 Mar 2008 08:01:27 +0000 Subject: [issue2357] sys.exc_{type, values, traceback} should raise a Py3K warning In-Reply-To: <1205782726.96.0.925182629024.issue2357@psf.upfronthosting.co.za> Message-ID: <1206432087.09.0.366852466787.issue2357@psf.upfronthosting.co.za> Georg Brandl added the comment: I'd say that since this is so easy for a fixer to spot and fix, no convoluted effort to add a Py3k warning is necessary. (The same goes for sys.exitfunc, #2356). ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 09:27:36 2008 From: report at bugs.python.org (Brett Cannon) Date: Tue, 25 Mar 2008 08:27:36 +0000 Subject: [issue2357] sys.exc_{type, values, traceback} should raise a Py3K warning In-Reply-To: <1205782726.96.0.925182629024.issue2357@psf.upfronthosting.co.za> Message-ID: <1206433656.75.0.0437858199323.issue2357@psf.upfronthosting.co.za> Brett Cannon added the comment: I agree with Georg; a 2to3 fixer is enough. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 09:37:40 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 25 Mar 2008 08:37:40 +0000 Subject: [issue2359] A Py3K warning for array.array.{read,write} is needed In-Reply-To: <1205782883.21.0.134767238935.issue2359@psf.upfronthosting.co.za> Message-ID: <1206434260.4.0.459669754222.issue2359@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed patch as r61881. ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 09:39:43 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 25 Mar 2008 08:39:43 +0000 Subject: [issue2476] optparse docs should mention %default being new in 2.4 In-Reply-To: <1206401399.57.0.922863750504.issue2476@psf.upfronthosting.co.za> Message-ID: <1206434383.94.0.534706695741.issue2476@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r61882. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 09:44:06 2008 From: report at bugs.python.org (Thomas Heller) Date: Tue, 25 Mar 2008 08:44:06 +0000 Subject: [issue2470] Need fixer for dl (removed) -> ctypes module In-Reply-To: <1206376898.67.0.57487519334.issue2470@psf.upfronthosting.co.za> Message-ID: <47E8BB52.104@ctypes.org> Thomas Heller added the comment: > In the simplest case, convert > > import dl > libc = dl.open("libc.so.6") > iconv = libc.call("iconv_open", "ISO-8859-1", "ISO-8859-2") > print(iconv) > > to > > import ctypes > libc = ctypes.CDLL("libc.so.6") > iconv = libc.iconv_open("ISO-8859-1", "ISO-8859-2") > print(iconv) > > Notice that .call has up to 11 arguments, the first one being > the function name. > > Thomas, is it the case that all calls to dl.call can be converted to a > ctypes call without parameter conversion? dl supports these parameter > types: > - byte string, passed as char* > - integers, passed as int > - None, passed as NULL Yes, this is correct. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 09:44:45 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Mar 2008 08:44:45 +0000 Subject: [issue2477] parser support for future import of unicode_strings In-Reply-To: <1206425748.68.0.392615437966.issue2477@psf.upfronthosting.co.za> Message-ID: <1206434685.53.0.227296151132.issue2477@psf.upfronthosting.co.za> Christian Heimes added the comment: I'll check it out today. ---------- assignee: -> tiran nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 09:47:01 2008 From: report at bugs.python.org (Jack Diederich) Date: Tue, 25 Mar 2008 08:47:01 +0000 Subject: [issue2357] sys.exc_{type, values, traceback} should raise a Py3K warning In-Reply-To: <1206433656.75.0.0437858199323.issue2357@psf.upfronthosting.co.za> Message-ID: Jack Diederich added the comment: +1, I'll burn my _apply_evil(ModuleObject *) function patch to moduleobject.c which did a memcpy on a type object and several other heresies. On Tue, Mar 25, 2008 at 4:27 AM, Brett Cannon wrote: > > Brett Cannon added the comment: > > I agree with Georg; a 2to3 fixer is enough. > > > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 10:07:01 2008 From: report at bugs.python.org (Eric Smith) Date: Tue, 25 Mar 2008 09:07:01 +0000 Subject: [issue2477] parser support for future import of unicode_strings In-Reply-To: <1206425748.68.0.392615437966.issue2477@psf.upfronthosting.co.za> Message-ID: <1206436021.66.0.716827362057.issue2477@psf.upfronthosting.co.za> Changes by Eric Smith : ---------- nosy: +eric.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 10:18:37 2008 From: report at bugs.python.org (Armin Rigo) Date: Tue, 25 Mar 2008 09:18:37 +0000 Subject: [issue1251748] compiler package: "global a; a=5" Message-ID: <1206436717.82.0.257665082968.issue1251748@psf.upfronthosting.co.za> Armin Rigo added the comment: Thanks Antoine for the clarification. The situation is that by now PyPy has found many many more bugs in trying to use the compiler package to run the whole stdlib and real-world applications. What I can propose is to extract what we have got and put it back into CPython's stdlib, keeping the current documented API. This will require a little bit of work (e.g. first finishing to add all new 2.5 and 2.6 features into PyPy's compiler) but IMHO it's more worthwhile than going through the process of rediscovering and fixing all the current bugs one by one. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Mar 25 11:13:49 2008 From: report at bugs.python.org (glathoud) Date: Tue, 25 Mar 2008 10:13:49 +0000 Subject: [issue2478] decimal.Decimal( 0 ).sqrt() fails Message-ID: <1206440028.99.0.198815518294.issue2478@psf.upfronthosting.co.za> Changes by glathoud : ---------- components: Library (Lib) nosy: glathoud severity: normal status: open title: decimal.Decimal( 0 ).sqrt() fails type: crash versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 11:14:51 2008 From: report at bugs.python.org (glathoud) Date: Tue, 25 Mar 2008 10:14:51 +0000 Subject: [issue2478] decimal.Decimal( 0 ).sqrt() fails In-Reply-To: <1206440091.4.0.85980098649.issue2478@psf.upfronthosting.co.za> Message-ID: <1206440091.4.0.85980098649.issue2478@psf.upfronthosting.co.za> New submission from glathoud : I got a crash with Python 2.5.2 : Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import decimal >>> decimal.Decimal( 0 ).sqrt() Traceback (most recent call last): File "", line 1, in File "f:\Python25\lib\decimal.py", line 2330, in sqrt return ans._fix(context) File "f:\Python25\lib\decimal.py", line 1461, in _fix Etiny = context.Etiny() AttributeError: 'NoneType' object has no attribute 'Etiny' __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 11:30:04 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Mar 2008 10:30:04 +0000 Subject: [issue2477] parser support for future import of unicode_strings In-Reply-To: <1206425748.68.0.392615437966.issue2477@psf.upfronthosting.co.za> Message-ID: <1206441004.8.0.283185927897.issue2477@psf.upfronthosting.co.za> Christian Heimes added the comment: I've carefully examined both version. I agree that update_flags_from_node is too fragile. I haven't verified my theory but I *think* the current code does neither support from __future__ import egg, spam nor from __future__ import egg from __future__ import spam The PyParser_ParseFileFlagsEx() is easier and more stable. I'll go with it. By the way I also like your name "unicode_strings". Should we stay with it or use my idea "unicode_literals"? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 11:51:12 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Mar 2008 10:51:12 +0000 Subject: [issue2472] Fixed block ordering code in compiler.pyassem In-Reply-To: <1206360580.92.0.370388118897.issue2472@psf.upfronthosting.co.za> Message-ID: <1206442272.02.0.132795555684.issue2472@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Neal, I don't have sufficient permissions to assign bugs to anybody, but here you are in the nosy list. :) ---------- nosy: +nascheme __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 11:57:18 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Mar 2008 10:57:18 +0000 Subject: [issue1251748] compiler package: "global a; a=5" Message-ID: <1206442638.94.0.674330172717.issue1251748@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Armin, it would be nice to merge back your work indeed. If you submit a patch I can take a look at it. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Mar 25 12:05:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Mar 2008 11:05:51 +0000 Subject: [issue2479] Bytearray and io backport In-Reply-To: <1206443150.97.0.809624584179.issue2479@psf.upfronthosting.co.za> Message-ID: <1206443150.97.0.809624584179.issue2479@psf.upfronthosting.co.za> New submission from Christian Heimes : Fix the remaining tests and merge the branch into 2.6 svn+ssh://pythondev at svn.python.org/python/branches/trunk-bytearray So far 5 unit tests are failing. Two are related to pickling/copy and two to subclassing. ---------- components: Interpreter Core, Library (Lib), Tests keywords: 26backport messages: 64475 nosy: tiran priority: critical severity: normal status: open title: Bytearray and io backport versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 12:10:58 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Mar 2008 11:10:58 +0000 Subject: [issue2224] branches/trunk-math patch In-Reply-To: <1204565487.81.0.141440413352.issue2224@psf.upfronthosting.co.za> Message-ID: <1206443458.03.0.498073017926.issue2224@psf.upfronthosting.co.za> Christian Heimes added the comment: Merge Mark's and my math branch into 2.6. IMHO it's ready and stable but I like to get the opinion of yet another core developer first. Merge recipe ------------ Since svnmerge.py causes too many conflicts I've created a patch. However the patch doesn't include copied files from the trunk-math branch. In order to apply the patch one has to copy some files from the trunk-math branch into the trunk. COPY: Python/pymath.c Include/pymath.h Lib/test/cmath_testcases.txt Lib/test/ieee754.txt DELETE: Python/hypot.c Objects/doubledigits.c ---------- priority: high -> critical Added file: http://bugs.python.org/file9845/trunk-math-integration.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 12:11:08 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Mar 2008 11:11:08 +0000 Subject: [issue2224] branches/trunk-math patch In-Reply-To: <1204565487.81.0.141440413352.issue2224@psf.upfronthosting.co.za> Message-ID: <1206443468.97.0.550026364168.issue2224@psf.upfronthosting.co.za> Changes by Christian Heimes : Removed file: http://bugs.python.org/file9594/trunk-math.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 12:32:56 2008 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 25 Mar 2008 11:32:56 +0000 Subject: [issue2477] parser support for future import of unicode_strings In-Reply-To: <1206425748.68.0.392615437966.issue2477@psf.upfronthosting.co.za> Message-ID: <1206444776.78.0.100288287853.issue2477@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: The flag should be named "unicode_literals" since that what changes. Unicode strings are already available in Python 2.x :-) BTW: I'm not convinced that these future imports are all that useful - the ratio between usefulness and added complexity leans a lot towards the latter. ---------- nosy: +lemburg __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 12:53:48 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 25 Mar 2008 11:53:48 +0000 Subject: [issue2026] test_largefile.py converted to unittest In-Reply-To: <1202341696.8.0.722908796599.issue2026@psf.upfronthosting.co.za> Message-ID: <1206446028.04.0.466404168023.issue2026@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Uh! This report is still open. Facundo could you close it? :) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 13:34:44 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 25 Mar 2008 12:34:44 +0000 Subject: [issue2478] decimal.Decimal( 0 ).sqrt() fails In-Reply-To: <1206440091.4.0.85980098649.issue2478@psf.upfronthosting.co.za> Message-ID: <1206448484.73.0.131659713389.issue2478@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: -> rhettinger nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 13:42:48 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Mar 2008 12:42:48 +0000 Subject: [issue2477] parser support for future import of unicode_strings In-Reply-To: <1206425748.68.0.392615437966.issue2477@psf.upfronthosting.co.za> Message-ID: <1206448968.44.0.421825592912.issue2477@psf.upfronthosting.co.za> Christian Heimes added the comment: Working patch I had to introduce yet another PyParser Ex method for string parsing. I also renamed the future feature to "unicode_literals" Added file: http://bugs.python.org/file9846/unicode_literals.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 13:59:24 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 25 Mar 2008 12:59:24 +0000 Subject: [issue2477] parser support for future import of unicode_strings In-Reply-To: <1206425748.68.0.392615437966.issue2477@psf.upfronthosting.co.za> Message-ID: <1206449964.95.0.074773391794.issue2477@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 14:30:35 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Mar 2008 13:30:35 +0000 Subject: [issue2478] decimal.Decimal( 0 ).sqrt() fails In-Reply-To: <1206440091.4.0.85980098649.issue2478@psf.upfronthosting.co.za> Message-ID: <1206451835.05.0.603789422477.issue2478@psf.upfronthosting.co.za> Mark Dickinson added the comment: I'll fix this. ---------- nosy: +marketdickinson __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 14:44:46 2008 From: report at bugs.python.org (Daniel Darabos) Date: Tue, 25 Mar 2008 13:44:46 +0000 Subject: [issue2480] pickling of recursive sets of objects fails In-Reply-To: <1206452686.51.0.217993005172.issue2480@psf.upfronthosting.co.za> Message-ID: <1206452686.51.0.217993005172.issue2480@psf.upfronthosting.co.za> New submission from Daniel Darabos : In the attached demo I create a graph of 250 nodes, all of which are connected to every other node, and this is represented by a set attribute of the Node objects. When I try to pickle this graph, it fails in various ways. In regular pickle it is always a "maximum recursion depth exceeded" error. In cPickle it is either a KeyError or a silent termination of the process. (As tested on Windows XP 32 bits.) It depends on the size of the graph. For smaller graphs (say 100 nodes) it works fine. If connections are described using a dictionary or even a list, I get the same errors. ---------- components: Library (Lib) files: bugdemo.py messages: 64481 nosy: cyhawk severity: normal status: open title: pickling of recursive sets of objects fails versions: Python 2.5 Added file: http://bugs.python.org/file9847/bugdemo.py __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 14:59:55 2008 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Tue, 25 Mar 2008 13:59:55 +0000 Subject: [issue1524825] ConfigParser: accept leading whitespace on options+comments Message-ID: <1206453595.94.0.916383526597.issue1524825@psf.upfronthosting.co.za> Quentin Gallet-Gilles added the comment: Didn't think "a few days" would translate into a month. My bad! Anyway, here's the promised patch. ---------- keywords: +patch Added file: http://bugs.python.org/file9848/cfgparser_comments.patch _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Mar 25 15:02:32 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Mar 2008 14:02:32 +0000 Subject: [issue2478] decimal.Decimal( 0 ).sqrt() fails In-Reply-To: <1206440091.4.0.85980098649.issue2478@psf.upfronthosting.co.za> Message-ID: <1206453752.47.0.704791212716.issue2478@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 15:31:00 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 25 Mar 2008 14:31:00 +0000 Subject: [issue2443] uninitialized access to va_list In-Reply-To: <1206095258.5.0.538024401904.issue2443@psf.upfronthosting.co.za> Message-ID: <1206455460.09.0.852988764434.issue2443@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This is not a bug. All the reported functions expect va_list argument to be initialized before being called. AFAICT, they are consistently used in this way. For example, PyObject * PyObject_CallFunctionObjArgs(PyObject *callable, ...) { PyObject *args, *tmp; va_list vargs; if (callable == NULL) return null_error(); /* count the args */ va_start(vargs, callable); args = objargs_mktuple(vargs); va_end(vargs); if (args == NULL) return NULL; tmp = PyObject_Call(callable, args, NULL); Py_DECREF(args); return tmp; } This may need to be clarified in the docs. For example, PyString_FromFormatV does not mention that vargs needs to be initialized: . On the other hand, this may be obvious to most C programmers. I suggest to close this issue as invalid. ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 15:33:55 2008 From: report at bugs.python.org (Christoph Zwerschke) Date: Tue, 25 Mar 2008 14:33:55 +0000 Subject: [issue2481] locale.strxfrm does not work with Unicode strings In-Reply-To: <1206455635.63.0.674389192114.issue2481@psf.upfronthosting.co.za> Message-ID: <1206455635.63.0.674389192114.issue2481@psf.upfronthosting.co.za> New submission from Christoph Zwerschke : While locale.strcoll seems to work with Unicode strings, locale.strxfrm gives a UnicodeError. Example: ### try: locale.setlocale(locale.LC_ALL, 'de') except locale.Error: # Windoof locale.setlocale(locale.LC_ALL, 'german') s = ['?gypten', 'Zypern'] print sorted(s, cmp=locale.strcoll) # works print sorted(s, key=locale.strxfrm) # works s = [u'?gypten', u'Zypern'] print sorted(s, cmp=locale.strcoll) # works print sorted(s, key=locale.strxfrm) # UnicodeError ### Therefore, it is not possible to sort lists of Unicode strings effectively. If possible, this should be fixed. If not possible, this problem should at least be mentioned in the documentation. Currently, the docs do not indicate that strcoll and strxfrm behave differently concerning Unicode. ---------- components: Unicode messages: 64484 nosy: cito severity: normal status: open title: locale.strxfrm does not work with Unicode strings type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 15:40:08 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Mar 2008 14:40:08 +0000 Subject: [issue2478] decimal.Decimal( 0 ).sqrt() fails In-Reply-To: <1206440091.4.0.85980098649.issue2478@psf.upfronthosting.co.za> Message-ID: <1206456008.05.0.64215345472.issue2478@psf.upfronthosting.co.za> Mark Dickinson added the comment: Fixed in r61892 (2.6) and r61893 (2.5). Thanks for the report! This bug exposes a flaw in the decimal testsuite: the thousands of testcases in Lib/test/decimaltestdata are only ever run with an explicitly given context. Would it be worth having an option to run (almost all) these tests with an implicit context as well, or even to do this by default in addition to the explicit context testing? ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 15:54:08 2008 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Tue, 25 Mar 2008 14:54:08 +0000 Subject: [issue1714] ConfigParser.py do not allow leading (and trailing) space in values. In-Reply-To: <1199115002.03.0.289718233868.issue1714@psf.upfronthosting.co.za> Message-ID: <1206456848.92.0.814079465466.issue1714@psf.upfronthosting.co.za> Changes by Quentin Gallet-Gilles : Removed file: http://bugs.python.org/file9217/cfgparser_doublequotes.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 15:59:05 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 25 Mar 2008 14:59:05 +0000 Subject: [issue2481] locale.strxfrm does not work with Unicode strings In-Reply-To: <1206455635.63.0.674389192114.issue2481@psf.upfronthosting.co.za> Message-ID: <1206457145.87.0.242989032043.issue2481@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: -> loewis nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 16:02:54 2008 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 25 Mar 2008 15:02:54 +0000 Subject: [issue2477] parser support for future import of unicode_strings In-Reply-To: <1206425748.68.0.392615437966.issue2477@psf.upfronthosting.co.za> Message-ID: <1206457374.75.0.611238358518.issue2477@psf.upfronthosting.co.za> Nick Coghlan added the comment: The patch actually isn't all that complicated - the main structural change to make it possible to process the strings correctly is converting the parser functions to have treat the flags argument as an I/O variable, rather than just an input. Other than that, there are just some fairly straightforward updates to the compiler to take advantage of the additional flag information now available from the parser. Being able to write significant pieces of code that run on both 2.6 and 3.0 without modification will be a big win in my opinion. While 2to3 will still be a valuable migration tool, especially for one-way migrations, it will be far far easier to support 2.6 and 3.0 in parallel if that pseudo-compilation step isn't necessary. Also Christian - the posted patch accidentally included your hack to make the version info a bit more non-SVN checkout friendly. ---------- nosy: +ncoghlan __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 16:14:36 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 25 Mar 2008 15:14:36 +0000 Subject: [issue2443] uninitialized access to va_list In-Reply-To: <1206095258.5.0.538024401904.issue2443@psf.upfronthosting.co.za> Message-ID: <1206458076.63.0.619475373148.issue2443@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: On the second thought the macro dance highlighted by OP belongs to pyport.h. Attached patch defines Py_VA_COPY macro and uses it to simplify va_list copying code. ---------- keywords: +patch Added file: http://bugs.python.org/file9849/issue2443.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 16:37:13 2008 From: report at bugs.python.org (Oleg Broytmann) Date: Tue, 25 Mar 2008 15:37:13 +0000 Subject: [issue2482] Decimal(unicode) In-Reply-To: <1206459433.83.0.00721913185616.issue2482@psf.upfronthosting.co.za> Message-ID: <1206459433.83.0.00721913185616.issue2482@psf.upfronthosting.co.za> New submission from Oleg Broytmann : Decimal(u'123').to_eng_string() returns unicode in Python 2.5.2. That's probably due to the optimization in decimal module, after which decimal stores coefficient (mantissa) as a str, and doesn't coerce input to str. See the thread at http://mail.python.org/pipermail/python-dev/2008-March/078189.html ---------- components: Library (Lib) messages: 64488 nosy: phd severity: normal status: open title: Decimal(unicode) type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 16:42:08 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Mar 2008 15:42:08 +0000 Subject: [issue2482] Decimal(unicode) In-Reply-To: <1206459433.83.0.00721913185616.issue2482@psf.upfronthosting.co.za> Message-ID: <1206459728.19.0.713385569571.issue2482@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: -> marketdickinson nosy: +marketdickinson versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 16:42:23 2008 From: report at bugs.python.org (Collin Winter) Date: Tue, 25 Mar 2008 15:42:23 +0000 Subject: [issue2431] 2to3 is rather slow In-Reply-To: <1205991054.16.0.327808127723.issue2431@psf.upfronthosting.co.za> Message-ID: <1206459743.65.0.44290488732.issue2431@psf.upfronthosting.co.za> Collin Winter added the comment: With the patch applied, all tests in test_fixers fail. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 16:51:09 2008 From: report at bugs.python.org (Facundo Batista) Date: Tue, 25 Mar 2008 15:51:09 +0000 Subject: [issue2482] Decimal(unicode) In-Reply-To: <1206459433.83.0.00721913185616.issue2482@psf.upfronthosting.co.za> Message-ID: <1206460269.31.0.866325135242.issue2482@psf.upfronthosting.co.za> Facundo Batista added the comment: Decimal needs to grow something like the following near the top of the module: try: _bytes = bytes except NameError: # 2.5 or earlier _bytes = str and then use _bytes instead of str as appropriate throughout the rest of the module. This will solve the actual problem, and scales well with 2.6 and 3k. ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 16:55:06 2008 From: report at bugs.python.org (Facundo Batista) Date: Tue, 25 Mar 2008 15:55:06 +0000 Subject: [issue2478] decimal.Decimal( 0 ).sqrt() fails In-Reply-To: <1206440091.4.0.85980098649.issue2478@psf.upfronthosting.co.za> Message-ID: <1206460506.12.0.0407349677048.issue2478@psf.upfronthosting.co.za> Facundo Batista added the comment: It'd be nice to have it, but actually I'm not sure that this is doable without some heavy editing of decimal's test framework. Thanks! ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 17:03:39 2008 From: report at bugs.python.org (Daniel Darabos) Date: Tue, 25 Mar 2008 16:03:39 +0000 Subject: [issue2480] pickling of large recursive structures fails In-Reply-To: <1206452686.51.0.217993005172.issue2480@psf.upfronthosting.co.za> Message-ID: <1206461019.51.0.436013102667.issue2480@psf.upfronthosting.co.za> Daniel Darabos added the comment: So now I've learned that this is a result of the way Pickler is implemented. I think that it would make sense to create an implementation that is not that recursive and that would handle such structures better. I have now written one such implementation that is a subclass of the original pickler and handles recursive data structures. I presume that it is inferior in a couple of ways (performance and memory efficiency probably), but a complete rewrite could probably create an implementation that handles recursive data structures and is not inferior. ---------- title: pickling of recursive sets of objects fails -> pickling of large recursive structures fails Added file: http://bugs.python.org/file9850/nonrecursivepickler.py __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 17:04:13 2008 From: report at bugs.python.org (Daniel Darabos) Date: Tue, 25 Mar 2008 16:04:13 +0000 Subject: [issue2480] pickling of large recursive structures fails In-Reply-To: <1206452686.51.0.217993005172.issue2480@psf.upfronthosting.co.za> Message-ID: <1206461053.6.0.178640285432.issue2480@psf.upfronthosting.co.za> Changes by Daniel Darabos : Added file: http://bugs.python.org/file9851/picklertest.py __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 17:13:06 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 25 Mar 2008 16:13:06 +0000 Subject: [issue2480] pickling of large recursive structures fails In-Reply-To: <1206452686.51.0.217993005172.issue2480@psf.upfronthosting.co.za> Message-ID: <1206461586.83.0.509958650691.issue2480@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 17:14:00 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 25 Mar 2008 16:14:00 +0000 Subject: [issue1714] ConfigParser.py do not allow leading (and trailing) space in values. In-Reply-To: <1199115002.03.0.289718233868.issue1714@psf.upfronthosting.co.za> Message-ID: <1206461640.41.0.546834482018.issue1714@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 17:15:13 2008 From: report at bugs.python.org (Daniel Darabos) Date: Tue, 25 Mar 2008 16:15:13 +0000 Subject: [issue2480] pickling of large recursive structures fails In-Reply-To: <1206452686.51.0.217993005172.issue2480@psf.upfronthosting.co.za> Message-ID: <1206461713.05.0.732585241451.issue2480@psf.upfronthosting.co.za> Daniel Darabos added the comment: Sidenote: If I click "edit" for nonrecursivepickler.py, I get told that "File has been classified as spam." Strange. Should I not use Viagra as a classname? :) (j/k I didn't do anything like that) However I have now fixed a mistake in my code. Added file: http://bugs.python.org/file9852/nonrecursivepickler-fixed.py __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 17:22:00 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Mar 2008 16:22:00 +0000 Subject: [issue2483] int and float accept bytes, complex does not In-Reply-To: <1206462120.7.0.66925954466.issue2483@psf.upfronthosting.co.za> Message-ID: <1206462120.7.0.66925954466.issue2483@psf.upfronthosting.co.za> New submission from Mark Dickinson : In 3.0, the int and float constructors accepts bytes instances as well as strings: >>> int(b'1') 1 >>> float(b'1') 1.0 but the complex constructor doesn't: >>> complex(b'1') Traceback (most recent call last): File "", line 1, in TypeError: complex() argument must be a string or a number I'd suggest that at least one of these three results is a bug, but I'm not sure which. >From a purity point of view, I think int() and float() shouldn't accept bytes. Is this a case of practicality beats purity? What are the pratical reasons to have int() and float() accept bytes? Once this is resolved, the behaviors of Decimal and Fraction should also be considered. ---------- components: Interpreter Core messages: 64494 nosy: marketdickinson severity: normal status: open title: int and float accept bytes, complex does not type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 17:25:36 2008 From: report at bugs.python.org (David Wolever) Date: Tue, 25 Mar 2008 16:25:36 +0000 Subject: [issue2431] 2to3 is rather slow In-Reply-To: <1205991054.16.0.327808127723.issue2431@psf.upfronthosting.co.za> Message-ID: <1206462336.12.0.814921308462.issue2431@psf.upfronthosting.co.za> David Wolever added the comment: Ah, yea -- in my rush to catch my train I must have neglected to look at the _results_ of running test.py... I have updated the patch so the fixers will work. Added file: http://bugs.python.org/file9853/fixer_head_node_lookup_2.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 17:37:57 2008 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 25 Mar 2008 16:37:57 +0000 Subject: [issue1251748] compiler package: "global a; a=5" In-Reply-To: <1206436717.82.0.257665082968.issue1251748@psf.upfronthosting.co.za> Message-ID: <20080325163752.GB16219@arctrix.com> Neil Schemenauer added the comment: On Tue, Mar 25, 2008 at 09:18:38AM +0000, Armin Rigo wrote: > The situation is that by now PyPy has found many many more bugs in > trying to use the compiler package to run the whole stdlib and > real-world applications. What I can propose is to extract what we have > got and put it back into CPython's stdlib, keeping the current > documented API. I'm not sure it can go back into the stdlib since there doesn't seem to be enough energy available to keep it up-to-date with the Python release schedule. I would like to make it available as an add-on package. > This will require a little bit of work (e.g. first > finishing to add all new 2.5 and 2.6 features into PyPy's compiler) > but IMHO it's more worthwhile than going through the process of > rediscovering and fixing all the current bugs one by one. Indeed it would make no sense to redo that work. Can the version in the PyPy tree be used as a direct replacement for the stdlib version or does it need some changes? You had mentioned being able to produce a patch against the stdlib version. Is that easy or would it be better just to take the PyPy version and package it up. Neil _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Mar 25 17:54:50 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Mar 2008 16:54:50 +0000 Subject: [issue2477] parser support for future import of unicode_strings In-Reply-To: <1206425748.68.0.392615437966.issue2477@psf.upfronthosting.co.za> Message-ID: <1206464090.38.0.117801971647.issue2477@psf.upfronthosting.co.za> Christian Heimes added the comment: > Also Christian - the posted patch accidentally included your hack to make the version info a bit more non-SVN checkout friendly. I'm still learning bzr. I just have figured out how to merge changes from the upstream trunk into my branch. It's actually nice ... __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 17:57:58 2008 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 25 Mar 2008 16:57:58 +0000 Subject: [issue2483] int and float accept bytes, complex does not In-Reply-To: <1206462120.7.0.66925954466.issue2483@psf.upfronthosting.co.za> Message-ID: <1206464278.35.0.916451352308.issue2483@psf.upfronthosting.co.za> Nick Coghlan added the comment: I have a couple of use cases for bytes-as-ASCII-text -> int, one of which also touches on floats. The other numeric types also accepting bytes as representing ASCII encoded strings would then follow from a consistency of behaviour argument. Use case 1: Decimal implementation The simplest way to retain the 2.x series decimal performance in 3.0 is to switch the mantissa storage from a string to a bytes object. This is only possible if the int constructor accepts bytes objects and treats them as an ASCII-encoded string. Use case 2: Serial protocols with embedded ASCII text I work with a lot of control protocols for different pieces of hardware, and one way the hardware vendors avoid having to write a custom control interface for their hardware is to make their serial interface human readable (so a terminal program like Hyperterminal or Miniterm becomes their user interface). Writing automated control software for these devices is essentially an exercise in screen-scraping the ASCII strings received on the serial port. Having to go through Unicode to convert ASCII digits embedded in these strings to numbers would be a major pain. While these numbers are mostly integers, you do get the occasional floating point value turning up as well, so bytes->float can also be useful. ---------- nosy: +ncoghlan __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 18:00:05 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Tue, 25 Mar 2008 17:00:05 +0000 Subject: [issue2484] Cosmetic patch for warning "unused variable" In-Reply-To: <1206464405.54.0.178616668761.issue2484@psf.upfronthosting.co.za> Message-ID: <1206464405.54.0.178616668761.issue2484@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : "int i,j;" in inner block is hiding "Py_ssize_t i,j;" ---------- components: Extension Modules files: fix_warning.patch keywords: patch, patch messages: 64499 nosy: ocean-city severity: normal status: open title: Cosmetic patch for warning "unused variable" versions: Python 3.0 Added file: http://bugs.python.org/file9854/fix_warning.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 18:23:37 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Mar 2008 17:23:37 +0000 Subject: [issue2443] uninitialized access to va_list In-Reply-To: <1206095258.5.0.538024401904.issue2443@psf.upfronthosting.co.za> Message-ID: <1206465817.26.0.15352846661.issue2443@psf.upfronthosting.co.za> Christian Heimes added the comment: Looks like a good idea to me ---------- priority: high -> critical resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 18:43:40 2008 From: report at bugs.python.org (Collin Winter) Date: Tue, 25 Mar 2008 17:43:40 +0000 Subject: [issue2431] 2to3 is rather slow In-Reply-To: <1205991054.16.0.327808127723.issue2431@psf.upfronthosting.co.za> Message-ID: <1206467020.64.0.157043195178.issue2431@psf.upfronthosting.co.za> Collin Winter added the comment: The updated version of the patch passes the tests and yields a 19-20% speed increase in the running time of test_all_fixers and the time taken for 2to3 to translate itself. I've sent David some comments on the patch, and once it's cleaned up some, this will be checked in. I'd like to keep the issue open, since there are clearly additional speed increases to be made. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 18:54:51 2008 From: report at bugs.python.org (Georg Brandl) Date: Tue, 25 Mar 2008 17:54:51 +0000 Subject: [issue2484] Cosmetic patch for warning "unused variable" In-Reply-To: <1206464405.54.0.178616668761.issue2484@psf.upfronthosting.co.za> Message-ID: <1206467691.07.0.44409016388.issue2484@psf.upfronthosting.co.za> Georg Brandl added the comment: This seems to be already fixed in trunk. Can you confirm? ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 18:59:21 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 25 Mar 2008 17:59:21 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224705.13.0.0890165071291.issue2459@psf.upfronthosting.co.za> Message-ID: <1206467962.0.0.470088760031.issue2459@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: +gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 19:05:49 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 25 Mar 2008 18:05:49 +0000 Subject: [issue2443] Define Py_VA_COPY macro as a cross-platform replacement for gcc __va_copy In-Reply-To: <1206095258.5.0.538024401904.issue2443@psf.upfronthosting.co.za> Message-ID: <1206468349.22.0.89966107688.issue2443@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- title: uninitialized access to va_list -> Define Py_VA_COPY macro as a cross-platform replacement for gcc __va_copy type: compile error -> feature request __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 19:21:12 2008 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Tue, 25 Mar 2008 18:21:12 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za> Message-ID: <1206469272.99.0.688616755083.issue2459@psf.upfronthosting.co.za> Changes by Fred L. Drake, Jr. : __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 19:21:20 2008 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Tue, 25 Mar 2008 18:21:20 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za> Message-ID: <1206469280.54.0.858440509513.issue2459@psf.upfronthosting.co.za> Changes by Fred L. Drake, Jr. : __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 19:28:55 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Mar 2008 18:28:55 +0000 Subject: [issue2483] int and float accept bytes, complex does not In-Reply-To: <1206462120.7.0.66925954466.issue2483@psf.upfronthosting.co.za> Message-ID: <1206469735.12.0.690910136386.issue2483@psf.upfronthosting.co.za> Mark Dickinson added the comment: For both these use cases, don't you still have a problem going the other way, from an integer back to bytes? Is there an easier way than bytes(str(n), 'ascii') ? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 19:41:55 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Mar 2008 18:41:55 +0000 Subject: [issue2482] Decimal(unicode) In-Reply-To: <1206459433.83.0.00721913185616.issue2482@psf.upfronthosting.co.za> Message-ID: <1206470515.58.0.565024216976.issue2482@psf.upfronthosting.co.za> Mark Dickinson added the comment: I'm not sure that converting to bytes for Python 3.0 is going to be a simple change. For one thing, most of the arithmetic functions have to do the reverse conversion (int -> str/bytes) at some point. At the moment, an int -> bytes conversion has to go through unicode (I think); something like bytes(str(n), 'ascii'), so it's not 100% clear that replacing str with bytes is going to produce a speed gain. For now, I'll get the fix for the 2.5/2.6 problem in (it only involves changing 3 lines in decimal.py, along with adding a few extra tests). Changing str -> bytes in 3.0 needs more careful thought, and some benchmarking. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 20:02:44 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Mar 2008 19:02:44 +0000 Subject: [issue2482] Decimal(unicode) In-Reply-To: <1206459433.83.0.00721913185616.issue2482@psf.upfronthosting.co.za> Message-ID: <1206471764.8.0.599725346067.issue2482@psf.upfronthosting.co.za> Mark Dickinson added the comment: str -> unicode regression fixed in r61904, r61906. (I backported the fix to 2.5; it's not absolutely clear that it's worth it, but this *is* a bug, and it seems worth not letting the various decimal.py versions diverge too much.) __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 20:19:26 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Mar 2008 19:19:26 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za> Message-ID: <1206472766.38.0.672198836364.issue2459@psf.upfronthosting.co.za> Antoine Pitrou added the comment: By the way, the compiler package fix has been isolated and cleaned up as part of #2472. Maybe it would be nice to start with that one. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 20:27:28 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 25 Mar 2008 19:27:28 +0000 Subject: [issue1251748] compiler package: "global a; a=5" Message-ID: <1206473248.56.0.0226141660552.issue1251748@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It seems to me that releasing it as a third-party package would be a little contradictory, since the compiler package is supposed to follow the CPython core (compile.c etc.) evolutions. In any case, whatever the decision (stdlib package or separate releases), I think it would be nice if there was a slightly more comprehensive test suite. :) Something like running some selected non-controversial parts of the test suite compiled with the compiler package (like PyPy does apparently) could be a good start. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Tue Mar 25 20:37:05 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Mar 2008 19:37:05 +0000 Subject: [issue2477] parser support for future import of unicode_strings In-Reply-To: <1206425748.68.0.392615437966.issue2477@psf.upfronthosting.co.za> Message-ID: <1206473825.89.0.927374519697.issue2477@psf.upfronthosting.co.za> Changes by Christian Heimes : Removed file: http://bugs.python.org/file9846/unicode_literals.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 20:38:02 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Mar 2008 19:38:02 +0000 Subject: [issue2477] parser support for future import of unicode_strings In-Reply-To: <1206425748.68.0.392615437966.issue2477@psf.upfronthosting.co.za> Message-ID: <1206473882.76.0.536570382183.issue2477@psf.upfronthosting.co.za> Christian Heimes added the comment: Slightly better patch * removed bzr hack * simplified parsestr() * updated NEWS Added file: http://bugs.python.org/file9855/unicode_literals2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 21:32:11 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 25 Mar 2008 20:32:11 +0000 Subject: [issue2196] Fix hasattr's exception problems In-Reply-To: <1204066315.71.0.0794011213674.issue2196@psf.upfronthosting.co.za> Message-ID: <1206477131.37.0.845122024574.issue2196@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 21:42:41 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 25 Mar 2008 20:42:41 +0000 Subject: [issue2390] Merge 2.6 ACKS with 3.0 ACKS In-Reply-To: <1205854707.75.0.657591820184.issue2390@psf.upfronthosting.co.za> Message-ID: <1206477761.24.0.0147458088568.issue2390@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Since the ACKS have changed since I did this merge, shall I remerge and commit the changes to both branches? __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 21:43:45 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 25 Mar 2008 20:43:45 +0000 Subject: [issue2026] test_largefile.py converted to unittest In-Reply-To: <1202341696.8.0.722908796599.issue2026@psf.upfronthosting.co.za> Message-ID: <1206477825.76.0.151087635463.issue2026@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 21:54:21 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Mar 2008 20:54:21 +0000 Subject: [issue2390] Merge 2.6 ACKS with 3.0 ACKS In-Reply-To: <1205854707.75.0.657591820184.issue2390@psf.upfronthosting.co.za> Message-ID: <1206478461.3.0.436888989902.issue2390@psf.upfronthosting.co.za> Christian Heimes added the comment: Yes, please sync the ACKS files again. ---------- assignee: tiran -> benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 22:16:06 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 25 Mar 2008 21:16:06 +0000 Subject: [issue2390] Merge 2.6 ACKS with 3.0 ACKS In-Reply-To: <1205854707.75.0.657591820184.issue2390@psf.upfronthosting.co.za> Message-ID: <1206479766.58.0.027742320145.issue2390@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Commited in r61913 and r61914. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 22:17:52 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Mar 2008 21:17:52 +0000 Subject: [issue2390] Merge 2.6 ACKS with 3.0 ACKS In-Reply-To: <1205854707.75.0.657591820184.issue2390@psf.upfronthosting.co.za> Message-ID: <1206479872.3.0.0786242030248.issue2390@psf.upfronthosting.co.za> Christian Heimes added the comment: For the record You don't have to merge changes from 2.6 to 3.0 manually. In fact you mustn't unless you explicitly block the revision with svnmerge.py. In general you submit a change to 2.6 and it gets merged into 3.0 later. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 22:19:44 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 25 Mar 2008 21:19:44 +0000 Subject: [issue2390] Merge 2.6 ACKS with 3.0 ACKS In-Reply-To: <1206479872.3.0.0786242030248.issue2390@psf.upfronthosting.co.za> Message-ID: <1afaf6160803251419n34a33b6dtb65204cd76bdc4ec@mail.gmail.com> Benjamin Peterson added the comment: On Tue, Mar 25, 2008 at 4:17 PM, Christian Heimes wrote: > > Christian Heimes added the comment: > > For the record > > You don't have to merge changes from 2.6 to 3.0 manually. In fact you > mustn't unless you explicitly block the revision with svnmerge.py. In > general you submit a change to 2.6 and it gets merged into 3.0 later. Thanks for the heads up. Should I block the revision then? > > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file9856/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080325/a7209495/attachment.txt From report at bugs.python.org Tue Mar 25 22:23:18 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Mar 2008 21:23:18 +0000 Subject: [issue2390] Merge 2.6 ACKS with 3.0 ACKS In-Reply-To: <1205854707.75.0.657591820184.issue2390@psf.upfronthosting.co.za> Message-ID: <1206480198.75.0.126618587138.issue2390@psf.upfronthosting.co.za> Christian Heimes added the comment: I think I'll follow a different path here. I may end up with svn rm Misc/ACKS svn copy ../trunk/Misc/ACKS Misc/ It should make future merges easier. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 22:25:15 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 25 Mar 2008 21:25:15 +0000 Subject: [issue2390] Merge 2.6 ACKS with 3.0 ACKS In-Reply-To: <1206480198.75.0.126618587138.issue2390@psf.upfronthosting.co.za> Message-ID: <1afaf6160803251425x714727a3gdd785b0114b3032f@mail.gmail.com> Benjamin Peterson added the comment: On Tue, Mar 25, 2008 at 4:23 PM, Christian Heimes wrote: > > Christian Heimes added the comment: > > I think I'll follow a different path here. I may end up with > > svn rm Misc/ACKS > svn copy ../trunk/Misc/ACKS Misc/ That's what I did. They are exactly the same file. > > > It should make future merges easier. > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file9857/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080325/56843f70/attachment.txt From report at bugs.python.org Tue Mar 25 22:26:20 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 25 Mar 2008 21:26:20 +0000 Subject: [issue2481] locale.strxfrm does not work with Unicode strings In-Reply-To: <1206455635.63.0.674389192114.issue2481@psf.upfronthosting.co.za> Message-ID: <1206480380.26.0.631435998515.issue2481@psf.upfronthosting.co.za> Martin v. L?wis added the comment: FWIW, this is fixed in Python 3.0. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 22:27:47 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 25 Mar 2008 21:27:47 +0000 Subject: [issue2390] Merge 2.6 ACKS with 3.0 ACKS In-Reply-To: <1205854707.75.0.657591820184.issue2390@psf.upfronthosting.co.za> Message-ID: <1206480467.59.0.283199267632.issue2390@psf.upfronthosting.co.za> Changes by Benjamin Peterson : Removed file: http://bugs.python.org/file9856/unnamed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 22:28:01 2008 From: report at bugs.python.org (Martin Geisler) Date: Tue, 25 Mar 2008 21:28:01 +0000 Subject: [issue2485] Traceback changed in 2.6 for unhashable objects In-Reply-To: <1206480481.83.0.917185709948.issue2485@psf.upfronthosting.co.za> Message-ID: <1206480481.83.0.917185709948.issue2485@psf.upfronthosting.co.za> New submission from Martin Geisler : The traceback message given when trying to hash unhashable objects has changed from Python 2.5 to 2.6: Python 2.5.2a0 (r251:54863, Feb 10 2008, 01:31:28) >>> hash([]) Traceback (most recent call last): File "", line 1, in TypeError: list objects are unhashable Python 2.6a1 (r26a1:61143, Mar 25 2008, 19:41:30) >>> hash([]) Traceback (most recent call last): File "", line 1, in TypeError: unhashable type: 'list' This breaks my Doctests unless I add a somewhat ugly "# doctest: +IGNORE_EXCEPTION_DETAIL" comment, so if this is not done on purpose, I would prefer Python 2.6 to output the same as 2.5. ---------- messages: 64517 nosy: mg severity: normal status: open title: Traceback changed in 2.6 for unhashable objects type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 22:28:02 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 25 Mar 2008 21:28:02 +0000 Subject: [issue2390] Merge 2.6 ACKS with 3.0 ACKS In-Reply-To: <1205854707.75.0.657591820184.issue2390@psf.upfronthosting.co.za> Message-ID: <1206480482.03.0.351669958746.issue2390@psf.upfronthosting.co.za> Changes by Benjamin Peterson : Removed file: http://bugs.python.org/file9857/unnamed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 22:29:18 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 25 Mar 2008 21:29:18 +0000 Subject: [issue2481] locale.strxfrm does not work with Unicode strings In-Reply-To: <1206455635.63.0.674389192114.issue2481@psf.upfronthosting.co.za> Message-ID: <1206480558.62.0.231636524996.issue2481@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Can it be backported? ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 22:29:33 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Mar 2008 21:29:33 +0000 Subject: [issue2390] Merge 2.6 ACKS with 3.0 ACKS In-Reply-To: <1205854707.75.0.657591820184.issue2390@psf.upfronthosting.co.za> Message-ID: <1206480572.99.0.294531602111.issue2390@psf.upfronthosting.co.za> Christian Heimes added the comment: Are you absolutely sure you have used "svn copy"? The logs don't show a svn copy. __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 22:31:49 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 25 Mar 2008 21:31:49 +0000 Subject: [issue2390] Merge 2.6 ACKS with 3.0 ACKS In-Reply-To: <1206480572.99.0.294531602111.issue2390@psf.upfronthosting.co.za> Message-ID: <1afaf6160803251431q61f68157h9d6dec4d777a7af0@mail.gmail.com> Benjamin Peterson added the comment: On Tue, Mar 25, 2008 at 4:29 PM, Christian Heimes wrote: > > Christian Heimes added the comment: > > Are you absolutely sure you have used "svn copy"? The logs don't show a > svn copy. Oh, no. I copied with cp, so svn doesn't know about it. > > > __________________________________ > Tracker > > __________________________________ > Added file: http://bugs.python.org/file9858/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080325/4ed3a297/attachment.txt From report at bugs.python.org Tue Mar 25 22:36:15 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Mar 2008 21:36:15 +0000 Subject: [issue2486] Consider using bytes type instead of str to store Decimal coefficients In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za> Message-ID: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za> New submission from Mark Dickinson : The Python 3.0 version of decimal.py currently stores the coefficient of a Decimal number (or the payload of a NaN) as a string, all of whose characters are in the range '0' through '9'. It may be more time-efficient to store the coefficient as a bytes instance instead, since bytes -> int conversion is likely to be faster than str -> int conversion. On the other hand, int -> bytes conversion has to go through str, so may be significantly slower than int -> str conversion... Bottom line: this needs testing. One other option: it may even be worth considering storing the coefficient directly as a Python integer. I've argued against this before, on the basis that it makes direct access to the decimal digits of a number harder, and this direct access is useful for rounding as well as for some of the more esoteric Decimal operations (logical operations, shifts and rotations). But it may be worth a look. (I think it's clear what the *right* option is, given unlimited developer time and energy: decimal.py should represent the coefficient using a long integer implementation written in C, with wordsize a power of 10---probably either 10**4 or 10**9.) See related discussion at issue 2482 and at http://mail.python.org/pipermail/python-dev/2008-March/078189.html ---------- components: Library (Lib) messages: 64521 nosy: facundobatista, marketdickinson, ncoghlan severity: normal status: open title: Consider using bytes type instead of str to store Decimal coefficients type: performance versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 22:38:32 2008 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Mar 2008 21:38:32 +0000 Subject: [issue2482] Decimal(unicode) In-Reply-To: <1206459433.83.0.00721913185616.issue2482@psf.upfronthosting.co.za> Message-ID: <1206481111.96.0.214142128477.issue2482@psf.upfronthosting.co.za> Mark Dickinson added the comment: The original bug here is fixed, so I'm closing this issue. I've opened a separate issue (issue 2486) for discussing changing the Decimal coefficient from str to bytes. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 22:40:20 2008 From: report at bugs.python.org (Rolland Dudemaine) Date: Tue, 25 Mar 2008 21:40:20 +0000 Subject: [issue2443] uninitialized access to va_list In-Reply-To: <1206455460.09.0.852988764434.issue2443@psf.upfronthosting.co.za> Message-ID: <47E9713F.3090009@ghs.com> Rolland Dudemaine added the comment: This is what I meant. The initialization should be done by calling va_start(count_va); as you described. In the files and lines I reported though, this is not called. I'll file a patch for it soon. --Rolland Dudemaine Alexander Belopolsky wrote: > Alexander Belopolsky added the comment: > > This is not a bug. All the reported functions expect va_list argument > to be initialized before being called. AFAICT, they are consistently > used in this way. For example, > > PyObject * > PyObject_CallFunctionObjArgs(PyObject *callable, ...) > { > PyObject *args, *tmp; > va_list vargs; > > if (callable == NULL) > return null_error(); > > /* count the args */ > va_start(vargs, callable); > args = objargs_mktuple(vargs); > va_end(vargs); > if (args == NULL) > return NULL; > tmp = PyObject_Call(callable, args, NULL); > Py_DECREF(args); > > return tmp; > } > > This may need to be clarified in the docs. For example, PyString_FromFormatV does not mention that vargs needs to be > initialized: api/string.html#PyString_FromFormatV>. On the other hand, this may be > obvious to most C programmers. > > I suggest to close this issue as invalid. > > ---------- > nosy: +belopolsky > > __________________________________ > Tracker > > __________________________________ > ---------- title: Define Py_VA_COPY macro as a cross-platform replacement for gcc __va_copy -> uninitialized access to va_list __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 22:43:10 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Tue, 25 Mar 2008 21:43:10 +0000 Subject: [issue2481] locale.strxfrm does not work with Unicode strings In-Reply-To: <1206455635.63.0.674389192114.issue2481@psf.upfronthosting.co.za> Message-ID: <1206481390.62.0.117992747993.issue2481@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Sure, although it probably shouldn't be backported to 2.5. ---------- versions: +Python 2.6 -Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 23:00:30 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 25 Mar 2008 22:00:30 +0000 Subject: [issue2457] add --help and -h options to pdb In-Reply-To: <1206214872.65.0.48935135608.issue2457@psf.upfronthosting.co.za> Message-ID: <1206482430.96.0.80885750407.issue2457@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- assignee: -> benjamin.peterson priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 23:00:43 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 25 Mar 2008 22:00:43 +0000 Subject: [issue2457] add --help and -h options to pdb In-Reply-To: <1206214872.65.0.48935135608.issue2457@psf.upfronthosting.co.za> Message-ID: <1206482443.81.0.338664143838.issue2457@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- assignee: benjamin.peterson -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Tue Mar 25 23:41:57 2008 From: report at bugs.python.org (Thomas Heller) Date: Tue, 25 Mar 2008 22:41:57 +0000 Subject: [issue2470] Need fixer for dl (removed) -> ctypes module In-Reply-To: <47E8BB52.104@ctypes.org> Message-ID: <47E97FC5.2070000@ctypes.org> Thomas Heller added the comment: Thomas Heller schrieb: > Thomas Heller added the comment: > >> In the simplest case, convert >> >> import dl >> libc = dl.open("libc.so.6") >> iconv = libc.call("iconv_open", "ISO-8859-1", "ISO-8859-2") >> print(iconv) >> >> to >> >> import ctypes >> libc = ctypes.CDLL("libc.so.6") >> iconv = libc.iconv_open("ISO-8859-1", "ISO-8859-2") >> print(iconv) >> Currently, in py3k, ctypes only passed bytes objects as char*; so the strings should be translated to bytes literals: import ctypes libc = ctypes.CDLL("libc.so.6") iconv = libc.iconv_open(b"ISO-8859-1", b"ISO-8859-2") # ^ ^ print(iconv) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 00:25:38 2008 From: report at bugs.python.org (Fredrik Johansson) Date: Tue, 25 Mar 2008 23:25:38 +0000 Subject: [issue2487] ldexp(x,n) misbehaves when abs(n) is large In-Reply-To: <1206487537.98.0.104101200523.issue2487@psf.upfronthosting.co.za> Message-ID: <1206487537.98.0.104101200523.issue2487@psf.upfronthosting.co.za> New submission from Fredrik Johansson : Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from math import ldexp >>> from sys import maxint >>> ldexp(1.234, maxint//2) Traceback (most recent call last): File "", line 1, in OverflowError: math range error >>> ldexp(1.234, maxint) 0.0 >>> ldexp(1.234, -maxint) 0.0 >>> ldexp(1.234, -maxint-2) Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int The first and third cases seem right. The second is clearly a bug. In the fourth case, it would be more correct to return 0.0 than to raise an exception IMHO. ---------- components: Library (Lib) messages: 64527 nosy: fredrikj severity: normal status: open title: ldexp(x,n) misbehaves when abs(n) is large type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 00:35:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Mar 2008 23:35:51 +0000 Subject: [issue2488] Backport sys.maxsize to Python 2.6 In-Reply-To: <1206488150.94.0.908333325517.issue2488@psf.upfronthosting.co.za> Message-ID: <1206488150.94.0.908333325517.issue2488@psf.upfronthosting.co.za> New submission from Christian Heimes : See topic ---------- components: Extension Modules keywords: 26backport, easy messages: 64528 nosy: tiran priority: high severity: normal status: open title: Backport sys.maxsize to Python 2.6 type: feature request versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 00:38:08 2008 From: report at bugs.python.org (Christian Heimes) Date: Tue, 25 Mar 2008 23:38:08 +0000 Subject: [issue2487] ldexp(x,n) misbehaves when abs(n) is large In-Reply-To: <1206487537.98.0.104101200523.issue2487@psf.upfronthosting.co.za> Message-ID: <1206488288.7.0.167689526046.issue2487@psf.upfronthosting.co.za> Christian Heimes added the comment: ldexp(1.234, maxint) works as expected in our trunk-math branch. ldexp(1.234, -maxint-2) fails with the same error message. ---------- assignee: -> marketdickinson nosy: +marketdickinson, tiran priority: -> normal versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 01:03:52 2008 From: report at bugs.python.org (Ryan Freckleton) Date: Wed, 26 Mar 2008 00:03:52 +0000 Subject: [issue2488] Backport sys.maxsize to Python 2.6 In-Reply-To: <1206488150.94.0.908333325517.issue2488@psf.upfronthosting.co.za> Message-ID: <1206489832.31.0.741537819684.issue2488@psf.upfronthosting.co.za> Ryan Freckleton added the comment: Here's a patch including docstring and NEWS update for this backport. ---------- keywords: +patch nosy: +ryan.freckleton Added file: http://bugs.python.org/file9859/patch.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 01:55:19 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 26 Mar 2008 00:55:19 +0000 Subject: [issue2486] Consider using bytes type instead of str to store Decimal coefficients In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za> Message-ID: <1206492919.1.0.19244908487.issue2486@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's a first try at a patch that converts the Decimal coefficient from type str to type bytes. It needs some work: here are some timings for a complete run of the test suite (best of 3 in each case) on my MacBook. Python 3.0, str: 12.880s Python 3.0, bytes: 13.294s Python 2.6: 9.279s Python 2.5: 9.212s There's still some room for speedup with the bytes patch, but at the moment it doesn't look as though performance alone is a compelling reason to make this change. ---------- keywords: +patch Added file: http://bugs.python.org/file9860/decimal_bytes.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 02:12:39 2008 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 26 Mar 2008 01:12:39 +0000 Subject: [issue2487] ldexp(x,n) misbehaves when abs(n) is large In-Reply-To: <1206487537.98.0.104101200523.issue2487@psf.upfronthosting.co.za> Message-ID: <1206493959.08.0.688723018586.issue2487@psf.upfronthosting.co.za> Mark Dickinson added the comment: I agree that the second and fourth cases are bugs. The second case looks like a Windows only problem: I get the expected OverflowError on both OS X 10.5.2/Intel and SuSE Linux 10.2/i686. The fourth case is cross-platform, and occurs also for large exponents: >>> ldexp(1.234, maxint+1) Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int It's still present in Python 3.0. I'll take a look. ---------- versions: +Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 02:15:49 2008 From: report at bugs.python.org (Fergus Henderson) Date: Wed, 26 Mar 2008 01:15:49 +0000 Subject: [issue2489] Patch for bugs in pty.py In-Reply-To: <1206494149.11.0.607365562092.issue2489@psf.upfronthosting.co.za> Message-ID: <1206494149.11.0.607365562092.issue2489@psf.upfronthosting.co.za> New submission from Fergus Henderson : The attached patch fixes some bugs in the pty.py module: - spawn() would not wait for the invoked process to finish. Also, it did not return a meaningful value, so there was no way to tell if the invoked process failed. After this patch, spawn() now waits for the invoked process, and returns the value returned from os.waitpid(). - There was a bug in the _copy() loop that caused it to spin using 100% CPU rather than blocking after EOF was reached on one of the two file descriptors that it was waiting for. ---------- components: Library (Lib) files: pty.py.patch keywords: patch messages: 64533 nosy: fergushenderson severity: normal status: open title: Patch for bugs in pty.py type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9861/pty.py.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 02:22:33 2008 From: report at bugs.python.org (Guilherme Polo) Date: Wed, 26 Mar 2008 01:22:33 +0000 Subject: [issue2489] Patch for bugs in pty.py In-Reply-To: <1206494149.11.0.607365562092.issue2489@psf.upfronthosting.co.za> Message-ID: <1206494553.27.0.258683216404.issue2489@psf.upfronthosting.co.za> Guilherme Polo added the comment: Hi Fergus, I would suggest using "if not data" to check for EOF ---------- nosy: +gpolo __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 02:46:31 2008 From: report at bugs.python.org (Fergus Henderson) Date: Wed, 26 Mar 2008 01:46:31 +0000 Subject: [issue2489] Patch for bugs in pty.py In-Reply-To: <1206494553.27.0.258683216404.issue2489@psf.upfronthosting.co.za> Message-ID: Fergus Henderson added the comment: On Tue, Mar 25, 2008 at 9:22 PM, Guilherme Polo wrote: > > I would suggest using "if not data" to check for EOF Good idea. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 02:52:03 2008 From: report at bugs.python.org (Pierre Metras) Date: Wed, 26 Mar 2008 01:52:03 +0000 Subject: [issue2490] Assertion failure in datetime.strftime() In-Reply-To: <1206496323.11.0.616426584007.issue2490@psf.upfronthosting.co.za> Message-ID: <1206496323.11.0.616426584007.issue2490@psf.upfronthosting.co.za> New submission from Pierre Metras : datetime.strftime(pattern) fails in assertion if pattern is big enough (> 100 chars) while time.strftime(pattern) gives the expected result. This occurs on Python 2.5 (tested on OLPC XO laptop, Fedora 9). Python 2.4 (Debian Etch) does not exhibit this bug. ---------- components: Extension Modules files: test.py messages: 64536 nosy: genepi severity: normal status: open title: Assertion failure in datetime.strftime() versions: Python 2.5 Added file: http://bugs.python.org/file9862/test.py __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 03:09:52 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 26 Mar 2008 02:09:52 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za> Message-ID: <1206497392.57.0.156258590526.issue2459@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This new patch also updates the code generation for list comprehensions. Here are some micro-benchmarks: ./python -m timeit -s "l = range(100)" "[x for x in l]" Before: 100000 loops, best of 3: 14.9 usec per loop After: 100000 loops, best of 3: 12.5 usec per loop ./python -m timeit -s "l = range(100)" "[x for x in l if x]" Before: 10000 loops, best of 3: 24.1 usec per loop After: 100000 loops, best of 3: 18.8 usec per loop ./python -m timeit -s "l = range(100)" "[x for x in l if not x]" Before: 100000 loops, best of 3: 15.5 usec per loop After: 100000 loops, best of 3: 11.9 usec per loop Please note that this patch is orthogonal with Neal's patch in #2183, so the two combined should be quite interesting for the list comprehensions bytecode. Added file: http://bugs.python.org/file9863/loops5.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 03:30:02 2008 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 26 Mar 2008 02:30:02 +0000 Subject: [issue2486] Consider using bytes type instead of str to store Decimal coefficients In-Reply-To: <1206480975.35.0.923616350386.issue2486@psf.upfronthosting.co.za> Message-ID: <1206498602.5.0.887462878883.issue2486@psf.upfronthosting.co.za> Nick Coghlan added the comment: Hmm, I forgot there wasn't currently a direct path back from int -> bytes. I think your numbers *do* show that we need to do something about the performance of the Python 3.0 version of decimal. A 25% increase in runtime is a pretty big performance hit. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 03:34:15 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 26 Mar 2008 02:34:15 +0000 Subject: [issue2490] Assertion failure in datetime.strftime() In-Reply-To: <1206496323.11.0.616426584007.issue2490@psf.upfronthosting.co.za> Message-ID: <1206498855.31.0.584123344979.issue2490@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Can you give us an example of the data that caused the failure? ---------- nosy: +benjamin.peterson type: -> behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 05:24:19 2008 From: report at bugs.python.org (Neal Norwitz) Date: Wed, 26 Mar 2008 04:24:19 +0000 Subject: [issue2491] io.open() handles errors differently on different platforms In-Reply-To: <1206505459.01.0.185425865749.issue2491@psf.upfronthosting.co.za> Message-ID: <1206505459.01.0.185425865749.issue2491@psf.upfronthosting.co.za> New submission from Neal Norwitz : The attached file has a snapshot of the python.org homepage that was causing test_urllibnet to fail on some platforms (2 sparc, and ia64 at least), but not other platforms. This should be handled consistently. I don't know if there are really errors in the attached web page or not. The problem occurs at byte offset 13259: >>> data[13250:13270] 'r - Journ\xc3\xa9es Python' I suppose that's invalid for ASCII, but valid UTF-8. See r61921. There is a problem that the API for fdopen doesn't accept errors, encoding, etc. so it's problematic to handle this condition. ---------- components: Library (Lib) files: py-org.html messages: 64540 nosy: nnorwitz priority: critical severity: normal status: open title: io.open() handles errors differently on different platforms type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file9864/py-org.html __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 05:38:24 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 26 Mar 2008 04:38:24 +0000 Subject: [issue2484] Cosmetic patch for warning "unused variable" In-Reply-To: <1206464405.54.0.178616668761.issue2484@psf.upfronthosting.co.za> Message-ID: <1206506304.28.0.935572182414.issue2484@psf.upfronthosting.co.za> Hirokazu Yamamoto added the comment: I've confirmed trunk doesn't have this problem. Probably this is merge issue. r57928 changed the position of "int i,j" in py3k, but not changed in trunk, so when r61864 was merged into py3k some kind of conflict happened. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 07:37:02 2008 From: report at bugs.python.org (Gabriel Genellina) Date: Wed, 26 Mar 2008 06:37:02 +0000 Subject: [issue2483] int and float accept bytes, complex does not In-Reply-To: <1206462120.7.0.66925954466.issue2483@psf.upfronthosting.co.za> Message-ID: <1206513421.92.0.703000109012.issue2483@psf.upfronthosting.co.za> Gabriel Genellina added the comment: Are numbers so special to break the rules? why stopping here? what about other types that may want to accept ASCII bytes instead of characters? Isn't this like going back to the 2.x world? The protocol with embedded ASCII numbers isn't a very convincing case for me. One can read a binary integer in C using a single function call. In Python 2.X this can't be done in a single call, one has to use struct.unpack to decode the bytes read, and there was no complains that I know of. In 3.0 the same happens for ASCII numbers too, one will have to decode them first. The conversion may look like a stupid step, but it's as stupid as having to use struct.unpack to convert some bits to the *same* bits inside the integer object. Writing int(str(value,'ascii')) doesn't look so terrible. And one may argue that int(b'1234') should return 0x34333231 instead of 1234; b'1234' is the binary representation of 0x34333231 in little-endian format. ---------- nosy: +gagenellina __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 08:00:09 2008 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 26 Mar 2008 07:00:09 +0000 Subject: [issue2483] int and float accept bytes, complex does not In-Reply-To: <1206462120.7.0.66925954466.issue2483@psf.upfronthosting.co.za> Message-ID: <1206514809.7.0.0858039890526.issue2483@psf.upfronthosting.co.za> Nick Coghlan added the comment: Agreed - I've been convinced that the right thing to do is reject bytes in int() and float() as well. If we decide we still want to support a fast-path conversion it should be via separate methods (e.g an int.from_ascii class method and an int.to_ascii instance method). __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 08:15:25 2008 From: report at bugs.python.org (Georg Brandl) Date: Wed, 26 Mar 2008 07:15:25 +0000 Subject: [issue2488] Backport sys.maxsize to Python 2.6 In-Reply-To: <1206488150.94.0.908333325517.issue2488@psf.upfronthosting.co.za> Message-ID: <1206515725.48.0.0312462043968.issue2488@psf.upfronthosting.co.za> Georg Brandl added the comment: What about #1570? ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 08:51:46 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 26 Mar 2008 07:51:46 +0000 Subject: [issue2488] Backport sys.maxsize to Python 2.6 In-Reply-To: <1206488150.94.0.908333325517.issue2488@psf.upfronthosting.co.za> Message-ID: <1206517906.53.0.265226070184.issue2488@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I don't see how backports like this add any value at all. The 2- to-3 tool handles renaming well, but a backport just creates a hodge- podge of aliases making the language harder to learn and harder to grep. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 10:00:22 2008 From: report at bugs.python.org (Georg Brandl) Date: Wed, 26 Mar 2008 09:00:22 +0000 Subject: [issue2484] Cosmetic patch for warning "unused variable" In-Reply-To: <1206464405.54.0.178616668761.issue2484@psf.upfronthosting.co.za> Message-ID: <1206522022.16.0.236118073329.issue2484@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, fixed in r61927. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 10:01:30 2008 From: report at bugs.python.org (Georg Brandl) Date: Wed, 26 Mar 2008 09:01:30 +0000 Subject: [issue2457] add --help and -h options to pdb In-Reply-To: <1206214872.65.0.48935135608.issue2457@psf.upfronthosting.co.za> Message-ID: <1206522090.41.0.107766879271.issue2457@psf.upfronthosting.co.za> Georg Brandl added the comment: Go ahead and commit. ---------- resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 10:43:25 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 26 Mar 2008 09:43:25 +0000 Subject: [issue2491] io.open() handles errors differently on different platforms In-Reply-To: <1206505459.01.0.185425865749.issue2491@psf.upfronthosting.co.za> Message-ID: <1206524605.62.0.581662874692.issue2491@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: With python3.0, os.fdopen() is a simple call to io.open(), which has these missing options. Maybe os.fdopen should be deprecated or removed, and replaced by io.open. Moreover, the comment in os.py is wrong: subprocess does not use fdopen any more, but io.open instead. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 12:40:34 2008 From: report at bugs.python.org (Pierre Metras) Date: Wed, 26 Mar 2008 11:40:34 +0000 Subject: [issue2490] Assertion failure in datetime.strftime() In-Reply-To: <1206496323.11.0.616426584007.issue2490@psf.upfronthosting.co.za> Message-ID: <1206531634.58.0.573622033993.issue2490@psf.upfronthosting.co.za> Pierre Metras added the comment: There is an example of a long strftime pattern in the test.py file attached to that issue. Just change the length of the pattern to see that it works for smaller patterns in Python 2.5. The pattern where it occured in my application is a Pango markup string used for localization: "%H:%M:%S" __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 12:53:57 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 26 Mar 2008 11:53:57 +0000 Subject: [issue2492] Check implementation of new buffer interface for PyString in 2.6 In-Reply-To: <1206532437.27.0.353832301396.issue2492@psf.upfronthosting.co.za> Message-ID: <1206532437.27.0.353832301396.issue2492@psf.upfronthosting.co.za> New submission from Christian Heimes : I've only implemented (getbufferproc)string_buffer_getbuffer of the new buffer protocol. Do I have to add "exports" to the PyString struct and add a releasebufferproc, too? ---------- components: Interpreter Core keywords: 26backport messages: 64550 nosy: tiran priority: high severity: normal status: open title: Check implementation of new buffer interface for PyString in 2.6 type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 12:55:39 2008 From: report at bugs.python.org (Christian Heimes) Date: Wed, 26 Mar 2008 11:55:39 +0000 Subject: [issue2492] Check implementation of new buffer interface for PyString in 2.6 In-Reply-To: <1206532437.27.0.353832301396.issue2492@psf.upfronthosting.co.za> Message-ID: <1206532539.92.0.843573257786.issue2492@psf.upfronthosting.co.za> Christian Heimes added the comment: By the way the code is in svn+ssh://pythondev at svn.python.org/python/branches/trunk-bytearray ---------- nosy: +teoliphant __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 12:58:26 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 26 Mar 2008 11:58:26 +0000 Subject: [issue2457] add --help and -h options to pdb In-Reply-To: <1206214872.65.0.48935135608.issue2457@psf.upfronthosting.co.za> Message-ID: <1206532706.02.0.715799869401.issue2457@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Committed in r61931. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 13:25:01 2008 From: report at bugs.python.org (Georg Brandl) Date: Wed, 26 Mar 2008 12:25:01 +0000 Subject: [issue2490] Assertion failure in datetime.strftime() In-Reply-To: <1206496323.11.0.616426584007.issue2490@psf.upfronthosting.co.za> Message-ID: <1206534301.54.0.760628031419.issue2490@psf.upfronthosting.co.za> Georg Brandl added the comment: I cannot reproduce this with test.py with Python 2.5.1 on x86 Linux. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 14:35:07 2008 From: report at bugs.python.org (Lorenz Quack) Date: Wed, 26 Mar 2008 13:35:07 +0000 Subject: [issue2250] rlcompleter raises Exception on bad input In-Reply-To: <1204886997.65.0.75088007868.issue2250@psf.upfronthosting.co.za> Message-ID: <1206538507.14.0.319305147329.issue2250@psf.upfronthosting.co.za> Lorenz Quack added the comment: I was thinking that the code in question could maybe also raise other exceptions. too bad I?m on vacation and can?t try this out myself. I believe the regular expression also matches something like import rlcompleter rlcompleter.Completer().complete("1foo.2bar3.smth", 0) which I guess would result in a SyntaxError. would be nice if someone could verify that. If I?m right I see two possibilities. either change the regular expression to match only valid python identifieres or also catch SyntaxErrors. could there be any other exception? ("In the face of ambiguity, refuse the temptation to guess.") __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 14:53:14 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 26 Mar 2008 13:53:14 +0000 Subject: [issue1561] py3k: test_mailbox fails on Windows In-Reply-To: <1196937492.24.0.0620025474702.issue1561@psf.upfronthosting.co.za> Message-ID: <1206539594.0.0.46347168069.issue1561@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Three months later, one obvious correction: open all (text) files with the newline='\n' option. - This makes files identical between Unix and Windows version - no more os.linesep A compatibility problem: mailboxes created with python2.6 cannot be opened with 3.0 ---------- keywords: +patch Added file: http://bugs.python.org/file9865/mailbox.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 14:58:07 2008 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Wed, 26 Mar 2008 13:58:07 +0000 Subject: [issue2479] Bytearray and io backport In-Reply-To: <1206443150.97.0.809624584179.issue2479@psf.upfronthosting.co.za> Message-ID: <1206539887.72.0.590776951955.issue2479@psf.upfronthosting.co.za> Quentin Gallet-Gilles added the comment: I've just updated my trunk checkout on Ubuntu and run the regression test suite. All tests OK. ---------- nosy: +quentin.gallet-gilles __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 15:06:20 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 26 Mar 2008 14:06:20 +0000 Subject: [issue1561] py3k: test_mailbox fails on Windows In-Reply-To: <1196937492.24.0.0620025474702.issue1561@psf.upfronthosting.co.za> Message-ID: <1206540380.08.0.467235941466.issue1561@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Another patch, which uses newline='' instead. Tests pass. The patch is much smaller, and old files are more likely to be compatible. OTOH, messages are unicode strings with \r\n. Which one do you prefer? Added file: http://bugs.python.org/file9866/mailbox2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 15:15:20 2008 From: report at bugs.python.org (Quentin Gallet-Gilles) Date: Wed, 26 Mar 2008 14:15:20 +0000 Subject: [issue2402] get rid of warnings in regrtest with -3 Message-ID: <1206540920.13.0.899945162633.issue2402@psf.upfronthosting.co.za> Changes by Quentin Gallet-Gilles : ---------- nosy: +quentin.gallet-gilles __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 15:47:35 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 26 Mar 2008 14:47:35 +0000 Subject: [issue2493] Remove unused constants from optimized code objects In-Reply-To: <1206542855.67.0.168475253552.issue2493@psf.upfronthosting.co.za> Message-ID: <1206542855.67.0.168475253552.issue2493@psf.upfronthosting.co.za> New submission from Alexander Belopolsky : When peephole optimizer folds multiple constants into one, the old constants remain in co_consts. Attached patch removes such unused constants. ---------- components: Interpreter Core files: compress-consts.diff keywords: patch messages: 64558 nosy: belopolsky severity: normal status: open title: Remove unused constants from optimized code objects type: resource usage versions: Python 2.6 Added file: http://bugs.python.org/file9867/compress-consts.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 15:47:43 2008 From: report at bugs.python.org (Pierre Metras) Date: Wed, 26 Mar 2008 14:47:43 +0000 Subject: [issue2490] Assertion failure in datetime.strftime() In-Reply-To: <1206496323.11.0.616426584007.issue2490@psf.upfronthosting.co.za> Message-ID: <1206542863.32.0.213596558142.issue2490@psf.upfronthosting.co.za> Pierre Metras added the comment: I did a mistake: OLPC XO is based on Fedora 7 and not 9. They plan to upgrade to 9 later this year (http://wiki.laptop.org/go/Fedora), so this bug will disappear by itself if it's confirmed that test.py runs correctly on Python 2.5.x and Fedora 9 ships with the latest version. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 16:06:16 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 26 Mar 2008 15:06:16 +0000 Subject: [issue2493] Remove unused constants from optimized code objects In-Reply-To: <1206542855.67.0.168475253552.issue2493@psf.upfronthosting.co.za> Message-ID: <1206543976.06.0.884471645995.issue2493@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 15:55:43 2008 From: report at bugs.python.org (ghorvath) Date: Wed, 26 Mar 2008 14:55:43 +0000 Subject: [issue1222721] tk + setlocale problems... Message-ID: <1206543343.72.0.199354860388.issue1222721@psf.upfronthosting.co.za> ghorvath added the comment: I can confirm that this bug is still present. After locale.setlocale(locale.LC_ALL, '') Backspace in Tkinter.Entry is not working anymore. There is no difference if the Backspace is issued by the keyboard or by self.master.winfo_toplevel().event_generate('') No messages are written. Tested on Linux (Ubuntu Gutsy)/Python 2.5.1 and Windows XP/Python 2.4.3 ---------- nosy: +ghorvath versions: +Python 2.5 _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Mar 26 16:31:26 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 26 Mar 2008 15:31:26 +0000 Subject: [issue2493] Remove unused constants from optimized code objects In-Reply-To: <1206542855.67.0.168475253552.issue2493@psf.upfronthosting.co.za> Message-ID: <1206545486.61.0.188083191617.issue2493@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I've noticed that the original patch does not handle the error condition from failed consts resize correctly. Please see compress-consts-1.diff for a fix. Added file: http://bugs.python.org/file9868/compress-consts-1.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 16:36:54 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 26 Mar 2008 15:36:54 +0000 Subject: [issue1518] Fast globals/builtins access (patch) In-Reply-To: <1196329437.66.0.0945045609125.issue1518@psf.upfronthosting.co.za> Message-ID: <1206545814.27.0.652175238161.issue1518@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 17:51:42 2008 From: report at bugs.python.org (ghorvath) Date: Wed, 26 Mar 2008 16:51:42 +0000 Subject: [issue1222721] tk + setlocale problems... Message-ID: <1206550302.83.0.108869870955.issue1222721@psf.upfronthosting.co.za> ghorvath added the comment: Attached a workaround for this problem, based on: http://ml.osdir.com/games.mud.client.lyntin/2005-03/msg00005.html I also found that the problem only appears when the LC_NUMERIC setting is different to en_US. (for example if it is de_AT) Added file: http://bugs.python.org/file9869/tksetlocalebug.py _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Mar 26 19:03:29 2008 From: report at bugs.python.org (Georg Brandl) Date: Wed, 26 Mar 2008 18:03:29 +0000 Subject: [issue2490] Assertion failure in datetime.strftime() In-Reply-To: <1206496323.11.0.616426584007.issue2490@psf.upfronthosting.co.za> Message-ID: <1206554609.57.0.235787428402.issue2490@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, closing as out of date. ---------- resolution: -> out of date status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 19:10:05 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 26 Mar 2008 18:10:05 +0000 Subject: [issue2268] Fold slice constants In-Reply-To: <1205176357.46.0.777488164944.issue2268@psf.upfronthosting.co.za> Message-ID: <1206555005.63.0.250372139205.issue2268@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Just to quantify the improvement: Before: $ ./python -m timeit -s"x='abc'" "x[::-1]" 1000000 loops, best of 3: 0.305 usec per loop $ ./python -O -m timeit -s"x='abc'" "x[::-1]" 1000000 loops, best of 3: 0.275 usec per loop After: $ ./python -m timeit -s"x='abc'" "x[::-1]" 1000000 loops, best of 3: 0.262 usec per loop $ ./python -O -m timeit -s"x='abc'" "x[::-1]" 1000000 loops, best of 3: 0.253 usec per loop For some reason, when I run pybench, the timings vary from run to run so much that I cannot even tell the difference. (Run to run differences are larger than patched to original.) FWIW, the micro-benchmark above shows 8% improvement with "-O" and 14% improvement without. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 19:16:18 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Wed, 26 Mar 2008 18:16:18 +0000 Subject: [issue1413192] bsddb: segfault on db.associate call with Txn and large data Message-ID: <1206555378.69.0.627145904456.issue1413192@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _____________________________________ Tracker _____________________________________ From report at bugs.python.org Wed Mar 26 21:46:01 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 26 Mar 2008 20:46:01 +0000 Subject: [issue2458] Allow Python code to change Py3k warning flag In-Reply-To: <1206221345.67.0.966605700107.issue2458@psf.upfronthosting.co.za> Message-ID: <1206564361.69.0.21680017907.issue2458@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Raising priority so this is looked at before we release 2.6. :) ---------- priority: -> critical __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 22:25:12 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Wed, 26 Mar 2008 21:25:12 +0000 Subject: [issue1503] test_xmlrpc is still flakey In-Reply-To: <1196126599.89.0.0637627606597.issue1503@psf.upfronthosting.co.za> Message-ID: <1206566712.47.0.22579169592.issue1503@psf.upfronthosting.co.za> Ralf Schmitt added the comment: The current buildbot has errors similar to this one (I assume): Exception happened during processing of request from ('127.0.0.1', 53126) Traceback (most recent call last): File "/Users/ralf/trunk/Lib/SocketServer.py", line 281, in _handle_request_noblock self.process_request(request, client_address) File "/Users/ralf/trunk/Lib/SocketServer.py", line 307, in process_request self.finish_request(request, client_address) File "/Users/ralf/trunk/Lib/SocketServer.py", line 320, in finish_request self.RequestHandlerClass(request, client_address, self) File "/Users/ralf/trunk/Lib/SocketServer.py", line 615, in __init__ self.handle() File "/Users/ralf/trunk/Lib/BaseHTTPServer.py", line 318, in handle self.handle_one_request() File "/Users/ralf/trunk/Lib/BaseHTTPServer.py", line 301, in handle_one_request self.raw_requestline = self.rfile.readline() File "/Users/ralf/trunk/Lib/socket.py", line 369, in readline data = self._sock.recv(self._rbufsize) error: [Errno 35] Resource temporarily unavailable ---------------------------------------- The problem is that the test calls serv.socket.settimeout(3) in the http_server function. This implicitly sets the server socket to nonblocking state. The accept call then returns a socket object, which - is blocking on OS X 10.4 ppc - is nonblocking on linux I can easily reproduce that on my mac mini g4 with python 2.6. ---------- nosy: +schmir versions: +Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 23:01:33 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Wed, 26 Mar 2008 22:01:33 +0000 Subject: [issue1503] test_xmlrpc is still flakey In-Reply-To: <1196126599.89.0.0637627606597.issue1503@psf.upfronthosting.co.za> Message-ID: <1206568893.59.0.946561197925.issue1503@psf.upfronthosting.co.za> Ralf Schmitt added the comment: I just double checked with the following program: #! /usr/bin/env python import os import fcntl import socket def isnonblocking(fd): return bool(fcntl.fcntl(fd, fcntl.F_GETFL, 0) & os.O_NONBLOCK) def main(): s=socket.socket() s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind(("0.0.0.0", 8000)) s.listen(5) s.settimeout(30) print "server isnonblocking:", isnonblocking(s.fileno()) client, addr = s.accept() print "client isnonblocking:", isnonblocking(client.fileno()) if __name__=="__main__": main() on my g4 mac it prints: ~/ python serv.py ralf at mini ok server isnonblocking: True client isnonblocking: True on linux: ~/ python mini/serv.py ralf at rat64 ok server isnonblocking: True client isnonblocking: False __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 23:08:44 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Wed, 26 Mar 2008 22:08:44 +0000 Subject: [issue1503] test_xmlrpc is still flakey In-Reply-To: <1196126599.89.0.0637627606597.issue1503@psf.upfronthosting.co.za> Message-ID: <1206569324.54.0.635683085274.issue1503@psf.upfronthosting.co.za> Ralf Schmitt added the comment: now that I see that the buildbot was running on ppc *Debian* I'm not quite sure if we're talking about the same issue. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 23:10:06 2008 From: report at bugs.python.org (Alan McIntyre) Date: Wed, 26 Mar 2008 22:10:06 +0000 Subject: [issue1503] test_xmlrpc is still flakey In-Reply-To: <1196126599.89.0.0637627606597.issue1503@psf.upfronthosting.co.za> Message-ID: <1206569406.74.0.926900455348.issue1503@psf.upfronthosting.co.za> Alan McIntyre added the comment: It's my fault the xmlrpc tests try to use non-blocking sockets. That got added because sometimes failing tests would just sit there with the server blocking until the entire test process got killed for running too long. There are some tests that are skipped in test_xmlrpc because of (apparent) Windows socket quirks; should they also be skipped for OS X PPC, or should the flaky tests just be scrapped? When I was last working on this I couldn't come up with a better way to run these tests, so unless somebody can suggest a new approach I'm just left with recommending the skip & scrap options as the only way to stop the flakiness. ---------- nosy: +alanmcintyre __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 23:18:17 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Wed, 26 Mar 2008 22:18:17 +0000 Subject: [issue1503] test_xmlrpc is still flakey In-Reply-To: <1196126599.89.0.0637627606597.issue1503@psf.upfronthosting.co.za> Message-ID: <1206569897.51.0.868885885134.issue1503@psf.upfronthosting.co.za> Ralf Schmitt added the comment: No, please do not disable them. I'm not quite sure what to do, but apparently these sockets returned from accept should be turned into blocking sockets. I just do not know, where this should happen. I think that this could even be done inside the accept call (which then might break some code). At least it should be done in the BaseHTTPServer code, which apparently cannot handle nonblocking sockets. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 26 23:54:24 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Wed, 26 Mar 2008 22:54:24 +0000 Subject: [issue1503] test_xmlrpc is still flakey In-Reply-To: <1196126599.89.0.0637627606597.issue1503@psf.upfronthosting.co.za> Message-ID: <1206572064.19.0.943747618269.issue1503@psf.upfronthosting.co.za> Ralf Schmitt added the comment: With the following diff, test_xmlrpc.py passes without problems. Like I said, someone else should decide where to turn on blocking mode. I now think that it should be in the socket.accept (i.e. in the C code) at least for unix platforms. Those who really want a nonblocking socket, will most probably call that setblocking(0) anyway (or their program is broken on linux, which returns blocking sockets by default). --- a/Lib/SocketServer.py Wed Mar 26 22:41:36 2008 +0100 +++ b/Lib/SocketServer.py Wed Mar 26 23:48:13 2008 +0100 @@ -441,8 +441,10 @@ May be overridden. """ - return self.socket.accept() - + r= self.socket.accept() + r[0].setblocking(1) + return r + def close_request(self, request): """Called to clean up an individual request.""" request.close() __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 00:09:32 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 26 Mar 2008 23:09:32 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za> Message-ID: <1206572972.64.0.591363840229.issue2459@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This new patch completes the bytecode modifications. For/while loops as well as list comprehensions and generator expressions are a bit faster now. Also, as a side effect I've introduced a speed improvement for "if" statements and expressions... Some micro-benchmarks (completing the ones already given above): ./python Tools/pybench/pybench.py -t IfThenElse Before: 167ms per round After: 136ms per round ./python -m timeit -s "y=range(100)" "sum(x for x in y)" Before: 10000 loops, best of 3: 20.4 usec per loop After: 100000 loops, best of 3: 17.9 usec per loop ./python -m timeit -s "y=range(100)" "sum(x for x in y if x)" Before: 10000 loops, best of 3: 28.5 usec per loop After: 10000 loops, best of 3: 23.3 usec per loop ./python -m timeit -s "y=range(100)" "sum(x for x in y if not x)" Before: 100000 loops, best of 3: 16.4 usec per loop After: 100000 loops, best of 3: 12.1 usec per loop ./python -m timeit -s "x,y,z=1,2,3" "x if y else z" Before: 1000000 loops, best of 3: 0.218 usec per loop After: 10000000 loops, best of 3: 0.159 usec per loop A couple of tests seem to be failing in obscure ways in the test suite, I'll try to examine them. Most of the test suite runs fine though. Added file: http://bugs.python.org/file9870/loops6.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 00:43:07 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 26 Mar 2008 23:43:07 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za> Message-ID: <1206574987.42.0.892258246789.issue2459@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, the fix for the bizarre failures was really simple. Now the only failing tests are in test_trace (because it makes assumptions regarding the bytecode that aren't true anymore, I'll have to adapt the tests). Added file: http://bugs.python.org/file9871/loops7.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 01:43:16 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 27 Mar 2008 00:43:16 +0000 Subject: [issue2487] ldexp(x,n) misbehaves when abs(n) is large In-Reply-To: <1206487537.98.0.104101200523.issue2487@psf.upfronthosting.co.za> Message-ID: <1206578596.92.0.378198420438.issue2487@psf.upfronthosting.co.za> Mark Dickinson added the comment: There are similar problems with integer shifts. In the trunk: >>> 1>>(2**40) Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int and in Python 3.0: >>> 1>>(2**40) Traceback (most recent call last): File "", line 1, in OverflowError: Python int too large to convert to C long These should probably by fixed, too, though at least the error message is clear. What should 1<<(2**31) do? __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 02:21:52 2008 From: report at bugs.python.org (James Henstridge) Date: Thu, 27 Mar 2008 01:21:52 +0000 Subject: [issue2422] Automatically disable pymalloc when running under valgrind In-Reply-To: <1205925069.41.0.603933745456.issue2422@psf.upfronthosting.co.za> Message-ID: <1206580911.96.0.118222917915.issue2422@psf.upfronthosting.co.za> James Henstridge added the comment: An updated version of the patch. The previous ones were missing the valgrind check, resulting in the pymalloc code paths being executed (which in turn cause unintialised read warnings from valgrind). Added file: http://bugs.python.org/file9872/disable-pymalloc-on-valgrind-py26.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 03:12:49 2008 From: report at bugs.python.org (Eric Huss) Date: Thu, 27 Mar 2008 02:12:49 +0000 Subject: [issue1622] zipfile hangs on certain zip files In-Reply-To: <1205808592.99.0.293079394702.issue1622@psf.upfronthosting.co.za> Message-ID: Eric Huss added the comment: Sorry for the long delay. Yes, the latest patch looks very good to me. -Eric __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 06:04:33 2008 From: report at bugs.python.org (Neal Norwitz) Date: Thu, 27 Mar 2008 05:04:33 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za> Message-ID: <1206594273.76.0.124077928092.issue2459@psf.upfronthosting.co.za> Neal Norwitz added the comment: Antoine, I hope to look at this patch eventually. Unfortunately, there are too many build/test problems that need to be resolved before the next release. If you can help out with those, I will be able to review this patch sooner. ---------- nosy: +nnorwitz __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 06:27:16 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 27 Mar 2008 05:27:16 +0000 Subject: [issue2065] trunk version does not compile with vs8 and vc6 In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za> Message-ID: <1206595636.69.0.758761569074.issue2065@psf.upfronthosting.co.za> Changes by Hirokazu Yamamoto : Removed file: http://bugs.python.org/file9424/ocean.zip __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 06:27:32 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 27 Mar 2008 05:27:32 +0000 Subject: [issue2065] trunk version does not compile with vs8 and vc6 In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za> Message-ID: <1206595652.62.0.575182754416.issue2065@psf.upfronthosting.co.za> Changes by Hirokazu Yamamoto : Removed file: http://bugs.python.org/file9456/ocean.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 06:27:42 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 27 Mar 2008 05:27:42 +0000 Subject: [issue2065] trunk version does not compile with vs8 and vc6 In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za> Message-ID: <1206595662.66.0.62218176373.issue2065@psf.upfronthosting.co.za> Changes by Hirokazu Yamamoto : Removed file: http://bugs.python.org/file9577/ocean.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 06:29:21 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 27 Mar 2008 05:29:21 +0000 Subject: [issue2065] trunk version does not compile with vs8 and vc6 In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za> Message-ID: <1206595761.39.0.728726760097.issue2065@psf.upfronthosting.co.za> Changes by Hirokazu Yamamoto : Removed file: http://bugs.python.org/file9595/ocean.zip __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 06:30:37 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Thu, 27 Mar 2008 05:30:37 +0000 Subject: [issue2065] trunk version does not compile with vs8 and vc6 In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za> Message-ID: <1206595837.37.0.728230366158.issue2065@psf.upfronthosting.co.za> Changes by Hirokazu Yamamoto : Added file: http://bugs.python.org/file9873/ocean.zip __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 08:03:19 2008 From: report at bugs.python.org (P. Henrique Silva) Date: Thu, 27 Mar 2008 07:03:19 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za> Message-ID: <1206601399.87.0.143768580602.issue2459@psf.upfronthosting.co.za> Changes by P. Henrique Silva : ---------- nosy: +phsilva __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 08:27:07 2008 From: report at bugs.python.org (Mark Summerfield) Date: Thu, 27 Mar 2008 07:27:07 +0000 Subject: [issue2494] Can't round-trip datetimes<->timestamps prior to 1970 on Windows In-Reply-To: <1206602826.96.0.687530064019.issue2494@psf.upfronthosting.co.za> Message-ID: <1206602826.96.0.687530064019.issue2494@psf.upfronthosting.co.za> New submission from Mark Summerfield : # If you run the code below on Py30a3 you get the output shown at the end import calendar, datetime, time pastdate = datetime.datetime(1969, 12, 31) print(pastdate) timestamp = calendar.timegm(pastdate.utctimetuple()) print(timestamp) try: pastdate_x = datetime.datetime.utcfromtimestamp(timestamp) except ValueError as err: print("FAIL", err) try: print(time.strftime("%Y-%m-%dT%H:%M:%S", time.gmtime(timestamp))) except ValueError as err: print("FAIL", err) r""" Python 30a3 Windows output: 1969-12-31 00:00:00 -86400 FAIL timestamp out of range for platform localtime()/gmtime() function FAIL (22, 'Invalid argument') Linux output: 1969-12-31 00:00:00 -86400 1969-12-31T00:00:00 """ # What this appears to show is that you can't round-trip between datetimes and timestamps on Windows for dates prior to 1970 ---------- components: Library (Lib) messages: 64578 nosy: mark severity: normal status: open title: Can't round-trip datetimes<->timestamps prior to 1970 on Windows type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 12:00:09 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 27 Mar 2008 11:00:09 +0000 Subject: [issue815646] thread unsafe file objects cause crash Message-ID: <1206615609.29.0.62744493335.issue815646@psf.upfronthosting.co.za> Antoine Pitrou added the comment: A small addition to Christian's code snippet allows me to reproduce the problem as well: import thread f=open("tmp1", "w") def worker(): global f while 1: f.close() f = open("tmp1", "w") f.seek(0,0) thread.start_new_thread(worker, ()) thread.start_new_thread(worker, ()) while 1: pass ---------- nosy: +pitrou ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Mar 27 12:22:30 2008 From: report at bugs.python.org (Guilherme Polo) Date: Thu, 27 Mar 2008 11:22:30 +0000 Subject: [issue2406] Improvement suggestions for the gzip module documentation In-Reply-To: <1205872183.57.0.209526870399.issue2406@psf.upfronthosting.co.za> Message-ID: <1206616950.84.0.432746752664.issue2406@psf.upfronthosting.co.za> Guilherme Polo added the comment: Hello, (some comments) What about using gzip.open instead of GzipFile ? It is just a shorthand, but I prefer it (just my opinion). Also, remove those semicolons. At the second example you called close on the string object, I guess you intended to do file_obj.close() In the third example you used "file", please change that to "open". In this sample example, you don't need to use shutil. I suggest changing it to: import gzip f_in = open('/home/joe/file.txt', 'rb') f_out = gzip.open('/home/joe/file.txt.gz', 'wb'); f_out.writelines(f_in) file_obj_out.close() f_out.close() Finally, consider doing these changes against Doc/library/gzip.rst and sending the diff ---------- nosy: +gpolo __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 12:37:08 2008 From: report at bugs.python.org (Thomas Guettler) Date: Thu, 27 Mar 2008 11:37:08 +0000 Subject: [issue1555570] email parser incorrectly breaks headers with a CRLF at 8192 Message-ID: <1206617828.69.0.586330722558.issue1555570@psf.upfronthosting.co.za> Thomas Guettler added the comment: I was hit by this bug in Django. The ticket URL: http://code.djangoproject.com/ticket/6256 It would be nice if this could be fixed. ---------- nosy: +guettli _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 27 13:04:35 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 27 Mar 2008 12:04:35 +0000 Subject: [issue2496] test_no_refcycle_through_target sometimes fails in test_threading In-Reply-To: <1206619475.61.0.0373454947155.issue2496@psf.upfronthosting.co.za> Message-ID: <1206619475.61.0.0373454947155.issue2496@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This is a reminder for the failing test which is affecting some buildbots. I can't reproduce it right now (under Linux), even by surrounding the test code with a pair of gc.disable() / gc.enable(). ---------- components: Library (Lib) messages: 64584 nosy: nnorwitz, pitrou severity: normal status: open title: test_no_refcycle_through_target sometimes fails in test_threading type: behavior versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 12:50:03 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 27 Mar 2008 11:50:03 +0000 Subject: [issue2495] tokenize doesn't handle __future__.unicode_literals correctly In-Reply-To: <1206618603.55.0.554342479222.issue2495@psf.upfronthosting.co.za> Message-ID: <1206618603.55.0.554342479222.issue2495@psf.upfronthosting.co.za> New submission from Christian Heimes : See r61976 Clear the blacklist and run the test with ./python Lib/test/regrtest.py -uall test_tokenize to reproduce the issue. ---------- components: Library (Lib) messages: 64582 nosy: tiran priority: normal severity: normal status: open title: tokenize doesn't handle __future__.unicode_literals correctly versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 12:50:53 2008 From: report at bugs.python.org (Christian Heimes) Date: Thu, 27 Mar 2008 11:50:53 +0000 Subject: [issue2494] Can't round-trip datetimes<->timestamps prior to 1970 on Windows In-Reply-To: <1206602826.96.0.687530064019.issue2494@psf.upfronthosting.co.za> Message-ID: <1206618653.38.0.28642630032.issue2494@psf.upfronthosting.co.za> Christian Heimes added the comment: It's most likely a platform limitation. Some platforms doen't support negative time stamps. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 13:28:03 2008 From: report at bugs.python.org (Facundo Batista) Date: Thu, 27 Mar 2008 12:28:03 +0000 Subject: [issue2451] No way to disable socket timeouts in httplib, etc. In-Reply-To: <1206141378.11.0.857343736887.issue2451@psf.upfronthosting.co.za> Message-ID: <1206620883.54.0.640720911987.issue2451@psf.upfronthosting.co.za> Facundo Batista added the comment: Mmm.... it seems that not only overlooked this final agreement, but also forgot it! Bloody brain, :( I'll happily review any proposed patch for this. Alan, maybe you can be persuaded to submit one? <.5 wink> ---------- resolution: wont fix -> status: closed -> open __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 13:36:01 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 27 Mar 2008 12:36:01 +0000 Subject: [issue2496] test_no_refcycle_through_target sometimes fails in test_threading In-Reply-To: <1206619475.61.0.0373454947155.issue2496@psf.upfronthosting.co.za> Message-ID: <1206621361.26.0.646798461069.issue2496@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is a tentative patch. I can't verify it fixes anything but at least it shouldn't do any harm ;) If it doesn't fix it I see two possible explanations: - the buildbots are running some kind of debug build which keeps references to local variables, preventing them to be deallocated - the C thread implementation needs fixing on some platforms ---------- keywords: +patch Added file: http://bugs.python.org/file9874/test_threading.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 13:59:55 2008 From: report at bugs.python.org (M.-A. DARCHE) Date: Thu, 27 Mar 2008 12:59:55 +0000 Subject: [issue2406] Improvement suggestions for the gzip module documentation In-Reply-To: <1205872183.57.0.209526870399.issue2406@psf.upfronthosting.co.za> Message-ID: <1206622795.18.0.565846517724.issue2406@psf.upfronthosting.co.za> M.-A. DARCHE added the comment: Thanks Guilherme (I hope Guilherme is your first name) for your very constructive answer. I'll do exactly as you suggest. Regards __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 14:05:28 2008 From: report at bugs.python.org (Rolland Dudemaine) Date: Thu, 27 Mar 2008 13:05:28 +0000 Subject: [issue2443] uninitialized access to va_list In-Reply-To: <1206095258.5.0.538024401904.issue2443@psf.upfronthosting.co.za> Message-ID: <1206623128.69.0.14405724875.issue2443@psf.upfronthosting.co.za> Rolland Dudemaine added the comment: Actually, this thing is more complex to solve than I thought. Specifically, as described in http://www.opengroup.org/onlinepubs/007908775/xsh/stdarg.h.html stdarg requires that variable argument functions have at least one fixed argument. This is implied by the declaration of "void va_start(va_list ap, argN);". As explained in the original ticket description, and also described before in the above link, va_start() must be called before any call to va_arg(), and this includes any access to the argument list using __va_copy namely. The problem is that at least objargs_mktuple(), line 2649 of Objects/abstract.c does not have a first fixed argument. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 14:17:24 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 27 Mar 2008 13:17:24 +0000 Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za> Message-ID: <1206623844.34.0.779610001594.issue2375@psf.upfronthosting.co.za> Georg Brandl added the comment: I even run modules compiled for Python 2.2 successfully on 2.5... ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 14:19:29 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 27 Mar 2008 13:19:29 +0000 Subject: [issue1261390] import dynamic library bug? Message-ID: <1206623969.09.0.991457069819.issue1261390@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 27 14:21:30 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 27 Mar 2008 13:21:30 +0000 Subject: [issue812750] OSA support for properties broken Message-ID: <1206624090.54.0.00971157026027.issue812750@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- priority: high -> low ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Mar 27 14:27:49 2008 From: report at bugs.python.org (Georg Brandl) Date: Thu, 27 Mar 2008 13:27:49 +0000 Subject: [issue2248] quit() method of SMTP instance (of smtplib) doesn't return it's result In-Reply-To: <1204875778.72.0.769426067571.issue2248@psf.upfronthosting.co.za> Message-ID: <1206624469.0.0.243005996373.issue2248@psf.upfronthosting.co.za> Georg Brandl added the comment: Added docs and committed as r61977. ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 15:05:19 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 27 Mar 2008 14:05:19 +0000 Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za> Message-ID: <1206626719.9.0.931395217388.issue2375@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I have never had a problem of different python versions coexisting on the same machine, but having 32-bit and 64-bit python coexist is much harder. Particularly when 32-bit python is compiled on the 64-bit OS (using -m32 flag). There is a related issue1294959 highlighting this problem. See also issue1536339, issue1553166, and issue858809. Ideally, I would like to see a mechanism that would allow both standard library and user modules to share machine independent (*.py{,c,o}) files while having separate locations for 32-bit and 64-bit C modules. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 15:11:18 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 27 Mar 2008 14:11:18 +0000 Subject: [issue1294959] Problems with /usr/lib64 builds. Message-ID: <1206627078.05.0.994036053757.issue1294959@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Can someone update the priority so that this is looked at before the 2.6 release? ---------- nosy: +belopolsky _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 27 15:31:03 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 27 Mar 2008 14:31:03 +0000 Subject: [issue1294959] Problems with /usr/lib64 builds. Message-ID: <1206628263.1.0.583069497258.issue1294959@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Placing the entire library tree in /usr/lib64 is wasteful on dual 32/64bit installation, but placing just the C modules there is contrary to python import logic and may cause problems to relative imports. I have suggested what I believed was a workable solution: have 64-bit python search lib64-dynload subdirectories instead of lib-dynload. See http://mail.python.org/pipermail/python-dev/2007-April/072653.html Currently $(prefix)/pythonX.Y/lib-dynload is inserted in the sys.path, but I think it would be better to handle this inside the importer in a way similar to how the importer looks for both foo.so and foomodule.so when importing foo. This would allow submodules and user modules treated the same way. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Mar 27 15:37:12 2008 From: report at bugs.python.org (Rolland Dudemaine) Date: Thu, 27 Mar 2008 14:37:12 +0000 Subject: [issue2497] stdbool support In-Reply-To: <1206628632.31.0.556646353118.issue2497@psf.upfronthosting.co.za> Message-ID: <1206628632.31.0.556646353118.issue2497@psf.upfronthosting.co.za> New submission from Rolland Dudemaine : For better portability, it is good to support stdbool.h when it exists. This prevents a potential issue when compiling asdl.c. Patch attached. ---------- components: Build files: python_stdbool_20080327.diff keywords: patch messages: 64594 nosy: rolland severity: normal status: open title: stdbool support versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9875/python_stdbool_20080327.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 15:37:19 2008 From: report at bugs.python.org (Rolland Dudemaine) Date: Thu, 27 Mar 2008 14:37:19 +0000 Subject: [issue2497] stdbool support In-Reply-To: <1206628632.31.0.556646353118.issue2497@psf.upfronthosting.co.za> Message-ID: <1206628639.33.0.689028131098.issue2497@psf.upfronthosting.co.za> Changes by Rolland Dudemaine : ---------- type: -> compile error __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 16:19:38 2008 From: report at bugs.python.org (Jean-Philippe Laverdure) Date: Thu, 27 Mar 2008 15:19:38 +0000 Subject: [issue2078] CSV Sniffer does not function properly on single column .csv files In-Reply-To: <1202832132.24.0.528453630912.issue2078@psf.upfronthosting.co.za> Message-ID: <1206631178.71.0.893907928342.issue2078@psf.upfronthosting.co.za> Jean-Philippe Laverdure added the comment: Hello and sorry for the late reply. Wolfgang: sorry about my misuse of the csv.DictReader constructor, that was a mistake on my part. However, it still is not functionning as I think it should/could. Look at this: Using this content: Sequence AAGINRDSL AAIANHQVL and this piece of code: f = open(sys.argv[-1], 'r') dialect = csv.Sniffer().sniff(f.readline()) f.seek(0) reader = csv.DictReader(f, dialect=dialect) for line in reader: print line I get this result: {'Sequen': 'AAGINRDSL', 'e': None} {'Sequen': 'AAIANHQVL', 'e': None} When I really should be getting this: {'Sequence': 'AAGINRDSL'} {'Sequence': 'AAIANHQVL'} The fact is this code is in use in an application where users can submit a .csv file produced by Excel for treatment. The file must contain a "Sequence" column since that is what the treatment is run on. Now I had to make the following changes to my code to account for the fact that some users submit a single column file (since only the "Sequence" column is required for treatment): f = open(sys.argv[-1], 'r') try: dialect = csv.Sniffer().sniff(f.readline(), [',', '\t']) f.seek(0) reader = csv.DictReader(f, dialect=dialect) except: print '>>>caught csv sniff() exception' f.seek(0) reader = csv.DictReader(f) for line in reader: Do what I need to do Which really feels like a patched use of a buggy implementation of the Sniffer class I understand the issues raised by Skip in regards to figuring out a delimiter at all costs... But really, the Sniffer class should work apropriately when a single column .csv file is submitted __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 17:06:54 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 27 Mar 2008 16:06:54 +0000 Subject: [issue2496] test_no_refcycle_through_target sometimes fails in test_threading In-Reply-To: <1206619475.61.0.0373454947155.issue2496@psf.upfronthosting.co.za> Message-ID: <1206634014.44.0.445100276387.issue2496@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hmm, even with a Py_DEBUG build I can't reproduce the bug. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 17:07:26 2008 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 27 Mar 2008 16:07:26 +0000 Subject: [issue2078] CSV Sniffer does not function properly on single column .csv files In-Reply-To: <1206631178.71.0.893907928342.issue2078@psf.upfronthosting.co.za> Message-ID: <18411.50739.462489.22076@montanaro-dyndns-org.local> Skip Montanaro added the comment: Jean-Philippe> The fact is this code is in use in an application where Jean-Philippe> users can submit a .csv file produced by Excel for Jean-Philippe> treatment. The file must contain a "Sequence" column Jean-Philippe> since that is what the treatment is run on. Now I had to Jean-Philippe> make the following changes to my code to account for the Jean-Philippe> fact that some users submit a single column file (since Jean-Philippe> only the "Sequence" column is required for treatment): Jean-Philippe> f = open(sys.argv[-1], 'r') Jean-Philippe> try: Jean-Philippe> dialect = csv.Sniffer().sniff(f.readline(), [',', '\t']) Jean-Philippe> f.seek(0) Jean-Philippe> reader = csv.DictReader(f, dialect=dialect) Jean-Philippe> except: Jean-Philippe> print '>>>caught csv sniff() exception' Jean-Philippe> f.seek(0) Jean-Philippe> reader = csv.DictReader(f) Jean-Philippe> for line in reader: Jean-Philippe> Do what I need to do What exceptions are you catching? Why are you only giving it a single line of input as a sample? What happens if you instead use f.read(1024) as the sample? When there is only a single column in the file and you give it a delimiter set which doesn't include any characters in the file it (I think correctly) raises an exception to tell you that it couldn't determine the delimiter: >>> import csv >>> f = open("listB2Mforblast.csv") >>> dialect = csv.Sniffer().sniff(f.read(1024)) >>> dialect.delimiter '"' >>> f.seek(0) >>> dialect = csv.Sniffer().sniff(f.read(1024), ",\t :;") Traceback (most recent call last): File "", line 1, in File "/Users/skip/local/lib/python2.6/csv.py", line 161, in sniff raise Error, "Could not determine delimiter" _csv.Error: Could not determine delimiter In that case, use csv.excel as the dialect. It doesn't matter what you use as the delimiter if it doesn't occur in the file, and if it can't figure out the delimiter it's also not going to guess the quotechar. >>> try: ... dialect = csv.Sniffer().sniff(f.read(1024), ",\t :;") ... except csv.Error: ... dialect = csv.excel ... I personally don't much like the sniffer. It doesn't use any knowledge of the structure of a CSV file to guess the delimiter and quotechar (and those are the only two parameters it does guess). I would prefer if it just went away, but folks use it so it's likely to remain in its current form for the forseeable future. Skip __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 17:16:54 2008 From: report at bugs.python.org (M.-A. DARCHE) Date: Thu, 27 Mar 2008 16:16:54 +0000 Subject: [issue2406] Improvement suggestions for the gzip module documentation In-Reply-To: <1205872183.57.0.209526870399.issue2406@psf.upfronthosting.co.za> Message-ID: <1206634614.84.0.401918950382.issue2406@psf.upfronthosting.co.za> M.-A. DARCHE added the comment: Here is the diff of the suggested modifications, which include Guilherme remarks. This is the kind of doc I would have like to read when I needed it. Regards. ---------- keywords: +patch Added file: http://bugs.python.org/file9876/gzip.rst.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 17:21:49 2008 From: report at bugs.python.org (Armin Rigo) Date: Thu, 27 Mar 2008 16:21:49 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za> Message-ID: <1206634909.91.0.131737011781.issue2459@psf.upfronthosting.co.za> Armin Rigo added the comment: Can you see if this simpler patch also gives speed-ups? (predict_loop.diff) ---------- nosy: +arigo Added file: http://bugs.python.org/file9877/predict_loop.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 17:22:40 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 27 Mar 2008 16:22:40 +0000 Subject: [issue2496] test_no_refcycle_through_target sometimes fails in test_threading In-Reply-To: <1206619475.61.0.0373454947155.issue2496@psf.upfronthosting.co.za> Message-ID: <1206634960.5.0.607743048032.issue2496@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hmm, I think I know what happens. t_bootstrap() in threadmodule.c calls the self.__bootstrap() method in the Thread object, and it is this method which sets the __stopped flag at its end, which in turns wakes up the join() method. The problem is that at this point, t_bootstrap() still (rightly) holds a reference to the Thread object, since it has a reference to its __bootstrap() method which is still running. Depending on how the operating system switches threads, this reference may or may not be released when the join() method returns. So I think it's the test that is flaky. Instead of calling the join() method, it should wait for the OS-level thread to finish. Or it should find another way of testing for the reference cycle. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 17:23:05 2008 From: report at bugs.python.org (Guilherme Polo) Date: Thu, 27 Mar 2008 16:23:05 +0000 Subject: [issue2406] Improvement suggestions for the gzip module documentation In-Reply-To: <1205872183.57.0.209526870399.issue2406@psf.upfronthosting.co.za> Message-ID: <1206634985.19.0.658723478467.issue2406@psf.upfronthosting.co.za> Guilherme Polo added the comment: If I could I would commit it, but you have my support on this one nevertheless ;) __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 17:32:06 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 27 Mar 2008 16:32:06 +0000 Subject: [issue2496] test_no_refcycle_through_target sometimes fails in test_threading In-Reply-To: <1206619475.61.0.0373454947155.issue2496@psf.upfronthosting.co.za> Message-ID: <1206635526.24.0.51526932372.issue2496@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm attaching a patch which tries to make the test a bit less flaky (well, it still is, since I introduce a time.sleep() :-)). Added file: http://bugs.python.org/file9878/test_threading2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 17:56:15 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 27 Mar 2008 16:56:15 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za> Message-ID: <1206636975.34.0.33695206205.issue2459@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Armin, your patch gives a speed-up for "for" loops and comprehensions, although a bit less. Also, it doesn't speed up "while" loops and "if" statements at all. For some reasons it also appears to make pystone a bit slower. Here are some micro-benchmarks: ./python -m timeit "for x in xrange(10000): pass" Before: 1000 loops, best of 3: 758 usec per loop After: 1000 loops, best of 3: 483 usec per loop ./python -m timeit "x=100" "while x: x -= 1" Before: 10000 loops, best of 3: 21.8 usec per loop After: 10000 loops, best of 3: 21.6 usec per loop ./python -m timeit -s "l = range(100)" "[x for x in l]" Before: 100000 loops, best of 3: 14.9 usec per loop After: 100000 loops, best of 3: 13.3 usec per loop ./python -m timeit -s "l = range(100)" "[x for x in l if x]" Before: 10000 loops, best of 3: 23.9 usec per loop After: 10000 loops, best of 3: 22.3 usec per loop ./python -m timeit -s "l = range(100)" "[x for x in l if not x]" Before: 100000 loops, best of 3: 15.8 usec per loop After: 100000 loops, best of 3: 13.9 usec per loop ./python Tools/pybench/pybench.py -t IfThenElse Before: 164ms per round After: 166ms per round __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 18:25:27 2008 From: report at bugs.python.org (Jeffrey C. Jacobs) Date: Thu, 27 Mar 2008 17:25:27 +0000 Subject: [issue433030] SRE: (?>...) is not supported Message-ID: <1206638727.36.0.438235226452.issue433030@psf.upfronthosting.co.za> Changes by Jeffrey C. Jacobs : ---------- nosy: +timehorse ____________________________________ Tracker ____________________________________ From report at bugs.python.org Thu Mar 27 20:37:05 2008 From: report at bugs.python.org (John J Lee) Date: Thu, 27 Mar 2008 19:37:05 +0000 Subject: [issue2451] No way to disable socket timeouts in httplib, etc. In-Reply-To: <1206141378.11.0.857343736887.issue2451@psf.upfronthosting.co.za> Message-ID: <1206646625.44.0.573796258334.issue2451@psf.upfronthosting.co.za> John J Lee added the comment: Great. I'll try to submit a patch this weekend. __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 21:28:49 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Thu, 27 Mar 2008 20:28:49 +0000 Subject: [issue2497] stdbool support In-Reply-To: <1206628632.31.0.556646353118.issue2497@psf.upfronthosting.co.za> Message-ID: <1206649729.22.0.142738455289.issue2497@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Why does it improve portability to use stdbool.h when it exists? What is the potential issue with asdl.c that gets fixed with this patch? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 21:32:36 2008 From: report at bugs.python.org (Lauro Moura) Date: Thu, 27 Mar 2008 20:32:36 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za> Message-ID: <1206649956.88.0.295821748253.issue2459@psf.upfronthosting.co.za> Changes by Lauro Moura : ---------- nosy: +lauromoura __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 21:39:03 2008 From: report at bugs.python.org (Jean-Philippe Laverdure) Date: Thu, 27 Mar 2008 20:39:03 +0000 Subject: [issue2078] CSV Sniffer does not function properly on single column .csv files In-Reply-To: <1202832132.24.0.528453630912.issue2078@psf.upfronthosting.co.za> Message-ID: <1206650343.02.0.115382198287.issue2078@psf.upfronthosting.co.za> Jean-Philippe Laverdure added the comment: Hi Skip, You're right, it does seem that using f.read(1024) to feed the sniffer works OK in my case and allows me to instantiate the DictReader correctly... Why that is I'm not sure though... I was submitting the first line as I thought is was the right sample to provide the sniffer for it to sniff the correct dialect regardless of the file format and file content. And yes, 'except csv.Error' is certainly a better way to trap my desired exception... I guess I'm a bit of a n00b using Python. Thanks for the help. Python really has a great community ! __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 22:03:02 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 27 Mar 2008 21:03:02 +0000 Subject: [issue2498] bdb modernized In-Reply-To: <1206651782.63.0.136220859042.issue2498@psf.upfronthosting.co.za> Message-ID: <1206651782.63.0.136220859042.issue2498@psf.upfronthosting.co.za> New submission from Benjamin Peterson : bdb.py has several places like this: try: try: pass except BdbQuit: pass finally: pass These can be modernized to the > 2.5 syntax. ---------- assignee: georg.brandl components: Library (Lib) files: bdb_modern.patch keywords: patch messages: 64607 nosy: benjamin.peterson, georg.brandl severity: normal status: open title: bdb modernized type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file9879/bdb_modern.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Mar 27 22:29:41 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Thu, 27 Mar 2008 21:29:41 +0000 Subject: [issue2496] test_no_refcycle_through_target sometimes fails in test_threading In-Reply-To: <1206619475.61.0.0373454947155.issue2496@psf.upfronthosting.co.za> Message-ID: <1206653381.69.0.0305063363738.issue2496@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: I'll look at this tonight. ---------- assignee: -> jyasskin nosy: +jyasskin __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 00:24:22 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 27 Mar 2008 23:24:22 +0000 Subject: [issue2495] tokenize doesn't handle __future__.unicode_literals correctly In-Reply-To: <1206618603.55.0.554342479222.issue2495@psf.upfronthosting.co.za> Message-ID: <1206660262.5.0.761238436849.issue2495@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Actually, the problem is that untokenize does not put spaces between two consecutive string literals: '' '' => '''' Corrected with r61979. Will backport ---------- nosy: +amaury.forgeotdarc resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 00:55:24 2008 From: report at bugs.python.org (Rolland Dudemaine) Date: Thu, 27 Mar 2008 23:55:24 +0000 Subject: [issue2497] stdbool support In-Reply-To: <1206649729.22.0.142738455289.issue2497@psf.upfronthosting.co.za> Message-ID: <47EC33E5.4070905@ghs.com> Rolland Dudemaine added the comment: Some compilers define false and true as macros. When doing this, the definition in asdl.h (included from asdl.c) which is originally : typedef enum {false, true} bool; therefore becomes : typedef enum {0, 1} bool; which is non-sensical. Using stdbool.h when it is available will ensure bool is defined as a type following the correct definition, which may or may not be an enum depending on the compiler. Even when using gcc, stdbool.h is here to define bool in C language, so why not use it ? --Rolland Martin v. L?wis wrote: > Martin v. L?wis added the comment: > > Why does it improve portability to use stdbool.h when it exists? > > What is the potential issue with asdl.c that gets fixed with this patch? > > ---------- > nosy: +loewis > > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 01:12:52 2008 From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=) Date: Fri, 28 Mar 2008 00:12:52 +0000 Subject: [issue2480] pickling of large recursive structures fails In-Reply-To: <1206452686.51.0.217993005172.issue2480@psf.upfronthosting.co.za> Message-ID: <1206663172.17.0.0428713444423.issue2480@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 03:20:21 2008 From: report at bugs.python.org (Collin Winter) Date: Fri, 28 Mar 2008 02:20:21 +0000 Subject: [issue2453] fix_except needs to allow for empty excepts In-Reply-To: <1206146973.79.0.293123214296.issue2453@psf.upfronthosting.co.za> Message-ID: <1206670821.33.0.909207525756.issue2453@psf.upfronthosting.co.za> Collin Winter added the comment: Fixed in r61983. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 04:36:56 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Fri, 28 Mar 2008 03:36:56 +0000 Subject: [issue2496] test_no_refcycle_through_target sometimes fails in test_threading In-Reply-To: <1206619475.61.0.0373454947155.issue2496@psf.upfronthosting.co.za> Message-ID: <1206675416.95.0.612884473105.issue2496@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: I think I've confirmed your diagnosis. If I add a _sleep(.01) to Thread.__bootstrap_inner() just after the call to self.__stop(), the test fails reliably. Very good catch! Given that, I think just adding a short sleep to the test before counting references will fix it nearly every time, but I'd like to kill the race dead if we can. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 05:05:18 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 28 Mar 2008 04:05:18 +0000 Subject: [issue2499] Fold unary + and not on constants In-Reply-To: <1206677118.63.0.142364619401.issue2499@psf.upfronthosting.co.za> Message-ID: <1206677118.63.0.142364619401.issue2499@psf.upfronthosting.co.za> New submission from Alexander Belopolsky : Before: >>> dis(lambda:+2) 1 0 LOAD_CONST 0 (2) 3 UNARY_POSITIVE 4 RETURN_VALUE >>> dis(lambda:not 2) 1 0 LOAD_CONST 0 (2) 3 UNARY_NOT 4 RETURN_VALUE After: >>> dis(lambda:+2) 1 0 LOAD_CONST 1 (2) 3 RETURN_VALUE >>> dis(lambda:not 2) 1 0 LOAD_CONST 1 (False) 3 RETURN_VALUE ---------- components: Interpreter Core files: fold-unary.diff keywords: patch messages: 64613 nosy: belopolsky severity: normal status: open title: Fold unary + and not on constants type: resource usage versions: Python 2.6 Added file: http://bugs.python.org/file9880/fold-unary.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 05:12:53 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Fri, 28 Mar 2008 04:12:53 +0000 Subject: [issue2496] test_no_refcycle_through_target sometimes fails in test_threading In-Reply-To: <1206619475.61.0.0373454947155.issue2496@psf.upfronthosting.co.za> Message-ID: <1206677573.34.0.807603051703.issue2496@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Fixed in r61984. I believe the exception info was actually keeping the object alive. The thread itself didn't have any references to it, but the traceback did. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 05:22:33 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Fri, 28 Mar 2008 04:22:33 +0000 Subject: [issue2459] speedup loops with better bytecode In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za> Message-ID: <1206678153.86.0.0988217591021.issue2459@psf.upfronthosting.co.za> Changes by Jeffrey Yasskin : ---------- nosy: +jyasskin __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 05:48:01 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 28 Mar 2008 04:48:01 +0000 Subject: [issue2497] stdbool support In-Reply-To: <47EC33E5.4070905@ghs.com> Message-ID: <47EC787D.40208@v.loewis.de> Martin v. L?wis added the comment: > Some compilers define false and true as macros. Which compilers specifically? It sounds like a violation of the C standard to do so, without stdbool.h being included. > Using stdbool.h when it is available will ensure bool is defined as a > type following the correct definition, which may or may not be an enum > depending on the compiler. But would that help in any way with respect to above compilers? If they don't follow the C standard, why should they provide stdbool.h? > Even when using gcc, stdbool.h is here to define bool in C language, so > why not use it ? Because we cannot *rely* on stdbool.h being present. Therefore, inclusion of stdbool.h must be conditional, with a fallback definition if stdbool.h is absent, and it thus complicates the source code of Python, with no gain whatsoever. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 07:39:56 2008 From: report at bugs.python.org (Neal Norwitz) Date: Fri, 28 Mar 2008 06:39:56 +0000 Subject: [issue1503] test_xmlrpc is still flakey In-Reply-To: <1196126599.89.0.0637627606597.issue1503@psf.upfronthosting.co.za> Message-ID: <1206686396.48.0.295538087971.issue1503@psf.upfronthosting.co.za> Neal Norwitz added the comment: Ugh. The manpage for accept on Ubuntu 6.10 says: """ On Linux, the new socket returned by accept() does not inherit file status flags such as O_NONBLOCK and O_ASYNC from the listening socket. This behaviour differs from the canonical BSD sockets implementation. Portable programs should not rely on inheritance or non-inheritance of file status flags and always explicitly set all required flags on the socket returned from accept(). """ http://msdn2.microsoft.com/en-us/library/aa450277.aspx says that Windows (CE, but I assume all variants) are like BSD in that they inherit attributes. """The newly created socket is the socket that will handle the actual connection and has the same properties as socket s, including the asynchronous events registered with the WSAEventSelect function.""" I assume that means blocking behavior. I checked in r61993 which should fix the immediate problem with test_xmlrpc. I wonder if we should change socket to do the same thing for all platforms. ---------- nosy: +nnorwitz __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 08:25:21 2008 From: report at bugs.python.org (Rolland Dudemaine) Date: Fri, 28 Mar 2008 07:25:21 +0000 Subject: [issue2497] stdbool support In-Reply-To: <47EC787D.40208@v.loewis.de> Message-ID: <47EC9D56.6000509@ghs.com> Rolland Dudemaine added the comment: In this precise case, this is for an RTOS called INTEGRITY, which does define true and false as macros. The compiler is the vendor compiler (Green Hills), but the definition conflicting with Python's definition is comiung from the system header. Note, the issue still remains outside this context. >> Using stdbool.h when it is available will ensure bool is defined as a >> type following the correct definition, which may or may not be an enum >> depending on the compiler. >> > > But would that help in any way with respect to above compilers? > If they don't follow the C standard, why should they provide stdbool.h? > That's not the point. If stdbool is not available, C99 still defines false and true as macros. If stdbool is available, then most compilers will define false and true as macros. This includes Green Hills' compiler, but more importantly gcc as well. Look at http://gcc.gnu.org/viewcvs/trunk/gcc/ginclude/stdbool.h?revision=130805&view=markup for the current definition of stdbool.h in gcc. Look at http://www.opengroup.org/onlinepubs/009695399/basedefs/stdbool.h.html for a definition of how false, true and _Bool should be defined. In both cases, if stdbool was included by any system header in the future, that would conflict with your current definition. >> Even when using gcc, stdbool.h is here to define bool in C language, so >> why not use it ? >> > > Because we cannot *rely* on stdbool.h being present. Therefore, > inclusion of stdbool.h must be conditional, with a fallback definition > if stdbool.h is absent, and it thus complicates the source code of > Python, with no gain whatsoever. > This is the main reason why I added the conditional in the code, so that for compilers that do not have a definition everything will work fine, and for those who have, then it's doing the right and expected thing. But actually, you're right, the line should be completely eliminated, and replaced with the following : typedef unsigned char _Bool; #define bool _Bool #define true 1 #define false 0 Btw, there are already a number of fallback definitions in Python.h and such. This one is another portability issue, just adding to the others. stdbool.h is a standard facility created to help portability, so again, why not use it ? I can post an updated patch if you want. Do you agree with these changes then? --Rolland > __________________________________ > Tracker > > __________________________________ > __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 08:25:25 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 28 Mar 2008 07:25:25 +0000 Subject: [issue2499] Fold unary + and not on constants In-Reply-To: <1206677118.63.0.142364619401.issue2499@psf.upfronthosting.co.za> Message-ID: <1206689125.34.0.927954679607.issue2499@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It would be helpful if we talked before going further on build-outs to the peephole optimizer. IIRC, we chose to not do this one because it interfered with other more important optimizations. More importantly, we decided that the peepholer is the wrong place to do much of this work. Most of the peepholer is going to be migrated up the chain, after the AST is generated, but before the opcodes are generated. That is a faster, more reliable, and more general approach. The constant folding anti-duplication patch should also not be done for this same reason. That patch slows down compilation and makes it more fragile but does not add speed (just like the dead code elimination patches). When the peepholer is moved-up, the anti- duplication code won't be needed (as you won't need its attendant rescan/rewrite pass of the bytecode). You're writing these faster than I have time to review and likely reject them. Please show some moderation. The peepholer is intentionally very conservative. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 08:50:10 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 28 Mar 2008 07:50:10 +0000 Subject: [issue2429] Patch for test_urllib2_net moving tests to use a local server In-Reply-To: <1205968955.73.0.744201305439.issue2429@psf.upfronthosting.co.za> Message-ID: <1206690610.03.0.345632980864.issue2429@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 08:54:02 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 28 Mar 2008 07:54:02 +0000 Subject: [issue2498] bdb modernized In-Reply-To: <1206651782.63.0.136220859042.issue2498@psf.upfronthosting.co.za> Message-ID: <1206690842.66.0.372266571157.issue2498@psf.upfronthosting.co.za> Georg Brandl added the comment: Go ahead and commit -- and don't forget the issue number :) ---------- assignee: georg.brandl -> benjamin.peterson resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 09:02:48 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 28 Mar 2008 08:02:48 +0000 Subject: [issue2429] Patch for test_urllib2_net moving tests to use a local server In-Reply-To: <1205968955.73.0.744201305439.issue2429@psf.upfronthosting.co.za> Message-ID: <1206691368.55.0.654188877926.issue2429@psf.upfronthosting.co.za> Gregory P. Smith added the comment: committed to trunk in r61998. time to watch the buildbots, it looked good to me and passed on my machine. i'll close it once i see buildbot test love. tweaks i made: I reenabled the commented out ProxyAuth test, as it works and I assumed that was leftover from your debugging. I also changed the URL in the ProxyAuth test to http://localhost just in case it triggered any network traffic. ---------- resolution: -> accepted status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 09:07:05 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 28 Mar 2008 08:07:05 +0000 Subject: [issue2406] Improvement suggestions for the gzip module documentation In-Reply-To: <1205872183.57.0.209526870399.issue2406@psf.upfronthosting.co.za> Message-ID: <1206691625.12.0.0866629197862.issue2406@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed patch in r61999. Thanks! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 09:32:46 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 28 Mar 2008 08:32:46 +0000 Subject: [issue2426] pysqlite provides no interface for database SQL dump In-Reply-To: <1205947581.08.0.648809036566.issue2426@psf.upfronthosting.co.za> Message-ID: <1206693165.93.0.936050521531.issue2426@psf.upfronthosting.co.za> Gregory P. Smith added the comment: thanks! committed to trunk in r62000. ---------- priority: -> normal resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 11:04:31 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 28 Mar 2008 10:04:31 +0000 Subject: [issue2500] Sync _sqlite module code In-Reply-To: <1206698671.09.0.0786877274007.issue2500@psf.upfronthosting.co.za> Message-ID: <1206698671.09.0.0786877274007.issue2500@psf.upfronthosting.co.za> New submission from Christian Heimes : The source code of the _sqlite module in 3.0 is not in sync with the code from 2.6. Some features and fixes are missing. If I recall correctly I didn't merge a revision from 2.6 to 3.0 because 2.6a1 and 3.0a3 were released on the same day. ---------- assignee: ghaering components: Extension Modules messages: 64623 nosy: ghaering, tiran priority: critical severity: normal status: open title: Sync _sqlite module code type: feature request versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 11:06:36 2008 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Fri, 28 Mar 2008 10:06:36 +0000 Subject: [issue2500] Sync _sqlite module code In-Reply-To: <1206698671.09.0.0786877274007.issue2500@psf.upfronthosting.co.za> Message-ID: <1206698796.35.0.212074395181.issue2500@psf.upfronthosting.co.za> Gerhard H?ring added the comment: I know. I'll do it this weekend. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 11:15:14 2008 From: report at bugs.python.org (Mark Summerfield) Date: Fri, 28 Mar 2008 10:15:14 +0000 Subject: [issue2501] xml.sax.parser() doesn't terminate when given a filename In-Reply-To: <1206699313.91.0.35803015757.issue2501@psf.upfronthosting.co.za> Message-ID: <1206699313.91.0.35803015757.issue2501@psf.upfronthosting.co.za> New submission from Mark Summerfield : The tiny program at the end of this message runs under Python 2.5 & 30a3. Under 2 it gives the following output: : python sax.py test.xml ('+', u'document') ('+', u'outer') ('+', u'inner') ('-', u'inner') ('-', u'outer') ('-', u'document') Done Under 3 it does not terminate: : python3 sax.py test.xml + document + outer + inner - inner - outer - document Traceback (most recent call last): File "sax.py", line 19, in parser.parse(sys.argv[1]) File "/home/mark/opt/python30a3/lib/python3.0/xml/sax/expatreader.py", line 107, in parse xmlreader.IncrementalParser.parse(self, source) File "/home/mark/opt/python30a3/lib/python3.0/xml/sax/xmlreader.py", line 124, in parse buffer = file.read(self._bufsize) File "/home/mark/opt/python30a3/lib/python3.0/io.py", line 774, in read current = self.raw.read(to_read) KeyboardInterrupt The xml.sax.parser() function seems to work fine if you give it an open file object and close the file after the call. But the documentation says you can give it a filename, but if you do that the parser does not terminate in Python 3 although it works fine in Python 2. # sax.py import sys import xml.sax BUG = True class SaxHandler(xml.sax.handler.ContentHandler): def startElement(self, name, attributes): print("+", name) def endElement(self, name): print("-", name) handler = SaxHandler() parser = xml.sax.make_parser() parser.setContentHandler(handler) if BUG: parser.parse(sys.argv[1]) else: fh = open(sys.argv[1], encoding="utf8") parser.parse(fh) fh.close() print("Done") # end of sax.py Here is the test file: ---------- components: XML messages: 64625 nosy: mark severity: normal status: open title: xml.sax.parser() doesn't terminate when given a filename type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 11:31:51 2008 From: report at bugs.python.org (Christian Heimes) Date: Fri, 28 Mar 2008 10:31:51 +0000 Subject: [issue2501] xml.sax.parser() doesn't terminate when given a filename In-Reply-To: <1206699313.91.0.35803015757.issue2501@psf.upfronthosting.co.za> Message-ID: <1206700310.94.0.348324972661.issue2501@psf.upfronthosting.co.za> Christian Heimes added the comment: I had to disable three unit tests in test_sax. We didn't noticed the problem before because the tests weren't actually run. The three tests are marked clearly with XXX and FIXME. ---------- nosy: +tiran priority: -> critical __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 12:05:19 2008 From: report at bugs.python.org (Wummel) Date: Fri, 28 Mar 2008 11:05:19 +0000 Subject: [issue2502] Add enum() example for named tuples In-Reply-To: <1206702319.7.0.998063864211.issue2502@psf.upfronthosting.co.za> Message-ID: <1206702319.7.0.998063864211.issue2502@psf.upfronthosting.co.za> New submission from Wummel : Named tuples can also be used to emulate enum datatypes. The patch adds an example to the documentation. ---------- assignee: georg.brandl components: Documentation files: 0001-Add-enum-example-for-named-tuples.patch keywords: patch messages: 64627 nosy: calvin, georg.brandl severity: normal status: open title: Add enum() example for named tuples versions: Python 2.6 Added file: http://bugs.python.org/file9881/0001-Add-enum-example-for-named-tuples.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 12:06:50 2008 From: report at bugs.python.org (Wummel) Date: Fri, 28 Mar 2008 11:06:50 +0000 Subject: [issue2503] Replace "== None/True/False" with "is" In-Reply-To: <1206702410.08.0.751356671571.issue2503@psf.upfronthosting.co.za> Message-ID: <1206702410.08.0.751356671571.issue2503@psf.upfronthosting.co.za> New submission from Wummel : Test equality with None/True/False singletons should be done by "is" rather than "==" to be on the safe side. Otherwise objects overriding __eq__ could compare equal to one of those singletons. ---------- components: None files: 0001-Replace-None-True-False-with-is.patch keywords: patch messages: 64628 nosy: calvin severity: normal status: open title: Replace "== None/True/False" with "is" versions: Python 2.6 Added file: http://bugs.python.org/file9882/0001-Replace-None-True-False-with-is.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 12:22:58 2008 From: report at bugs.python.org (Wummel) Date: Fri, 28 Mar 2008 11:22:58 +0000 Subject: [issue2502] Add enum() example for named tuples In-Reply-To: <1206702319.7.0.998063864211.issue2502@psf.upfronthosting.co.za> Message-ID: <1206703378.32.0.179921361372.issue2502@psf.upfronthosting.co.za> Wummel added the comment: The motivation for this patch is that documenting a single function adding enum-like capabilities would hopefully eliminate the numerous "enum" recipies already out there, each handling things a little different. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 13:12:17 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 28 Mar 2008 12:12:17 +0000 Subject: [issue1810] AST compile() patch In-Reply-To: <1200095922.65.0.677669960272.issue1810@psf.upfronthosting.co.za> Message-ID: <1206706336.96.0.310881319413.issue1810@psf.upfronthosting.co.za> Georg Brandl added the comment: So I finally got to this one :) I had to fix a few things, mainly error handling, and a refleak. And I found a refleak in the compiler :) Reviewed and committed in r62004. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 13:13:24 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 28 Mar 2008 12:13:24 +0000 Subject: [issue2503] Replace "== None/True/False" with "is" In-Reply-To: <1206702410.08.0.751356671571.issue2503@psf.upfronthosting.co.za> Message-ID: <1206706404.38.0.625279834206.issue2503@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: You are right of course, but just out of curiosity, do you really have objects that compare equal to None? ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 13:14:53 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 28 Mar 2008 12:14:53 +0000 Subject: [issue2503] Replace "== None/True/False" with "is" In-Reply-To: <1206702410.08.0.751356671571.issue2503@psf.upfronthosting.co.za> Message-ID: <1206706493.85.0.409975774784.issue2503@psf.upfronthosting.co.za> Georg Brandl added the comment: I'm in favor of this patch. Not only is "is" faster here, but it is also way more idiomatic. ---------- nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 13:28:46 2008 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 28 Mar 2008 12:28:46 +0000 Subject: [issue2078] CSV Sniffer does not function properly on single column .csv files In-Reply-To: <1206650343.02.0.115382198287.issue2078@psf.upfronthosting.co.za> Message-ID: <18412.4165.440393.304270@montanaro-dyndns-org.local> Skip Montanaro added the comment: Jean-Philippe> You're right, it does seem that using f.read(1024) to Jean-Philippe> feed the sniffer works OK in my case and allows me to Jean-Philippe> instantiate the DictReader correctly... Why that is I'm Jean-Philippe> not sure though... It works entirely based on chracter frequencies. The more characters you feed it the better it should be at guessing the correct delimiter. In particular, it pays attention to the frequency of the possible delimiters per line and assumes the number of columns is the same for each line. (Well, there's one place where it does use some knowledge of the structure of a csv file, so my earlier assertion was incorrect.) If you only feed it one line it can't really use that frequency-per-line information. Jean-Philippe> I was submitting the first line as I thought is was the Jean-Philippe> right sample to provide the sniffer for it to sniff the Jean-Philippe> correct dialect regardless of the file format and file Jean-Philippe> content. That's a good guess, but not quite spot on in this case. In particular, the character frequencies in the first line tend to be much different than the other lines because it usually a row of column headers, while the remainder of the file (though not always ;-) is a table of numbers. Skip __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 13:40:05 2008 From: report at bugs.python.org (Jeffrey C. Jacobs) Date: Fri, 28 Mar 2008 12:40:05 +0000 Subject: [issue433030] SRE: (?>...) is not supported Message-ID: <1206708005.23.0.509699094554.issue433030@psf.upfronthosting.co.za> Jeffrey C. Jacobs added the comment: Fredrik, If you're still listening, I am gonna try and tackle this one but I would like to know why you or the famous Jeffrey of the Regexp world claims that there is already code in the Regexp Engine for Atomic Grouping? Adding a hook for (?>...) should be trivial but I don't wanna re-invent the wheel if the proper stack-unwind code already exists. Thanks. Of course, Andrew (a.k.a. A.M. Kuchling) already asked this question and you did not answer it, so I guess you're not reading this, but if you are, please respond. Thanks! ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 28 13:40:52 2008 From: report at bugs.python.org (Jeffrey C. Jacobs) Date: Fri, 28 Mar 2008 12:40:52 +0000 Subject: [issue433030] SRE: Atomic Grouping (?>...) is not supported Message-ID: <1206708052.76.0.988612695048.issue433030@psf.upfronthosting.co.za> Changes by Jeffrey C. Jacobs : ---------- title: SRE: (?>...) is not supported -> SRE: Atomic Grouping (?>...) is not supported ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 28 13:58:45 2008 From: report at bugs.python.org (Georg Brandl) Date: Fri, 28 Mar 2008 12:58:45 +0000 Subject: [issue2502] Add enum() example for named tuples In-Reply-To: <1206702319.7.0.998063864211.issue2502@psf.upfronthosting.co.za> Message-ID: <1206709125.57.0.59584310384.issue2502@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed example (a * was missing) and committed as r62007. Thanks! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 14:05:28 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 28 Mar 2008 13:05:28 +0000 Subject: [issue2502] Add enum() example for named tuples In-Reply-To: <1206702319.7.0.998063864211.issue2502@psf.upfronthosting.co.za> Message-ID: <1206709528.41.0.60602428415.issue2502@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Raymond, is this kind of recipes worth adding to the 'collections' module? Maybe with the following form: def enum(*valuenames): return namedtuple('Enum', valuenames)(*range(len(valuenames))) ---------- nosy: +amaury.forgeotdarc, rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 14:24:33 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 28 Mar 2008 13:24:33 +0000 Subject: [issue2503] Replace "== None/True/False" with "is" In-Reply-To: <1206702410.08.0.751356671571.issue2503@psf.upfronthosting.co.za> Message-ID: <1206710672.99.0.0653615343431.issue2503@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Yes, PEP8 says:: Comparisons to singletons like None should always be done with 'is' or 'is not', never the equality operators. Reading the patch: - a change modifies "x == False" into "not x", another moves some lines. I checked that they are OK (x is already the result of a comparison). - some occurrences of "x != None" are not replaced. Why? (ex. in test_ast.py) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 14:27:32 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 28 Mar 2008 13:27:32 +0000 Subject: [issue2499] Fold unary + and not on constants In-Reply-To: <1206689125.34.0.927954679607.issue2499@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Fri, Mar 28, 2008 at 3:25 AM, Raymond Hettinger wrote: > > It would be helpful if we talked before going further on build-outs to > the peephole optimizer. Sure. > IIRC, we chose to not do this one because it > interfered with other more important optimizations. There are two optimization in my patch: one for + and the other not . I think you recall that not optimization could interfere with not a is b --> a is not b and similar transformations. My patch, however does not affect those. With respect to unary +, I don't think it was intentionally omitted: I would think it is more common to use unary + on constants than `..`, but case UNARY_CONVERT is there in 2.x. Constant folding promotes more readable code: 24*60*60 is more obvious than 86400, prefixing positive numbers with + leads to better visual alignment, etc. Users should not be required to think twice about which constant expressions are folded and which are not. Here is another surprise with the current peepholer: 1 0 LOAD_CONST 0 (1) 3 LOAD_CONST 3 (6) 6 BINARY_ADD 7 RETURN_VALUE 1 0 LOAD_CONST 4 (7) 3 RETURN_VALUE I have a fix in the works, but I will wait for your further comments before submitting it. > > More importantly, we decided that the peepholer is the wrong place to > do much of this work. Most of the peepholer is going to be migrated > up the chain, after the AST is generated, but before the opcodes are > generated. That is a faster, more reliable, and more general > approach. > I agree. Constant folding, is an interesting case because peepholer has to duplicate a subset of eval logic. I wonder if the new approach could eliminate that. BTW, what is the rationale for leading +/- not being part of the number literal? Unary +/- optimization seems mostly useful for the simple +/-x case which could be handled by the tokenizer. What is the timeline for that project? Maybe a comment should be placed in peephole.c explaining that there is a plan to move uptimization logic up the compilation chain and announcing a moratorium on further peephole.c work. I am not the only one submitting peephole optimizer patches recently. > You're writing these faster than I have time to review and likely > reject them. Please show some moderation. ok :-) One more peephole optimizer related idea that I have in the pipeline is to implement an option to disable optimization altogether. Having such an option would help debugging/profiling the optimizer and will give users a simple check when they suspect that their code is improperly optimized. I would propose a patch already, but I could not think of a good command line option. Most compilers use -O0, but that would be confusingly similar to -OO. What do you think? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 14:46:55 2008 From: report at bugs.python.org (Wummel) Date: Fri, 28 Mar 2008 13:46:55 +0000 Subject: [issue2503] Replace "== None/True/False" with "is" In-Reply-To: <1206702410.08.0.751356671571.issue2503@psf.upfronthosting.co.za> Message-ID: <1206712015.11.0.722973788646.issue2503@psf.upfronthosting.co.za> Wummel added the comment: Amaury, I never saw an object comparing equal to None. I think the most likely case is a buggy x.__eq__() implementation. Then the "if x == None" statement gets triggered, and somebody has a hard time with bug hunting. Just a note: I used an adapted source checker for this patch, which initially came from the Sphinx documentation project, found under tools/check_sources.py. So the credits for this go to Georg Brandl. That is also why '!=' did not get replaced (the source checker only searched for '=='. I will post an updated patch. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 15:04:33 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 28 Mar 2008 14:04:33 +0000 Subject: [issue2503] Replace "== None/True/False" with "is" In-Reply-To: <1206702410.08.0.751356671571.issue2503@psf.upfronthosting.co.za> Message-ID: <1206713073.45.0.172026474017.issue2503@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Despite the title, the patch replaces "result == False" with "not result" rather than "result is False". While probably ok in this particular context, this changes the logic. For example, >>> result = "" >>> result == False False >>> not result True ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 17:20:41 2008 From: report at bugs.python.org (Collin Winter) Date: Fri, 28 Mar 2008 16:20:41 +0000 Subject: [issue2338] Backport reload() moving to imp.reload() In-Reply-To: <1205776379.99.0.615033547761.issue2338@psf.upfronthosting.co.za> Message-ID: <1206721241.03.0.398969073603.issue2338@psf.upfronthosting.co.za> Changes by Collin Winter : ---------- components: +2to3 (2.x to 3.0 conversion tool) __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 18:54:52 2008 From: report at bugs.python.org (John Krukoff) Date: Fri, 28 Mar 2008 17:54:52 +0000 Subject: [issue643841] New class special method lookup change Message-ID: <1206726891.99.0.119271229309.issue643841@psf.upfronthosting.co.za> John Krukoff added the comment: I was just bit by this today in converting a proxy class from old style to new style. The official documentation was of no help in discoverting that neither __getattr__ or __getattribute__ are used to look up magic attribute names. Even the link to "New-style Classes" off the development documentation page is useless, as none of the resources there (http://www.python.org/doc/newstyle/) mention the incompatible change. This seems like an issue that is going to come up more frequently as python 3000 pushes everyone to using only new style classes. It'd be very useful if whatever conversion tool we get, or the python 3000 standard library includes a proxy class or metaclass that is able to help with this conversion, such as this one: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/252151 Though preferably with some knowledge of all exising magic names. ---------- assignee: -> georg.brandl components: +Documentation -None nosy: +georg.brandl, jkrukoff versions: +Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6 ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 28 19:09:53 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 28 Mar 2008 18:09:53 +0000 Subject: [issue815646] thread unsafe file objects cause crash Message-ID: <1206727793.0.0.790985148086.issue815646@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is a preliminary patch which shows how things might be done better. It only addresses close(), seek() and dealloc right now. However, as mentioned in test_close_open_seek, if I raise the number of workers, I get crashes (while test_close_open is fine). Perhaps fseek() in the glibc is thread unsafe when operating on the same file descriptor? ---------- keywords: +patch Added file: http://bugs.python.org/file9883/filethread1.patch ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 28 19:20:45 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 28 Mar 2008 18:20:45 +0000 Subject: [issue815646] thread unsafe file objects cause crash Message-ID: <1206728445.2.0.626667070174.issue815646@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Another approach would be to add a dedicated lock for each PyFileObject. This sounds a bit bad performance-wise but after all the GIL itself is a lock, and we release and re-acquire it on each file operation, so why not? ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 28 19:42:41 2008 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Fri, 28 Mar 2008 18:42:41 +0000 Subject: [issue2174] xml.sax.xmlreader does not support the InputSource protocol In-Reply-To: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za> Message-ID: <1206729761.44.0.790843410568.issue2174@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: It's certainly arguable that the current behavior is a bug, though I suspect it shouldn't be considered major since I've not seen any prior complaints about this. It should be easy to fix the bug you describe by taking the character stream and encoding it before feeding it to the XML parser; Expat can certainly be forced to take a known encoding, ignoring what's in the XML declaration. On the other hand, it's not at all clear that changing this is worthwhile. This API borrows quite literally from the Java SAX APIs; perhaps this separation of the character stream from the byte stream makes sense for some of the Java XML parsers, but I don't know that there are any Python parsers that benefit from that separation. ---------- components: -Library (Lib), Unicode priority: normal -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 19:47:38 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 28 Mar 2008 18:47:38 +0000 Subject: [issue815646] thread unsafe file objects cause crash Message-ID: <1206730057.92.0.69403563693.issue815646@psf.upfronthosting.co.za> Antoine Pitrou added the comment: On the other hand, surprisingly enough, the flockfile/funlockfile manpage tells me that: The stdio functions are thread-safe. This is achieved by assigning to each FILE object a lockcount and (if the lockcount is nonzero) an owning thread. For each library call, these functions wait until the FILE object is no longer locked by a different thread, then lock it, do the requested I/O, and unlock the object again. This leaves me wondering what is happening in the above-mentioned test. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 28 19:55:57 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 28 Mar 2008 18:55:57 +0000 Subject: [issue1346238] A constant folding optimization pass for the AST Message-ID: <1206730556.96.0.975900455056.issue1346238@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Raymond wrote in his recent response on issue2499 (a patch that adds unary '+' and 'not' folding to peephole optimizer): """ More importantly, we decided that the peepholer is the wrong place to do much of this work. Most of the peepholer is going to be migrated up the chain, after the AST is generated, but before the opcodes are generated. That is a faster, more reliable, and more general approach. """ (See msg64618.) This looks like the relevant patch. I would like to take a look at the patch, but since it is more than 2 years old, maybe someone has an updated version. Please advise. ---------- nosy: +belopolsky type: -> performance _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Mar 28 20:04:48 2008 From: report at bugs.python.org (Collin Winter) Date: Fri, 28 Mar 2008 19:04:48 +0000 Subject: [issue2446] 2to3 translates "import foobar" to "import .foobar" rather than "from . import foobar" In-Reply-To: <1206122382.01.0.177794619684.issue2446@psf.upfronthosting.co.za> Message-ID: <1206731088.55.0.454128208499.issue2446@psf.upfronthosting.co.za> Collin Winter added the comment: The problem with the "fix" in r61755 is that it doesn't distinguish between stdlib and non-stdlib imports: "import os" becomes "from . import os", which is clearly wrong. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 20:19:37 2008 From: report at bugs.python.org (David Wolever) Date: Fri, 28 Mar 2008 19:19:37 +0000 Subject: [issue2446] 2to3 translates "import foobar" to "import .foobar" rather than "from . import foobar" In-Reply-To: <1206731088.55.0.454128208499.issue2446@psf.upfronthosting.co.za> Message-ID: <35A3DB0E-25D0-41BE-8919-85432F87B85D@cs.toronto.edu> David Wolever added the comment: Can you write a test case proving this? At the moment, the second thing that the transform function in fix_import.py does is return if the import doesn't look like a local import (see probably_a_local_import in fix_import). At the moment, all (with an exception or two) of the import test cases test both cases -- the local import exists and the local import does not exist -- automatically. On 28-Mar-08, at 3:04 PM, Collin Winter wrote: > > Collin Winter added the comment: > > The problem with the "fix" in r61755 is that it doesn't distinguish > between stdlib and non-stdlib imports: "import os" becomes "from . > import os", which is clearly wrong. > > __________________________________ > Tracker > > __________________________________ __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 21:12:57 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 28 Mar 2008 20:12:57 +0000 Subject: [issue2426] pysqlite provides no interface for database SQL dump In-Reply-To: <1205947581.08.0.648809036566.issue2426@psf.upfronthosting.co.za> Message-ID: <1206735177.53.0.0238566109939.issue2426@psf.upfronthosting.co.za> Gregory P. Smith added the comment: and r62012 which adds the dump.py files I forgot to svn add in r62000. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 21:18:10 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 28 Mar 2008 20:18:10 +0000 Subject: [issue2426] pysqlite provides no interface for database SQL dump In-Reply-To: <1205947581.08.0.648809036566.issue2426@psf.upfronthosting.co.za> Message-ID: <1206735490.13.0.194374006545.issue2426@psf.upfronthosting.co.za> Gregory P. Smith added the comment: although closed, i'm assigning this to ghaering so that he knows it went in and can merge this back into pysqlite if its not already in there. ---------- assignee: gregory.p.smith -> ghaering nosy: +ghaering __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 21:41:54 2008 From: report at bugs.python.org (Collin Winter) Date: Fri, 28 Mar 2008 20:41:54 +0000 Subject: [issue2446] 2to3 translates "import foobar" to "import .foobar" rather than "from . import foobar" In-Reply-To: <1206122382.01.0.177794619684.issue2446@psf.upfronthosting.co.za> Message-ID: <1206736914.2.0.644708268708.issue2446@psf.upfronthosting.co.za> Collin Winter added the comment: Looking at it, I was confused by a quirk introduced into test_fixers: Test_import's check_both() helper method does the wrong thing in this case: a = "import os" self.check_both(a, a) # Fails, tries to translate "import os" into "from . import os" self.unchanged(a) passes, though. What's going on with these methods? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 21:57:27 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 28 Mar 2008 20:57:27 +0000 Subject: [issue2498] bdb modernized In-Reply-To: <1206651782.63.0.136220859042.issue2498@psf.upfronthosting.co.za> Message-ID: <1206737847.04.0.16940104492.issue2498@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Commited with a message in r60218 ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 21:59:46 2008 From: report at bugs.python.org (David Wolever) Date: Fri, 28 Mar 2008 20:59:46 +0000 Subject: [issue2446] 2to3 translates "import foobar" to "import .foobar" rather than "from . import foobar" In-Reply-To: <1206736914.2.0.644708268708.issue2446@psf.upfronthosting.co.za> Message-ID: <66A881BA-FA70-4977-859C-F9962DBA6EEE@cs.toronto.edu> David Wolever added the comment: Ah, yes -- that may be the fault of the confusingly named 'check_both'. The "both" means "both when the module in question exists and when it does not". If you've got a better name, please change it! Take a look at the method and you'll see how it works. The problem is that testing this is a little tricky -- you've either got to give it files that you know exist, create files, or work some magic. I took the work some magic route, and replaced the "exists" method which fix_import imports from os (that way the tests can check the list of files which are being checked). See the test_files_checked method for that. __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 28 23:45:08 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 28 Mar 2008 22:45:08 +0000 Subject: [issue815646] thread unsafe file objects cause crash Message-ID: <1206744308.79.0.450831305038.issue815646@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Why hadn't I read #595601 in detail, it has an explanation: [quoting Jeremy Hylton] The universal newline code is squirrels the FILE * in a local variable, which is worse. If it happens that another thread closes the file, at best the local points to a closed FILE *. But that memory could get recycled and then there's no way to know what it points to. [/quoting] Even with careful coding, there's a small window between releasing the GIL on our side, and acquiring the FILE-specific lock in the glibc, during which the fclose() function can be invoked and release the FILE just before we invoke another function (e.g. fseek()) on it. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Mar 28 23:51:52 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 28 Mar 2008 22:51:52 +0000 Subject: [issue2388] Compiler warnings when using UCS4 In-Reply-To: <1205848812.38.0.436275134314.issue2388@psf.upfronthosting.co.za> Message-ID: <1206744712.84.0.206387110508.issue2388@psf.upfronthosting.co.za> Benjamin Peterson added the comment: This is because in UCS, Py_UNICODE is an unsigned long. In calls to PyErr_Format, the format specifier %c (int, the UCS2 Py_UNICODE) is given, so the compiler gives a warning. ---------- versions: -Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 00:13:34 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 28 Mar 2008 23:13:34 +0000 Subject: [issue1015989] compiler.transformer: correct lineno attribute when possible Message-ID: <1206746014.87.0.649460173541.issue1015989@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This patch was applied at r37285 (in svn terms). It looks like closing this issue was blocked by #1057835 which was deemed unrelated and resolved in any case. I suggest to close this issue. ---------- nosy: +belopolsky type: -> behavior _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 29 00:26:38 2008 From: report at bugs.python.org (Paul Kippes) Date: Fri, 28 Mar 2008 23:26:38 +0000 Subject: [issue2426] pysqlite provides no interface for database SQL dump In-Reply-To: <1205947581.08.0.648809036566.issue2426@psf.upfronthosting.co.za> Message-ID: <1206746798.36.0.433228862976.issue2426@psf.upfronthosting.co.za> Paul Kippes added the comment: Thanks so much. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 00:38:47 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 28 Mar 2008 23:38:47 +0000 Subject: [issue1015989] compiler.transformer: correct lineno attribute when possible Message-ID: <1206747527.03.0.179343179307.issue1015989@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> out of date status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 29 00:40:57 2008 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Fri, 28 Mar 2008 23:40:57 +0000 Subject: [issue1546263] Segfaults with concurrent sqlite db access and schema change Message-ID: <1206747657.76.0.0839870792538.issue1546263@psf.upfronthosting.co.za> Gerhard H?ring added the comment: Long fixed in 2.6 and 3.0 branches. Don't think it's worth fixing it in 2.5. ---------- resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 29 00:45:12 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Fri, 28 Mar 2008 23:45:12 +0000 Subject: [issue2497] stdbool support In-Reply-To: <47EC9D56.6000509@ghs.com> Message-ID: <47ED8305.8000505@v.loewis.de> Martin v. L?wis added the comment: > If stdbool is not available, C99 still defines false and true as macros. What do you mean by that? In C99, true and false are *not* defined in a translation unit unless stdbool.h is included, see 7.16. > If stdbool is available, then most compilers will define false and true > as macros. *In* the header file, that is. C99 *requires* the implementation to define true and false *only* in the header file, and *only* as macros. Anything else would not be conforming to C99. > In both cases, if stdbool was included by any system header in the > future, that would conflict with your current definition. No system header should ever include stdbool.h; doing so would be in violation of the standards. > Do you agree with these changes then? Not at all; I think the patch should be rejected. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 00:51:29 2008 From: report at bugs.python.org (Robert Siemer) Date: Fri, 28 Mar 2008 23:51:29 +0000 Subject: [issue1731717] race condition in subprocess module Message-ID: <1206748289.72.0.919073277194.issue1731717@psf.upfronthosting.co.za> Robert Siemer added the comment: Bad design stays bad design: the hope that pids don't get reused soon breaks two assumptions: 1) I don't have to wait() for a child process soon. It's the programs business. 2) Pids cycle: there are security patches to make pids of future processes hard to predict by assigning random free pids. I actually was about to report a bug on subprocess when I bumped into this one. My problem is pretty thread-less but related: How do I kill() a process if it's pid got recycled behind my back?? In my opinion the module should work the "Python" way of doing things, otherwise programmers will be surprised, as I was: a) don't do my work (no wait() for things I care of/have reference to) b) do your work (clean up things I don't care of/have no reference to) If that's not possible, how does subprocess actually "intends to replace os.spawn*"? [Library Reference] It is still possible to extend the Popen() call to reflect if the caller wants a P_NOWAITO or P_NOWAIT behavior, but the closer we get to the os, the less sense does it make to replace some other modules... ---------- nosy: +siemer _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 29 01:30:36 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 29 Mar 2008 00:30:36 +0000 Subject: [issue815646] thread unsafe file objects cause crash Message-ID: <1206750636.67.0.0119082989476.issue815646@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Some good news: I've found a way to continue with my approach and make it working. The close() method now raises an appropriate IOError when another method is being called from another thread. Attaching a patch, which protects a bunch of file object methods (together with tests). Now the bad news: the protection logic in fileobject.c is, hmm, a bit contrived (and I'm not even sure it's 100% correct). If someone wants to read it and put his veto before I go further... Added file: http://bugs.python.org/file9884/filethread2.patch ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Mar 29 01:39:36 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 29 Mar 2008 00:39:36 +0000 Subject: [issue595601] file (& socket) I/O are not thread safe Message-ID: <1206751176.17.0.980486174709.issue595601@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've posted a preliminary patch for the close()-should-raise-an-error approach here: #815646 ---------- nosy: +pitrou ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Mar 29 02:21:36 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:21:36 +0000 Subject: [issue1919] Backport of io.py In-Reply-To: <1201174901.71.0.122218114057.issue1919@psf.upfronthosting.co.za> Message-ID: <1206753696.46.0.0991488821066.issue1919@psf.upfronthosting.co.za> Georg Brandl added the comment: The bytearray branch has been merged. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 02:24:36 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:24:36 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206753876.9.0.259121905775.issue1751@psf.upfronthosting.co.za> Georg Brandl added the comment: Bumping priority so that this gets reviewed before next release. ---------- nosy: +georg.brandl priority: normal -> critical __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 02:25:50 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:25:50 +0000 Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6 In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za> Message-ID: <1206753950.17.0.73832347588.issue1745@psf.upfronthosting.co.za> Georg Brandl added the comment: Bumping priority. ---------- keywords: +26backport priority: normal -> critical __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 02:26:01 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:26:01 +0000 Subject: [issue2327] Backport keyword-only arguments to 2.6 In-Reply-To: <1205774336.48.0.251602118658.issue2327@psf.upfronthosting.co.za> Message-ID: <1206753961.63.0.36904744597.issue2327@psf.upfronthosting.co.za> Georg Brandl added the comment: #1745 already has a patch. ---------- nosy: +georg.brandl resolution: -> duplicate superseder: -> Backport of PEP 3102 "keyword-only arguments" to 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 02:26:08 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:26:08 +0000 Subject: [issue2327] Backport keyword-only arguments to 2.6 In-Reply-To: <1205774336.48.0.251602118658.issue2327@psf.upfronthosting.co.za> Message-ID: <1206753968.39.0.422566358567.issue2327@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 02:27:19 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:27:19 +0000 Subject: [issue815646] thread unsafe file objects cause crash Message-ID: <1206754039.64.0.317421528228.issue815646@psf.upfronthosting.co.za> Georg Brandl added the comment: Closed #595601 as a duplicate. ---------- nosy: +georg.brandl ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Mar 29 02:27:31 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:27:31 +0000 Subject: [issue595601] file (& socket) I/O are not thread safe Message-ID: <1206754051.58.0.800079218456.issue595601@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> duplicate status: open -> closed superseder: -> thread unsafe file objects cause crash ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Mar 29 02:30:40 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:30:40 +0000 Subject: [issue1717] Get rid of more refercenes to __cmp__ In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za> Message-ID: <1206754240.55.0.158094035382.issue1717@psf.upfronthosting.co.za> Georg Brandl added the comment: Bumping priority. ---------- nosy: +georg.brandl priority: normal -> critical __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 02:33:38 2008 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sat, 29 Mar 2008 01:33:38 +0000 Subject: [issue1625205] sqlite3 documentation omits: close(), commit(), autocommit Message-ID: <1206754418.27.0.246168238157.issue1625205@psf.upfronthosting.co.za> Gerhard H?ring added the comment: Fixed in r62026. Thanks for bringing this up. ---------- resolution: -> fixed status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 29 02:34:55 2008 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sat, 29 Mar 2008 01:34:55 +0000 Subject: [issue2500] Sync _sqlite module code In-Reply-To: <1206698671.09.0.0786877274007.issue2500@psf.upfronthosting.co.za> Message-ID: <1206754495.66.0.141145402107.issue2500@psf.upfronthosting.co.za> Gerhard H?ring added the comment: done. the py3k branch is now up-to-date wrt to the sqlite3 module. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 02:37:16 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:37:16 +0000 Subject: [issue1158] %f format for datetime objects In-Reply-To: <1189650403.5.0.731044089134.issue1158@psf.upfronthosting.co.za> Message-ID: <1206754636.68.0.371537957951.issue1158@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 02:41:15 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:41:15 +0000 Subject: [issue2430] Stop test_format.py from executing as side effect of import In-Reply-To: <1205987352.7.0.846357959052.issue2430@psf.upfronthosting.co.za> Message-ID: <1206754875.33.0.760797232171.issue2430@psf.upfronthosting.co.za> Georg Brandl added the comment: This seems to have been committed in r61925. ---------- nosy: +georg.brandl resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 02:43:37 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:43:37 +0000 Subject: [issue2479] Bytearray and io backport In-Reply-To: <1206443150.97.0.809624584179.issue2479@psf.upfronthosting.co.za> Message-ID: <1206755017.52.0.262447415161.issue2479@psf.upfronthosting.co.za> Georg Brandl added the comment: The branch has been merged in r61936. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 02:44:12 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:44:12 +0000 Subject: [issue1967] Backport dictviews to 2.6 In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za> Message-ID: <1206755052.37.0.498131833479.issue1967@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- keywords: +26backport __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 02:44:07 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:44:07 +0000 Subject: [issue1967] Backport dictviews to 2.6 In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za> Message-ID: <1206755047.87.0.0568732460079.issue1967@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- priority: normal -> critical __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 02:51:17 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:51:17 +0000 Subject: [issue1442] pythonstartup addition of minor error checking In-Reply-To: <1195013244.94.0.813010409666.issue1442@psf.upfronthosting.co.za> Message-ID: <1206755477.11.0.369354390641.issue1442@psf.upfronthosting.co.za> Georg Brandl added the comment: Backported to 2.6 in r62030 and 2.5 in r62031. ---------- nosy: +georg.brandl status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 02:54:49 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:54:49 +0000 Subject: [issue2310] Reorganize the 3.0 Misc/NEWS file In-Reply-To: <1205702758.46.0.979295500245.issue2310@psf.upfronthosting.co.za> Message-ID: <1206755689.78.0.613423512456.issue2310@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: georg.brandl -> gvanrossum __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 03:10:24 2008 From: report at bugs.python.org (Pierre Metras) Date: Sat, 29 Mar 2008 02:10:24 +0000 Subject: [issue2504] Add gettext.pgettext() and variants support In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za> Message-ID: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za> New submission from Pierre Metras : Please add support for pgettext(msgctxt, msgid) and variants (dpgettext, dcpgettext...) in the gettext module. I will not rephrase the justification for these functions and why contexts are essential for good localization: http://www.gnu.org/software/gettext/manual/gettext.html#Contexts ---------- components: Extension Modules messages: 64675 nosy: genepi severity: normal status: open title: Add gettext.pgettext() and variants support type: feature request versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 02:57:13 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:57:13 +0000 Subject: [issue965065] document docs.python.org in PEP-101 Message-ID: <1206755833.5.0.479561626842.issue965065@psf.upfronthosting.co.za> Georg Brandl added the comment: Leaving open as a reminder for coming rstdocs releases. ---------- priority: normal -> high ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Mar 29 02:55:38 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:55:38 +0000 Subject: [issue2176] Undocumented lastrowid attribute i sqlite3 cursor class In-Reply-To: <1203862408.41.0.133171732382.issue2176@psf.upfronthosting.co.za> Message-ID: <1206755738.58.0.179880663129.issue2176@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- priority: -> high __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 02:55:22 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:55:22 +0000 Subject: [issue2129] Link error of gethostbyaddr and gethostname in Python Manuals (the chm file) In-Reply-To: <1203179561.47.0.405991627355.issue2129@psf.upfronthosting.co.za> Message-ID: <1206755722.7.0.179951513966.issue2129@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- status: open -> pending __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 02:56:07 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 01:56:07 +0000 Subject: [issue1945] Document back ported C functions In-Reply-To: <1201445858.91.0.21119487494.issue1945@psf.upfronthosting.co.za> Message-ID: <1206755767.84.0.0831169244897.issue1945@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 04:05:06 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Sat, 29 Mar 2008 03:05:06 +0000 Subject: [issue2065] trunk version does not compile with vs8 and vc6 In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za> Message-ID: <1206759906.13.0.816290577747.issue2065@psf.upfronthosting.co.za> Changes by Hirokazu Yamamoto : Added file: http://bugs.python.org/file9885/ocean.zip __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 04:13:38 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 29 Mar 2008 03:13:38 +0000 Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za> Message-ID: <1206760418.84.0.680657199949.issue2464@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The problem does not appear to have anything to do with SSL. The problem is that the chain of HTTP requests goes: GET -> 302 -> 302 -> 301 On the final 301 urllib2's internal state is messed up such that by the time its in the handle_error_302 method it believes the Location header contains the following: 'http://www.wikispaces.com/\x00/?responseToken=481aec3249f429316459e01c00b7e522' The \x00 and everything after it should not be there and is not there if you look at what is sent over the socket itself. The ?responseToken=xxx value is leftover from the previous 302 response. No idea where the \x00 came from yet. I'm debugging... ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith priority: -> normal versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 04:41:54 2008 From: report at bugs.python.org (Koh Wei Jie) Date: Sat, 29 Mar 2008 03:41:54 +0000 Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za> Message-ID: <1206762114.63.0.146158823049.issue2464@psf.upfronthosting.co.za> Koh Wei Jie added the comment: Please take your time, because this bug isn't critical. Thanks! __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 04:47:29 2008 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 29 Mar 2008 03:47:29 +0000 Subject: [issue643841] New class special method lookup change Message-ID: <1206762449.43.0.276286197954.issue643841@psf.upfronthosting.co.za> Nick Coghlan added the comment: The 2.6 and 3.0 documentation has already been updated appropriately. The forward compatible way to handle this is to inherit from object and override the special methods explicitly in the 2.x version (Yes this can make writing proxy objects more tedious, but from our experience with the tempfile module, I would say that the bulk of proxy objects that aren't overriding special methods on a case-by-case basis are probably broken anyway). It may be appropriate to add a -3 warning that is triggered whenever a special method is retrieved via __getattr__ on a classic class. ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Mar 29 04:48:41 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 29 Mar 2008 03:48:41 +0000 Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za> Message-ID: <1206762521.45.0.804902137218.issue2464@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Instrumenting the code and looking closer at the tcpdump, its true. wikispaces.com is returning an invalid Location: header with a null byte in the middle of it. The "fix" on our end should be to handle such garbage from such broken web servers more gracefully. Other clients seem to treat the null as an end of string or end of that header. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 05:19:09 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 29 Mar 2008 04:19:09 +0000 Subject: [issue2464] urllib2 can't handle http://www.wikispaces.com In-Reply-To: <1206283270.11.0.221591174332.issue2464@psf.upfronthosting.co.za> Message-ID: <1206764349.55.0.983852676416.issue2464@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I'm not sure what the best solution for this is. If I truncate the header values at a \x00 character it ends in an infinite redirect loop (which urllib2 detects and raises on). If I simple remove all \x00 characters the resulting url is not accepted by wikispaces.com due to having an extra / in it. Verdict: wikispaces.com is broken. urllib2 could do better. wget and firefox deal with it properly. but i'll leave deciding which patch to use up to someone who cares about handling broken sites. patch to implement either behavior of dealing with nulls where they shouldn't be: Index: Lib/httplib.py =================================================================== --- Lib/httplib.py (revision 62033) +++ Lib/httplib.py (working copy) @@ -291,9 +291,18 @@ break headerseen = self.isheader(line) if headerseen: + # Some bad web servers reply with headers with a \x00 null + # embedded in the value. Other http clients deal with + # this by treating it as a value terminator, ignoring the + # rest so we will too. http://bugs.python.org/issue2464. + if '\x00' in line: + line = line[:line.find('\x00')] + # if you want to just remove nulls instead use this: + #line = line.replace('\x00', '') # It's a legal header line, save it. hlist.append(line) - self.addheader(headerseen, line[len(headerseen)+1:].strip()) + value = line[len(headerseen)+1:].strip() + self.addheader(headerseen, value) continue else: # It's not a header line; throw it back and stop here. ---------- assignee: gregory.p.smith -> priority: normal -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 05:25:12 2008 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 29 Mar 2008 04:25:12 +0000 Subject: [issue2429] Patch for test_urllib2_net moving tests to use a local server In-Reply-To: <1205968955.73.0.744201305439.issue2429@psf.upfronthosting.co.za> Message-ID: <1206764712.33.0.139543426928.issue2429@psf.upfronthosting.co.za> Gregory P. Smith added the comment: all buildbots seem happy with the new tests. ---------- status: pending -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 05:37:26 2008 From: report at bugs.python.org (David Remahl) Date: Sat, 29 Mar 2008 04:37:26 +0000 Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module In-Reply-To: <1190163754.35.0.664170861932.issue1179@psf.upfronthosting.co.za> Message-ID: <1206765446.73.0.162154386122.issue1179@psf.upfronthosting.co.za> David Remahl added the comment: The following test cases still cause bus errors with the patch applied: import imageop; imageop.rgb82rgb('A'*(2**30), 32768, 32768) import imageop; imageop.grey2rgb('A'*(2**30), 32768, 32768) ---------- nosy: +chmod007 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 05:48:28 2008 From: report at bugs.python.org (Neal Norwitz) Date: Sat, 29 Mar 2008 04:48:28 +0000 Subject: [issue2477] parser support for future import of unicode_strings In-Reply-To: <1206425748.68.0.392615437966.issue2477@psf.upfronthosting.co.za> Message-ID: <1206766108.54.0.235198743367.issue2477@psf.upfronthosting.co.za> Neal Norwitz added the comment: Christian checked this in a few days ago in r61953 and a few other revisions. ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 07:35:53 2008 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 29 Mar 2008 06:35:53 +0000 Subject: [issue1579] logging documentation is unclear In-Reply-To: <1197300194.46.0.863908405505.issue1579@psf.upfronthosting.co.za> Message-ID: <1206772553.15.0.445890488955.issue1579@psf.upfronthosting.co.za> Vinay Sajip added the comment: I don't believe that the logging documentation is particularly unclear, though of course it could always be improved, like most other documentation ;-) It certainly does not rely on prior experience of log4j; though some of the concepts are similar, the details are not. As per Facundo's comment, I'll certainly look at documentation patches - but I'll close this issue for now. If you would like to reopen, please submit a patch with specific suggested improvements. ---------- nosy: +vsajip resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 09:38:26 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 29 Mar 2008 08:38:26 +0000 Subject: [issue2504] Add gettext.pgettext() and variants support In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za> Message-ID: <1206779905.98.0.561097139347.issue2504@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Would you like to work on a patch? ---------- nosy: +loewis __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 10:18:00 2008 From: report at bugs.python.org (Wummel) Date: Sat, 29 Mar 2008 09:18:00 +0000 Subject: [issue2503] Replace "== None/True/False" with "is" In-Reply-To: <1206702410.08.0.751356671571.issue2503@psf.upfronthosting.co.za> Message-ID: <1206782280.2.0.154885087464.issue2503@psf.upfronthosting.co.za> Wummel added the comment: Here is an updated patch, using "is False" to be consistent, and also replacing the "!=" occurences. Added file: http://bugs.python.org/file9886/0001-Replace-None-True-False-with-is.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 10:18:27 2008 From: report at bugs.python.org (Wummel) Date: Sat, 29 Mar 2008 09:18:27 +0000 Subject: [issue2503] Replace "== None/True/False" with "is" In-Reply-To: <1206702410.08.0.751356671571.issue2503@psf.upfronthosting.co.za> Message-ID: <1206782307.87.0.963436422788.issue2503@psf.upfronthosting.co.za> Changes by Wummel : Removed file: http://bugs.python.org/file9882/0001-Replace-None-True-False-with-is.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 10:47:32 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 29 Mar 2008 09:47:32 +0000 Subject: [issue2503] Replace "== None/True/False" with "is" In-Reply-To: <1206702410.08.0.751356671571.issue2503@psf.upfronthosting.co.za> Message-ID: <1206784052.84.0.171914612861.issue2503@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This patch is fine. Before applying, check the code in PyShell to see if the "if response is False" line can be simplified to "if not response". ---------- nosy: +rhettinger resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 10:53:48 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 09:53:48 +0000 Subject: [issue2503] Replace "== None/True/False" with "is" In-Reply-To: <1206702410.08.0.751356671571.issue2503@psf.upfronthosting.co.za> Message-ID: <1206784428.4.0.731198395633.issue2503@psf.upfronthosting.co.za> Georg Brandl added the comment: Benjamin, do you want to apply this? Add a Misc/NEWS item as well. ---------- assignee: -> benjamin.peterson nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 10:58:03 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 29 Mar 2008 09:58:03 +0000 Subject: [issue2502] Add enum() example for named tuples In-Reply-To: <1206702319.7.0.998063864211.issue2502@psf.upfronthosting.co.za> Message-ID: <1206784683.65.0.733745003333.issue2502@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks for asking. This should not go into the collections module. The concept makes more sense in statically compiled languages. In Python, we typically write something like "RED, ORANGE, YELLOW = range (3)" at the module level. That is faster and still allows prefixing using the module name (for example, re.MULTILINE). ---------- resolution: accepted -> rejected __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 11:08:16 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 29 Mar 2008 10:08:16 +0000 Subject: [issue2503] Replace "== None/True/False" with "is" In-Reply-To: <1206702410.08.0.751356671571.issue2503@psf.upfronthosting.co.za> Message-ID: <1206785296.22.0.0576053450114.issue2503@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Don't think changes like this warrant a NEWS entry. It's a code clean- up, not a semantic change. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 14:38:10 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 13:38:10 +0000 Subject: [issue2505] Restrict attributes of _ast nodes In-Reply-To: <1206797890.8.0.128090233535.issue2505@psf.upfronthosting.co.za> Message-ID: <1206797890.8.0.128090233535.issue2505@psf.upfronthosting.co.za> New submission from Georg Brandl : This patch adds two things to the _ast module: * Nodes can be initialized with keyword arguments: m = _ast.Module(body=[...]) * Only attributes that are in _fields or _attributes can be set on nodes. Martin, what do you think? ---------- assignee: loewis components: Extension Modules files: ast-attrs.diff keywords: patch messages: 64691 nosy: georg.brandl, loewis severity: normal status: open title: Restrict attributes of _ast nodes type: behavior versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9887/ast-attrs.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 14:38:41 2008 From: report at bugs.python.org (Ned Batchelder) Date: Sat, 29 Mar 2008 13:38:41 +0000 Subject: [issue2506] Line tracing of continue after always-taken if is incorrect In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> New submission from Ned Batchelder : When tracing line execution with sys.settrace, a particular code structure fails to report an executed line. The line is a continue statement after an if condition in which the if condition is true every time it is executed. Attached is a file with two copies of the same code, except in the first the if condition is always true, and in the second it is sometimes true. In the first, trace.py reports that the continue is never executed, even though it is (as evidenced from the values of a, b, and c after execution). In the second code, the continue is properly reported. This bug has been present since version 2.3. 2.2 does not exhibit it (trace.py didn't exist in 2.2, but coverage.py shows the problem also). To see the problem, execute "trace.py -c -m continue.py". Then continue.py.cover will show: 1: a = b = c = 0 101: for n in range(100): 100: if n % 2: 50: if n % 4: 50: a += 1 >>>>>> continue else: 50: b += 1 50: c += 1 1: assert a == 50 and b == 50 and c == 50 1: a = b = c = 0 101: for n in range(100): 100: if n % 2: 50: if n % 3: 33: a += 1 17: continue else: 50: b += 1 50: c += 1 1: assert a == 33 and b == 50 and c == 50 ---------- components: Interpreter Core files: continue.py messages: 64692 nosy: nedbat severity: normal status: open title: Line tracing of continue after always-taken if is incorrect type: behavior versions: Python 2.3, Python 2.4, Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9888/continue.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 14:40:35 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 13:40:35 +0000 Subject: [issue2505] Restrict attributes of _ast nodes In-Reply-To: <1206797890.8.0.128090233535.issue2505@psf.upfronthosting.co.za> Message-ID: <1206798035.95.0.985686119442.issue2505@psf.upfronthosting.co.za> Georg Brandl added the comment: On second thought, restricting node attributes may prevent custom AST processing tools from adding useful information themselves... __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 14:48:40 2008 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sat, 29 Mar 2008 13:48:40 +0000 Subject: [issue2152] make sqlite.Row hashable correctly In-Reply-To: <1203590912.21.0.769567830293.issue2152@psf.upfronthosting.co.za> Message-ID: <1206798520.03.0.938820275041.issue2152@psf.upfronthosting.co.za> Gerhard H?ring added the comment: Thomas, could you do me a favour and create a patch for Python 3.0, too? It seems that only tp_richcompare is supported there. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 14:50:49 2008 From: report at bugs.python.org (Kylotan) Date: Sat, 29 Mar 2008 13:50:49 +0000 Subject: [issue1579] logging documentation is unclear In-Reply-To: <1197300194.46.0.863908405505.issue1579@psf.upfronthosting.co.za> Message-ID: <1206798649.85.0.76627879297.issue1579@psf.upfronthosting.co.za> Kylotan added the comment: I think I gave some pretty clear details in my original submission. A better example on the front page is needed rather than one that could be confused with output methods. The example in 14.5.3 needs to not be one big code dump with no explanation other than comments. I could go on: the front page talks about named logger instances, and yet the basic example completely omits any mention of such instances, instead using module-level calls. You have to dig into the middle of the example in 14.5.3 to see what this means, and because that example isn't well explained, it's still not clear. It seems to have 2 loggers attached to the root, but I can't see what benefit that gives, since there's no example showing that logging sent to the root goes to the children (does it?), nor does the reverse happen. Examples should show one or two things, not try to demonstrate every feature in a code dump and expect you to guess which parts do what. As for submitting a patch, the whole problem with documentation is that if you don't understand it, you can't use the software, so how could such a person possibly know exactly what should go in the patch? It needs to be written from the perspective of someone who has never used it before, which right now it plainly isn't. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 15:01:22 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 29 Mar 2008 14:01:22 +0000 Subject: [issue2078] CSV Sniffer does not function properly on single column .csv files In-Reply-To: <1202832132.24.0.528453630912.issue2078@psf.upfronthosting.co.za> Message-ID: <1206799282.37.0.305030349564.issue2078@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > It works entirely based on chracter frequencies. Does it make sense to restrict delimiters to a reasonable set of characters? Usual punctuations, spaces, tabs... what else? ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 15:28:38 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 29 Mar 2008 14:28:38 +0000 Subject: [issue2507] Exception state lives too long in 3.0 In-Reply-To: <1206800918.45.0.478667091266.issue2507@psf.upfronthosting.co.za> Message-ID: <1206800918.45.0.478667091266.issue2507@psf.upfronthosting.co.za> New submission from Antoine Pitrou : See http://mail.python.org/pipermail/python-3000/2008-March/012830.html : the exception state can survive across thread switches if the enclosing frame is not destroyed immediately. ---------- components: Interpreter Core messages: 64697 nosy: jyasskin, pitrou severity: normal status: open title: Exception state lives too long in 3.0 type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 15:35:22 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 29 Mar 2008 14:35:22 +0000 Subject: [issue2507] Exception state lives too long in 3.0 In-Reply-To: <1206800918.45.0.478667091266.issue2507@psf.upfronthosting.co.za> Message-ID: <1206801322.72.0.265855621444.issue2507@psf.upfronthosting.co.za> Antoine Pitrou added the comment: And this is a patch, together with a test. ---------- keywords: +patch Added file: http://bugs.python.org/file9889/exc_cleanup.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 15:41:52 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 29 Mar 2008 14:41:52 +0000 Subject: [issue2506] Line tracing of continue after always-taken if is incorrect In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1206801712.62.0.747187452322.issue2506@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This is because of a "peephole" optimization of the generated bytecode: a jump instruction which target is another jump instruction can be modified modified to target the final location. You gain a few opcodes, but tracing is confusing... Not sure how to fix this, though. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 15:49:18 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 29 Mar 2008 14:49:18 +0000 Subject: [issue2505] Restrict attributes of _ast nodes In-Reply-To: <1206798035.95.0.985686119442.issue2505@psf.upfronthosting.co.za> Message-ID: <47EE56EB.5000700@v.loewis.de> Martin v. L?wis added the comment: > On second thought, restricting node attributes may prevent custom AST > processing tools from adding useful information themselves... Indeed. If anything is to be checked, it should be whether the child nodes or attributes have the right types. However, that should rather be done in a recursive check function on _mod, which then would also check whether all necessary fields have been set. Or, such checks could be delayed until actual compilation of the tree is attempted (i.e. conversion to the C AST structures). As for being able to pass constructor arguments: I'd expect them to be positional arguments, not keyword arguments - anybody creating AST nodes would normally have Python.asdl open, no? __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 16:15:27 2008 From: report at bugs.python.org (Skip Montanaro) Date: Sat, 29 Mar 2008 15:15:27 +0000 Subject: [issue2078] CSV Sniffer does not function properly on single column .csv files In-Reply-To: <1206799282.37.0.305030349564.issue2078@psf.upfronthosting.co.za> Message-ID: <18414.23817.630359.900652@montanaro-dyndns-org.local> Skip Montanaro added the comment: >> It works entirely based on chracter frequencies. Amaury> Does it make sense to restrict delimiters to a reasonable set of Amaury> characters? Usual punctuations, spaces, tabs... what else? There is an optional delimiters argument to the sniff() method which defaults to None. I would be happier if it was "the usual suspects" (NeoOffice refuses to gues, but offers TAB, space, semicolon and comma as the default separators when importing a CSV file - Excel seems to just figure it out). That would change the behavior though. With no delimiter set it's generally going to find something, just pick incorrectly. With a non-existent delimiter set it's going to raise an exception. I'm not sure this would be a good tradeoff and would just break existing code. Skip __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 16:25:07 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 29 Mar 2008 15:25:07 +0000 Subject: [issue2503] Replace "== None/True/False" with "is" In-Reply-To: <1206702410.08.0.751356671571.issue2503@psf.upfronthosting.co.za> Message-ID: <1206804307.91.0.205452710913.issue2503@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Patch was committed in r62043. Wummel, thanks for the patch! Georg, thanks for the practice. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 16:55:35 2008 From: report at bugs.python.org (kobi) Date: Sat, 29 Mar 2008 15:55:35 +0000 Subject: [issue2508] When you create a file using file(path, "w") if the filename is illegal it throws an irrelevant error message Message-ID: <1206806135.36.0.409722603539.issue2508@psf.upfronthosting.co.za> Changes by kobi : ---------- nosy: kobipe3 severity: normal status: open title: When you create a file using file(path, "w") if the filename is illegal it throws an irrelevant error message type: resource usage versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 16:56:46 2008 From: report at bugs.python.org (kobi) Date: Sat, 29 Mar 2008 15:56:46 +0000 Subject: [issue2508] When you create a file using file(path, "w") if the filename is illegal it throws an irrelevant error message In-Reply-To: <1206806206.89.0.612203172817.issue2508@psf.upfronthosting.co.za> Message-ID: <1206806206.89.0.612203172817.issue2508@psf.upfronthosting.co.za> New submission from kobi : It throws an IOError: ... No such file or directory: %path% instead of IOError: Invalid file name. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 17:00:36 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 29 Mar 2008 16:00:36 +0000 Subject: [issue1054434] automatic XMLRPC boxcarring via multicall for xmlrpclib Message-ID: <1206806436.86.0.322675013831.issue1054434@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As nobody has asked for this patch to be included, I think its probably easiest just to reject it. Thanks for offering it in the first place, though. ---------- resolution: -> rejected status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Mar 29 17:10:02 2008 From: report at bugs.python.org (Facundo Batista) Date: Sat, 29 Mar 2008 16:10:02 +0000 Subject: [issue2508] When you create a file using file(path, "w") if the filename is illegal it throws an irrelevant error message In-Reply-To: <1206806206.89.0.612203172817.issue2508@psf.upfronthosting.co.za> Message-ID: <1206807002.51.0.423019515821.issue2508@psf.upfronthosting.co.za> Facundo Batista added the comment: How do you know, in a cross platform way, that the name is illegal instead that the file or directory does not exist? ---------- nosy: +facundobatista __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 17:34:02 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 29 Mar 2008 16:34:02 +0000 Subject: [issue2508] When you create a file using file(path, "w") if the filename is illegal it throws an irrelevant error message In-Reply-To: <1206806206.89.0.612203172817.issue2508@psf.upfronthosting.co.za> Message-ID: <1206808442.47.0.0473178020748.issue2508@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is not a bug in Python. The error that you get comes directly from the operating system/C library, so please complain to your system vendor. ---------- nosy: +loewis resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 18:07:02 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 29 Mar 2008 17:07:02 +0000 Subject: [issue2509] Bazaar ignore file In-Reply-To: <1206810422.5.0.478405887603.issue2509@psf.upfronthosting.co.za> Message-ID: <1206810422.5.0.478405887603.issue2509@psf.upfronthosting.co.za> New submission from Benjamin Peterson : I basically copied all the svn:ignore props into this file... ---------- components: None files: bzr-ignore.patch keywords: easy, patch messages: 64707 nosy: barry, benjamin.peterson, georg.brandl severity: normal status: open title: Bazaar ignore file type: feature request Added file: http://bugs.python.org/file9890/bzr-ignore.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 18:07:11 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 29 Mar 2008 17:07:11 +0000 Subject: [issue2510] Bazaar ignore file In-Reply-To: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za> Message-ID: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za> New submission from Benjamin Peterson : I basically copied all the svn:ignore props into this file... ---------- components: None files: bzr-ignore.patch keywords: easy, patch messages: 64708 nosy: barry, benjamin.peterson, georg.brandl severity: normal status: open title: Bazaar ignore file type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file9891/bzr-ignore.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 18:12:11 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 29 Mar 2008 17:12:11 +0000 Subject: [issue2509] Bazaar ignore file In-Reply-To: <1206810422.5.0.478405887603.issue2509@psf.upfronthosting.co.za> Message-ID: <1206810731.08.0.438394220035.issue2509@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> duplicate status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 18:49:35 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 17:49:35 +0000 Subject: [issue2510] Bazaar ignore file In-Reply-To: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za> Message-ID: <1206812975.63.0.156139390605.issue2510@psf.upfronthosting.co.za> Georg Brandl added the comment: I don't know if we should pollute the SVN tree with random VCS stuff. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 18:56:01 2008 From: report at bugs.python.org (Jeroen Ruigrok van der Werven) Date: Sat, 29 Mar 2008 17:56:01 +0000 Subject: [issue2510] Bazaar ignore file In-Reply-To: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za> Message-ID: <1206813361.13.0.712297389739.issue2510@psf.upfronthosting.co.za> Jeroen Ruigrok van der Werven added the comment: Given how Bazaar is not an official choice for the repository adding this kind of thing will lead to a road to add such information for Hg and other VCSes as well in order to be fair to all. ---------- nosy: +asmodai __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 19:12:10 2008 From: report at bugs.python.org (Christian Heimes) Date: Sat, 29 Mar 2008 18:12:10 +0000 Subject: [issue2507] Exception state lives too long in 3.0 In-Reply-To: <1206800918.45.0.478667091266.issue2507@psf.upfronthosting.co.za> Message-ID: <1206814330.01.0.861811177632.issue2507@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- priority: -> release blocker __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 19:13:49 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 29 Mar 2008 18:13:49 +0000 Subject: [issue2510] Bazaar ignore file In-Reply-To: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za> Message-ID: <1206814429.64.0.216021611146.issue2510@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I'd like to get Barry's opinion on this, since he added the experimental Bazaar branches. I think it's reasonable as long as they're "offical" VCS branches. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 19:18:53 2008 From: report at bugs.python.org (Jeroen Ruigrok van der Werven) Date: Sat, 29 Mar 2008 18:18:53 +0000 Subject: [issue2510] Bazaar ignore file In-Reply-To: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za> Message-ID: <1206814732.97.0.677580415707.issue2510@psf.upfronthosting.co.za> Jeroen Ruigrok van der Werven added the comment: But isn't that Bazaar thing totally stand-alone from the SVN repository? What experimental branches are you talking about? __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 19:25:17 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 29 Mar 2008 18:25:17 +0000 Subject: [issue2506] Line tracing of continue after always-taken if is incorrect In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1206815117.79.0.709308031464.issue2506@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I think this is not a bug. Here is a simpler way to illustrate the issue: def f(x): for i in range(10): if x: pass continue f(True) f(False) If you run the code above under trace, you get the following coverage: 1: def f(x): 22: for i in range(10): 20: if x: 10: pass 10: continue 1: f(True) 1: f(False) Note that the 'continue' line is executed 10 instead of expected 20 times. This happens exactly as Amaury explained. If you disassemble f, you'll see 2 0 SETUP_LOOP 34 (to 37) 3 LOAD_GLOBAL 0 (range) 6 LOAD_CONST 1 (10) 9 CALL_FUNCTION 1 12 GET_ITER >> 13 FOR_ITER 20 (to 36) 16 STORE_FAST 1 (i) 3 19 LOAD_FAST 0 (x) 22 JUMP_IF_FALSE 4 (to 29) 25 POP_TOP 4 26 JUMP_ABSOLUTE 13 >> 29 POP_TOP 5 30 JUMP_ABSOLUTE 13 33 JUMP_ABSOLUTE 13 >> 36 POP_BLOCK >> 37 LOAD_CONST 0 (None) 40 RETURN_VALUE Note how peephole optimizer replaced jump to the 'continue' line (5) from the 'pass' line (4) with a jump to the 'for' line by replacing 4 26 JUMP_FORWARD 1 (to 30) with 4 26 JUMP_ABSOLUTE 13 I say this is not a bug because trace is correct in showing that the continue statement is never reached when executing f(True). ---------- nosy: +belopolsky __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 19:30:08 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 18:30:08 +0000 Subject: [issue2511] Give AST's excepthandler proper attributes In-Reply-To: <1206815408.44.0.121788242529.issue2511@psf.upfronthosting.co.za> Message-ID: <1206815408.44.0.121788242529.issue2511@psf.upfronthosting.co.za> New submission from Georg Brandl : The ASDL file has an XXX comment about excepthandler's lineno and col_offset -- they are not attributes but fields which gets confusing when this is exported to Python code. I think the only way to solve this is to make it a "trivial" Sum with one element. This patch does that. ---------- assignee: loewis components: Interpreter Core files: ast-except.diff keywords: patch messages: 64714 nosy: georg.brandl, loewis severity: normal status: open title: Give AST's excepthandler proper attributes versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9892/ast-except.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 19:31:46 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 18:31:46 +0000 Subject: [issue2505] Easier creation of _ast nodes In-Reply-To: <1206797890.8.0.128090233535.issue2505@psf.upfronthosting.co.za> Message-ID: <1206815506.18.0.898942038471.issue2505@psf.upfronthosting.co.za> Georg Brandl added the comment: Okay, I'm dropping the attribute restriction part. Attaching new patch that allows creating nodes with fields (not attributes) as positional arguments, and setting all keyword arguments as attributes on self. ---------- title: Restrict attributes of _ast nodes -> Easier creation of _ast nodes Added file: http://bugs.python.org/file9893/ast-constructor-v2.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 19:51:39 2008 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sat, 29 Mar 2008 18:51:39 +0000 Subject: [issue2215] test_sqlite fails in 2.6a1 on MacOS X In-Reply-To: <1204422139.64.0.558749633793.issue2215@psf.upfronthosting.co.za> Message-ID: <1206816699.19.0.667999493899.issue2215@psf.upfronthosting.co.za> Changes by Gerhard H?ring : ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 19:51:55 2008 From: report at bugs.python.org (Ned Batchelder) Date: Sat, 29 Mar 2008 18:51:55 +0000 Subject: [issue2506] Line tracing of continue after always-taken if is incorrect In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1206816715.58.0.206737589611.issue2506@psf.upfronthosting.co.za> Ned Batchelder added the comment: I see that the cause of the problem is the peephole optimizer. That doesn't mean this isn't a problem. I am measuring the code coverage of a set of tests, and one of my lines is being marked as not executed. This is not the fault of the tests, because in fact, without the optimization, the line would be executed. Conceptually, the line has been executed (the loop is restarted, rather than execution continuing). I don't know what the solution to this is. Some options include fixing the line tracing code to somehow indicate that the continue was executed; or providing a way to disable peephole optimization for times when accurate execution tracing is more important than speed. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 19:53:12 2008 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sat, 29 Mar 2008 18:53:12 +0000 Subject: [issue2441] Mac build_install.py script fetches unavailable SQLite version In-Reply-To: <1206052647.34.0.885320572694.issue2441@psf.upfronthosting.co.za> Message-ID: <1206816792.78.0.11940279388.issue2441@psf.upfronthosting.co.za> Changes by Gerhard H?ring : ---------- assignee: -> ghaering nosy: +ghaering __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 19:53:50 2008 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sat, 29 Mar 2008 18:53:50 +0000 Subject: [issue2176] Undocumented lastrowid attribute i sqlite3 cursor class In-Reply-To: <1203862408.41.0.133171732382.issue2176@psf.upfronthosting.co.za> Message-ID: <1206816830.58.0.404067392544.issue2176@psf.upfronthosting.co.za> Changes by Gerhard H?ring : ---------- assignee: georg.brandl -> ghaering nosy: +ghaering __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 20:12:55 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 29 Mar 2008 19:12:55 +0000 Subject: [issue2510] Bazaar ignore file In-Reply-To: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za> Message-ID: <1206817975.16.0.0623915720367.issue2510@psf.upfronthosting.co.za> Benjamin Peterson added the comment: http://www.python.org/dev/bazaar/ __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 20:12:56 2008 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sat, 29 Mar 2008 19:12:56 +0000 Subject: [issue2176] Undocumented lastrowid attribute i sqlite3 cursor class In-Reply-To: <1203862408.41.0.133171732382.issue2176@psf.upfronthosting.co.za> Message-ID: <1206817976.43.0.133775411235.issue2176@psf.upfronthosting.co.za> Gerhard H?ring added the comment: The lastrowid attribute is now documented in r62044. Thanks for bringing this up. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 20:39:34 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 29 Mar 2008 19:39:34 +0000 Subject: [issue815646] thread unsafe file objects cause crash Message-ID: <1206819574.48.0.449446302919.issue815646@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Actually, my approach was not 100% correct, it failed in some rare cases. I've come to the conclusion that using an unlock count on the PyFileObject is the correct way to proceed. I'm now attaching a working and complete patch which protects all methods of the PyFileObject. The original test suite runs fine, as well as the added test cases and Tim Peters' crasher here: http://mail.python.org/pipermail/python-dev/2003-June/036537.html To sum up the changes brought by this patch: - no supplementary locking - but each time we release the GIL to do an operation on a FILE, we increase a dedicated counter on the PyFileObject - when close()ing a PyFileObject, if the aforementioned counter is non-zero, we throw an IOError rather than risking calling fclose(). By construction this cannot happen in the PyFileObject destructor, but if ever it happens (for example if a C extension decides to put its hands in the PyFileObject struct), we throw a SystemError instead. Added file: http://bugs.python.org/file9894/filethread3.patch ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Mar 29 20:42:20 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 29 Mar 2008 19:42:20 +0000 Subject: [issue2506] Line tracing of continue after always-taken if is incorrect In-Reply-To: <1206816715.58.0.206737589611.issue2506@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Sat, Mar 29, 2008 at 2:51 PM, Ned Batchelder wrote: > > Ned Batchelder added the comment: > > I am measuring the code coverage of a set of tests, and one of my lines > is being marked as not executed. This is not the fault of the tests, > because in fact, without the optimization, the line would be executed. > Conceptually, the line has been executed (the loop is restarted, rather > than execution continuing). > .. but the continue statement on line 5 is NOT executed in x == True case. Note that without optimization, the if statement + the continue line translate to 3 19 LOAD_FAST 0 (x) 22 JUMP_IF_FALSE 4 (to 29) 25 POP_TOP 4 26 JUMP_FORWARD 1 (to 30) >> 29 POP_TOP 5 >> 30 JUMP_ABSOLUTE 13 where the second jump is to the continue statement. Peephole optimizer recognizes that the jump target is an unconditional jump and changes the code to jump directly to the final target bypassing the continue line. The optimized code is 3 19 LOAD_FAST 0 (x) 22 JUMP_IF_FALSE 4 (to 29) 25 POP_TOP 4 26 JUMP_ABSOLUTE 13 >> 29 POP_TOP 5 30 JUMP_ABSOLUTE 13 If x is true, line five is NOT executed. > I don't know what the solution to this is. Some options include fixing > the line tracing code to somehow indicate that the continue was > executed; or providing a way to disable peephole optimization for times > when accurate execution tracing is more important than speed. > I think it is a good idea to provide a way to disable peephole optimizer. In fact, I recently proposed exactly that in msg64638. My only problem is that I would like to follow gcc tradition and make -O option take an optional numeric argument with 0 meaning no optimization and increasingly aggressive optimization as the argument increases. Unfortunately -O0 will be confusingly similar to -OO. Since -OO is not really optimization, but rather "strip" option, it should probably migrate to -s or something. In any case, such drastic changes to command line options are not acceptable for 2.x, but maybe possible for 3.0. I can easily implement -N (No optimization) or -g (debug) option that will disable the peephole optimizer if there is support for such feature. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 20:59:38 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 29 Mar 2008 19:59:38 +0000 Subject: [issue2511] Give AST's excepthandler proper attributes In-Reply-To: <1206815408.44.0.121788242529.issue2511@psf.upfronthosting.co.za> Message-ID: <1206820778.17.0.209500286463.issue2511@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Sounds fine to me. ---------- assignee: loewis -> georg.brandl resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 21:03:13 2008 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 29 Mar 2008 20:03:13 +0000 Subject: [issue2505] Easier creation of _ast nodes In-Reply-To: <1206797890.8.0.128090233535.issue2505@psf.upfronthosting.co.za> Message-ID: <1206820993.75.0.312959910346.issue2505@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Looks fine to me. It might be reasonable to further restrict the constructor to either 0 or len(_fields) arguments. ---------- assignee: loewis -> georg.brandl resolution: -> accepted __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 21:14:26 2008 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 29 Mar 2008 20:14:26 +0000 Subject: [issue2473] logging.LogRecord should know how to handle dict-like args In-Reply-To: <1206366966.49.0.127979087555.issue2473@psf.upfronthosting.co.za> Message-ID: <1206821666.65.0.740093814486.issue2473@psf.upfronthosting.co.za> Vinay Sajip added the comment: You don't need to change the logging package for this. Simply generate a bona-fide dict from your UserDict or DictMixin subclass as follows: dict(userDict_or_mixIn_instance) and pass that into the logging call instead of userDict_or_mixIn_instance. ---------- assignee: -> vsajip nosy: +vsajip resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 21:39:28 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 29 Mar 2008 20:39:28 +0000 Subject: [issue815646] thread unsafe file objects cause crash Message-ID: <1206823168.02.0.433116520759.issue815646@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ah, I had forgotten to protect the print statement as well. Here is a new patch :-) Added file: http://bugs.python.org/file9895/filethread4.patch ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sat Mar 29 21:50:41 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 29 Mar 2008 20:50:41 +0000 Subject: [issue2506] Line tracing of continue after always-taken if is incorrect In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1206823841.43.0.160817176594.issue2506@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > Unfortunately -O0 will be confusingly similar to -OO. On my browser, both are shown identically at the pixel level. Microsoft compilers use -Od to disable optimization... __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 21:58:20 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 29 Mar 2008 20:58:20 +0000 Subject: [issue2506] Line tracing of continue after always-taken if is incorrect In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1206824300.2.0.424117647453.issue2506@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This has basically almost never been a problem in the real world. No need to complicate the world further by adding yet another option and the accompanying implementation-specific knowledge of why you would ever want to use it. Also, when the peepholer is moved (after the AST is created, but before the opcodes), then little oddities like this will go away. Recommend closing as "won't fix". ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 22:07:33 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Sat, 29 Mar 2008 21:07:33 +0000 Subject: [issue2510] Bazaar ignore file In-Reply-To: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za> Message-ID: <1206824853.52.0.575936714582.issue2510@psf.upfronthosting.co.za> Ralf Schmitt added the comment: it should be no problem to add this to the bzr repository. this is where it belongs. ---------- nosy: +schmir __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 22:19:16 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 29 Mar 2008 21:19:16 +0000 Subject: [issue2510] Bazaar ignore file In-Reply-To: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za> Message-ID: <1206825556.93.0.279417981955.issue2510@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I don't think that will work (at the moment.) The Bazaar repo is an exact copy (on a cron job) of the Subversion one, so we can't add files. Also, those using bzr-svn would miss out on the .bzrignore file. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 22:19:29 2008 From: report at bugs.python.org (Ned Batchelder) Date: Sat, 29 Mar 2008 21:19:29 +0000 Subject: [issue2506] Line tracing of continue after always-taken if is incorrect In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1206825569.18.0.815058272969.issue2506@psf.upfronthosting.co.za> Ned Batchelder added the comment: I recognize that this is an unusual case, but it did come up in the real world. I found this while measuring test coverage, and the continue line was marked as not executed, when it was. I don't understand "when the peepholer is moved", so maybe you are right that this will no longer be an issue. But it seems to me to be endemic to code optimization to lose the one-to-one correspondence between source lines and ranges of bytecodes. And as the compiler becomes more complex and performs more optmizations, problems like this will likely increase, no? In any case, I'd like to know more about the changes planned for the AST and compiler... __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 22:28:01 2008 From: report at bugs.python.org (Georg Brandl) Date: Sat, 29 Mar 2008 21:28:01 +0000 Subject: [issue2510] Bazaar ignore file In-Reply-To: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za> Message-ID: <1206826081.74.0.485352407943.issue2510@psf.upfronthosting.co.za> Georg Brandl added the comment: Wouldn't it be the job of the synchronisation job to automatically create a .bzrignore file from the SVN ignore properties? __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 22:34:22 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 29 Mar 2008 21:34:22 +0000 Subject: [issue2510] Bazaar ignore file In-Reply-To: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za> Message-ID: <1206826462.32.0.899619205042.issue2510@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Automation would be wonderful, but that still doesn't solve bzr-svn problem. In the future, bzr-svn should be able to deal with svn:ignore props, but it can't now. Should the Bazaar experiment fail, I'd just like to remind you that "environmental cleanup" (aka pollution removal) is only one "svn rm" away... __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 23:03:47 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 29 Mar 2008 22:03:47 +0000 Subject: [issue2510] Bazaar ignore file In-Reply-To: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za> Message-ID: <1206828227.02.0.876019776329.issue2510@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Personally, I think it would be fine to add one .bzrignore file at the top of the tree. I would also have no problem adding one for hg if some Mercurial fan asks for it. As you say, cleaning up afterward is a simple 'rm' away. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 23:08:32 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 29 Mar 2008 22:08:32 +0000 Subject: [issue2512] decide what to do with gettext API In-Reply-To: <1206828512.7.0.626832335532.issue2512@psf.upfronthosting.co.za> Message-ID: <1206828512.7.0.626832335532.issue2512@psf.upfronthosting.co.za> New submission from Benjamin Peterson : The gettext module currently has functions and methods beginning with "u" to designate functions which return unicode objects. The install function/method also has a "unicode" parameter. These are obviously useless in Py3k. The attached patch removes the u prefixed functions and and unicode parameters. Docs updates are included. PS. If you're interested, the Bazaar branch I developed this on is at http://code.python.org/python/users/benjamin.peterson/py3k_gettext_api/. ---------- components: Library (Lib) keywords: patch messages: 64733 nosy: barry, benjamin.peterson priority: critical severity: normal status: open title: decide what to do with gettext API type: feature request versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 23:18:56 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 29 Mar 2008 22:18:56 +0000 Subject: [issue2512] decide what to do with gettext API In-Reply-To: <1206828512.7.0.626832335532.issue2512@psf.upfronthosting.co.za> Message-ID: <1206829136.69.0.0996032242408.issue2512@psf.upfronthosting.co.za> Changes by Benjamin Peterson : Added file: http://bugs.python.org/file9896/gettext_api.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Mar 29 23:50:57 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Sat, 29 Mar 2008 22:50:57 +0000 Subject: [issue2507] Exception state lives too long in 3.0 In-Reply-To: <1206800918.45.0.478667091266.issue2507@psf.upfronthosting.co.za> Message-ID: <1206831057.36.0.325985673269.issue2507@psf.upfronthosting.co.za> Jeffrey Yasskin added the comment: Thanks for the patch. This isn't specific to threads at all, so the test doesn't need to spawn a thread, just raise an exception from a nested function with a parameter, catch it, delete the object the parameter referred to, and then check that the object has been destroyed. I don't know the exception handling code very well, so I'd like someone more familiar with it to check that the patch is correct and efficient. Collin, would you do the honors? ---------- assignee: -> collinwinter nosy: +collinwinter __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 00:08:53 2008 From: report at bugs.python.org (Jeffrey C. Jacobs) Date: Sat, 29 Mar 2008 23:08:53 +0000 Subject: [issue433030] SRE: Atomic Grouping (?>...) is not supported Message-ID: <1206832133.0.0.197635538536.issue433030@psf.upfronthosting.co.za> Jeffrey C. Jacobs added the comment: I'm digging into the sre_parse.py at the moment and this I have all the changes I need for that now. The rest of the changes I believe are in either sre_compile.py or more likely directly in _sre.c, so I will examine those files next. I am attaching a single diff for expedience. This is not an official patch, just a sample to see the progress I am making. I forgot the correct format for patch files but I promise to get it right when I have made more progress. ---------- components: +Library (Lib) versions: +Python 2.6 Added file: http://bugs.python.org/file9897/PyLibDiffs.txt ____________________________________ Tracker ____________________________________ From report at bugs.python.org Sun Mar 30 00:23:47 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 29 Mar 2008 23:23:47 +0000 Subject: [issue2507] Exception state lives too long in 3.0 In-Reply-To: <1206800918.45.0.478667091266.issue2507@psf.upfronthosting.co.za> Message-ID: <1206833026.98.0.62746306955.issue2507@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You are right, threads aren't needed. So, attaching an updated patch. Added file: http://bugs.python.org/file9898/exc_cleanup2.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 00:40:10 2008 From: report at bugs.python.org (Robert Siemer) Date: Sat, 29 Mar 2008 23:40:10 +0000 Subject: [issue1731717] race condition in subprocess module Message-ID: <1206834010.51.0.689284101103.issue1731717@psf.upfronthosting.co.za> Robert Siemer added the comment: Update for my comment: python2.5.2 does not show that problem. python2.4.5 did. I repeat, 2.5.2 does not clean up processes which are still referenced, but it does clean unreferenced ones. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sun Mar 30 01:56:38 2008 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 30 Mar 2008 00:56:38 +0000 Subject: [issue1579] logging documentation is unclear In-Reply-To: <1197300194.46.0.863908405505.issue1579@psf.upfronthosting.co.za> Message-ID: <1206838598.71.0.533666809889.issue1579@psf.upfronthosting.co.za> Vinay Sajip added the comment: In your original submission, you said: "... the front page has a rather confusing example of the named hierarchy system, which might mislead the reader by making them think it's about file types (perhaps for log output) rather than just arbitrary naming conventions." What the front page says is: "Each [Logger] instance has a name, and they are conceptually arranged in a name space hierarchy using dots (periods) as separators. For example, a logger named "scan" is the parent of loggers "scan.text", "scan.html" and "scan.pdf". Logger names can be anything you want, and indicate the area of an application in which a logged message originates." Notice the last sentence, which clearly (to me) states that logger names can by anything you want, i.e. an arbitrary naming convention. Although the examples given were "scan.text", "scan.html" and "scan.pdf", I don't believe the average user would confuse this with file types for log output, unless they skimmed the paragraph. The paragraph does not mention file types anywhere else, and nor do the next few paragraphs. The example in section 14.5.3 is fairly well commented, so IMO it's misrepresenting it a little to call it a "code dump". It's not the first example, either - a number of shorter examples are shown earlier in the documentation. When the logging package was introduced into Python back in version 2.3, there were some valid comments from people about lack of examples and lack of clarity in the documentation. This was rectified over time, and your comment is the first one for several months about documentation clarity. About documentation, it could always be argued that it could be clearer, because there's bound to be someone who doesn't understand it. But maintenance of this package (and Python) is a spare-time activity for most of us, and a number of competing priorities have to be traded off when deciding how to spend that time. I have spent a fair amount of time over the months improving the documentation, as have others, to the point where we don't get many comments about it; hence, it's time, from my point of view, to scratch other itches. If people feel strongly enough about it, they'll submit specific ideas or patches, which can be easily incorporated into the documentation. (You can look at the history of changes to the logging documentation in SVN to see that it updated reasonably often.) Simply stating that it "is quite confusing" is so open ended that an effort to make it less confusing could take a very long time, and that's why I invited a patch: I got the impression that you now understand how the hierarchy etc. works, even if you didn't straight away. If you are still having difficulty understanding some aspects of the package, please post on comp.lang.python: you will see that queries are reasonably promptly answered, not always by core developers but often by other users of the logging package. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 03:15:15 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 30 Mar 2008 01:15:15 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206839715.41.0.207345992049.issue1751@psf.upfronthosting.co.za> Antoine Pitrou added the comment: >From a quick glance: I may be wrong, but it looks like in bytesio_writelines(), you'll have some reference leaks if the `while` loop exits early because bytesio_write() returns NULL; `item` and `it` should be decred'ed before returning. ---------- nosy: +pitrou __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 06:00:30 2008 From: report at bugs.python.org (ajaksu) Date: Sun, 30 Mar 2008 04:00:30 +0000 Subject: [issue2506] Line tracing of continue after always-taken if is incorrect In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1206849630.29.0.445466308467.issue2506@psf.upfronthosting.co.za> Changes by ajaksu : ---------- nosy: +ajaksu2 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 06:43:48 2008 From: report at bugs.python.org (Senthil) Date: Sun, 30 Mar 2008 04:43:48 +0000 Subject: [issue2275] urllib2 header capitalization In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za> Message-ID: <1206852228.18.0.528441922267.issue2275@psf.upfronthosting.co.za> Senthil added the comment: I understand your implementation of _cap_header_key function. But should not this patch be handled in a way wherein. key.capitalize() is just replaced by key.upper()? Should not that suffice? What is the difference between _cap_header_key and key.upper()? Thank you, Senthil ---------- nosy: +orsenthil __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 06:58:56 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 30 Mar 2008 04:58:56 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206853136.97.0.717979734938.issue1751@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : Removed file: http://bugs.python.org/file9084/_bytesio.c __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 06:59:01 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 30 Mar 2008 04:59:01 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206853141.74.0.64411981492.issue1751@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : Removed file: http://bugs.python.org/file9085/add-bytesio-setup.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 06:59:12 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 30 Mar 2008 04:59:12 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206853152.95.0.342966023243.issue1751@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : Removed file: http://bugs.python.org/file9087/test_memoryio.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 06:59:07 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 30 Mar 2008 04:59:07 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206853147.57.0.892243370577.issue1751@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : Removed file: http://bugs.python.org/file9086/swap-initstdio-initsite.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 06:59:20 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 30 Mar 2008 04:59:20 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206853160.26.0.790038122907.issue1751@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : Removed file: http://bugs.python.org/file9088/remove-old-stringio-test.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 06:59:24 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 30 Mar 2008 04:59:24 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206853164.11.0.594290363399.issue1751@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : Removed file: http://bugs.python.org/file9089/truncate-semantic-change.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 06:59:29 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 30 Mar 2008 04:59:29 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206853169.4.0.790556817507.issue1751@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : Removed file: http://bugs.python.org/file9090/io-misc-fixes.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 07:02:35 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 30 Mar 2008 05:02:35 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206853355.76.0.51645946446.issue1751@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Yes, that was a leak. It should be fixed now. Merci Antoine! Added file: http://bugs.python.org/file9899/bytesio+misc-fixes-4.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 08:40:26 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 30 Mar 2008 06:40:26 +0000 Subject: [issue2511] Give AST's excepthandler proper attributes In-Reply-To: <1206815408.44.0.121788242529.issue2511@psf.upfronthosting.co.za> Message-ID: <1206859226.72.0.770385173454.issue2511@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed in r62047. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 09:01:25 2008 From: report at bugs.python.org (Mark Hammond) Date: Sun, 30 Mar 2008 07:01:25 +0000 Subject: [issue2513] 64bit cross compilation on windows In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za> Message-ID: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za> New submission from Mark Hammond : I've taken the liberty of adding Trent, Christian and Martin to the nosy list as I know they are actively, if reluctantly interested in this. This patch allows the distutils to cross-compile on Windows. It has been tested on x86 and amd64 platforms, with both platforms successfully able to natively and cross-compile extension modules and create binary distributions. To cross-compile, specify '--plat-name' to the build command (valid values are 'win32', 'win-amd64' and 'win-ia64'). This option name was chosen to be consistent with the bdist_dumb command. I've included the docs I added below (which are also in the patch), but note that as with native compilation using distutils, it's not necessary to set any environment variables or do anything else special with your environment to make this work. The patch also adds a x64 target for the 'bdist_wininst' target, which it creates as distutils/command/wininst-9.0-amd64.exe. This executable is necessary even for bdist_wininst to work natively on x64, but is still included here for simplicity. To assist with testing, I've also added a distutils setup.py script to the PC/example_nt directory. This is capable of creating bdist_wininst executables for both native and cross platforms; 'setup.py build --platname=win-amd64 bdist_wininst' will create an amd64 installer on an x86 machine. The patch has not been tested with a Visual Studio environment without cross-compile tools installed - it will obviously fail, but its not clear how ugly this failure will be. Below is the text I added to docs/distutils/builtdist.rst: Cross-compiling on Windows ===================== Starting with Python 2.6, distutils is capable of cross-compiling between Windows platforms. In practice, this means that with the correct tools installed, you can use a 32bit version of Windows to create 64bit extensions and vice-versa. To build for an alternate platform, specify the :option:`--plat-name` option to the build command. Valid values are currently 'win32', 'win-amd64' and 'win-ia64'. For example, on a 32bit version of Windows, you could execute:: python setup.py build --plat-name=win-amd64 to build a 64bit version of your extension. The Windows Installers also support this option, so the command:: python setup.py build --plat-name=win-amd64 bdist_wininst would create a 64bit installation executable on your 32bit version of Windows. Note that by default, Visual Studio 2008 does not install 64bit compilers or tools. You may need to reexecute the Visual Studio setup process and select these tools. ---------- assignee: mhammond components: Distutils files: windows-cross-compile.patch keywords: 64bit, patch messages: 64743 nosy: Trent.Nelson, ctheune, loewis, mhammond severity: normal status: open title: 64bit cross compilation on windows type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file9900/windows-cross-compile.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 09:01:55 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 30 Mar 2008 07:01:55 +0000 Subject: [issue2505] Easier creation of _ast nodes In-Reply-To: <1206797890.8.0.128090233535.issue2505@psf.upfronthosting.co.za> Message-ID: <1206860515.76.0.835578294504.issue2505@psf.upfronthosting.co.za> Georg Brandl added the comment: Committed in r62049. ---------- status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 10:36:42 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 30 Mar 2008 08:36:42 +0000 Subject: [issue2176] Undocumented lastrowid attribute i sqlite3 cursor class In-Reply-To: <1203862408.41.0.133171732382.issue2176@psf.upfronthosting.co.za> Message-ID: <1206866202.12.0.81127419907.issue2176@psf.upfronthosting.co.za> Georg Brandl added the comment: Gerhard: Note that you don't need to commit identical changes to the trunk and 3k branches -- the merging process will take care of this. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 12:46:44 2008 From: report at bugs.python.org (Armin Ronacher) Date: Sun, 30 Mar 2008 10:46:44 +0000 Subject: [issue2514] new AST init breaks on Store and other fieldless Nodes In-Reply-To: <1206874004.35.0.00269760141772.issue2514@psf.upfronthosting.co.za> Message-ID: <1206874004.35.0.00269760141772.issue2514@psf.upfronthosting.co.za> New submission from Armin Ronacher : #2505 adds a new init to the ast nodes that allows initialization of the fields directory from the constructor. Unfortunately there are nodes where fields is None (_ast.Store and others) and the constructor didn't take care of this. The patch applied adds a test for None to fix the problem. ---------- components: Extension Modules files: initfix.diff keywords: patch messages: 64746 nosy: aronacher severity: normal status: open title: new AST init breaks on Store and other fieldless Nodes versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9901/initfix.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 14:12:28 2008 From: report at bugs.python.org (Hans-Peter Jansen) Date: Sun, 30 Mar 2008 12:12:28 +0000 Subject: [issue2275] urllib2 header capitalization In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za> Message-ID: <1206879148.43.0.181211248011.issue2275@psf.upfronthosting.co.za> Hans-Peter Jansen added the comment: > But should not this patch be handled in a way wherein. > key.capitalize() is just replaced by key.upper()? Hmm, are you sure? >>> "hello".upper() 'HELLO' >>> but the issue is with values containing dashes: >>> 'accept-charset'.capitalize() 'Accept-charset' whereas the rest of the world would expect: 'Accept-Charset' ^ This is especially useful, if you try to emulate the behavior of a typical browser as close as possible. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 17:00:26 2008 From: report at bugs.python.org (John J Lee) Date: Sun, 30 Mar 2008 15:00:26 +0000 Subject: [issue2275] urllib2 header capitalization In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za> Message-ID: <1206889226.69.0.382163749007.issue2275@psf.upfronthosting.co.za> John J Lee added the comment: Specifically, these improvements could be made: * the headers actually sent to httplib could be normalized to Standard-Http-Case by urllib2 * the urllib2.Request.headers interface could support case-insensitive key lookup __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 16:56:51 2008 From: report at bugs.python.org (John J Lee) Date: Sun, 30 Mar 2008 14:56:51 +0000 Subject: [issue2275] urllib2 header capitalization In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za> Message-ID: <1206889011.71.0.0201052837496.issue2275@psf.upfronthosting.co.za> John J Lee added the comment: urllib2.Request.headers is, in practice, an undocumented public interface. Did you run the tests? There is room for improvement here, but not in the way you suggest. python[1]$ python2.6 iPython 2.6a1+ (trunk:62045M, Mar 30 2008, 03:07:23) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import test.test_urllib2 >>> print test.test_urllib2.test_request_headers_dict.__doc__ The Request.headers dictionary is not a documented interface. It should stay that way, because the complete set of headers are only accessible through the .get_header(), .has_header(), .header_items() interface. However, .headers pre-dates those methods, and so real code will be using the dictionary. The introduction in 2.4 of those methods was a mistake for the same reason: code that previously saw all (urllib2 user)-provided headers in .headers now sees only a subset (and the function interface is ugly and incomplete). A better change would have been to replace .headers dict with a dict subclass (or UserDict.DictMixin instance?) that preserved the .headers interface and also provided access to the "unredirected" headers. It's probably too late to fix that, though. Check .capitalize() case normalization: >>> url = "http://example.com" >>> Request(url, headers={"Spam-eggs": "blah"}).headers["Spam-eggs"] 'blah' >>> Request(url, headers={"spam-EggS": "blah"}).headers["Spam-eggs"] 'blah' Currently, Request(url, "Spam-eggs").headers["Spam-Eggs"] raises KeyError, but that could be changed in future. >>> ---------- nosy: +jjlee __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 18:28:30 2008 From: report at bugs.python.org (John J Lee) Date: Sun, 30 Mar 2008 16:28:30 +0000 Subject: [issue2451] No way to disable socket timeouts in httplib, etc. In-Reply-To: <1206141378.11.0.857343736887.issue2451@psf.upfronthosting.co.za> Message-ID: <1206894509.94.0.171092132579.issue2451@psf.upfronthosting.co.za> John J Lee added the comment: I've attached a patch. My patch introduces one minor issue: it's an inconvenience when wrapping objects if special default values like socket._GLOBAL_DEFAULT_TIMEOUT are not public. However, I think it's not worth making that special value public in this case, because it's not needed by code that does not support the socket.getdefaulttimeout() global default timeout. Patch description ----------------- * Change the timeout arguments that were introduced with Facundo's 2.6 timeout changes so that they have the same meaning as the argument of socket.socket.settimeout() . Specifically, None means "no timeout" (previously, there was no way to request that), and there is no special public timeout value meaning "use the global default socket.getdefaulttimeout() value" (previously, you could pass None to request that). This affects socket, urllib2, urllib (only urllib.ftpwrapper, for urllib2's benefit, urllib public interface and behaviour is unchanged), httplib, ftplib, telnetlib, poplib, and smtplib. * Fix a test bug: test_urllib2net changed global state by calling urllib2.install_opener(), which interfered with other tests. * In tests, where possible, close sockets by calling high-level methods (e.g. call ftplib.FTP.close(), rather than poking into the object's internals to .close() the socket directly). * Inconsistent defaulting behaviour in telnetlib was introduced with the timeout changes (r54608). Made timeout behave like port in terms of defaulting behaviour. * Improve socket.create_connection() documentation. Some of these changes need to be propagated to the individual protocol modules that call this function (e.g. httplib). - Document return value - Be more PEP 8-compliant ("Connect to...", not "Connects to...") - Remove this sentence, since it seems out of place in API documentation and unlikely to be true: "Especially useful for higher-level protocols, it is not normally used directly from application-level code." - Reword to remove any doubt that the timeout applies to (almost) all blocking operations, not just .connect() - Rephrase timeout parameter description for better English style. - Note that create_connection() is a convenience function (rather than part of the thin wrapper around the C API). - Make the docstring for create_connection() match the official reST API docs. Unresolved issues with the new 2.6 timeout functionality -------------------------------------------------------- * http://bugs.python.org/issue2452 * I did not propagate the changes to socket.create_connection() docs to all the protocol modules (httplib, etc.). Probably this change should be committed separately -- I ran out of time. * References in the docs to "the global default timeout setting" are vague. They should specifically refer to socket.getdefaulttimeout() . This should be done in such a way as to also fix the lack of documentation of the None special value in the protocol modules documentation (httplib, etc.). I should have fixed that as part of this patch, but ran out of time -- sorry! * Inconsistency: CacheFTPHandler has per-handler timeout, per-request timeout is ignored! Doc/library/urllib2.rst says (in two places): """This actually only work for HTTP, HTTPS, FTP and FTPS connections.""" That's not true. (What about CacheFTPHandler, for instance?) It's also unclear why it refers to *connections* rather than URL schemes, handler classes, and the network operations they perform. (there's also a little grammatical error here -- s/work/works/) * API weirdness: Only some, special, urllib2.Request objects may be passed to handlers, because the constructor does not create objects with a .timeout. Should it really be per-request anyway (I'm not sure)? ---------- keywords: +patch Added file: http://bugs.python.org/file9902/issue2451.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 18:34:26 2008 From: report at bugs.python.org (John J Lee) Date: Sun, 30 Mar 2008 16:34:26 +0000 Subject: [issue2451] No way to disable socket timeouts in httplib, etc. In-Reply-To: <1206141378.11.0.857343736887.issue2451@psf.upfronthosting.co.za> Message-ID: <1206894866.13.0.2746191684.issue2451@psf.upfronthosting.co.za> John J Lee added the comment: Should I also have selected "Python 3.0" from the "Versions" list, BTW? Don't know what the proper process is ATM... __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 18:40:07 2008 From: report at bugs.python.org (John J Lee) Date: Sun, 30 Mar 2008 16:40:07 +0000 Subject: [issue2451] No way to disable socket timeouts in httplib, etc. In-Reply-To: <1206141378.11.0.857343736887.issue2451@psf.upfronthosting.co.za> Message-ID: <1206895207.74.0.308750847371.issue2451@psf.upfronthosting.co.za> John J Lee added the comment: Me: """ This should be done in such a way as to also fix the lack of documentation of the None special value in the protocol modules documentation (httplib, etc.). I should have fixed that as part of this patch, but ran out of time -- sorry! """ Erm, possibly the meaning and allowed values of the timeout arguments would be more naturally documented by pointing to the socket .settimeout() method docs, actually. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 18:43:44 2008 From: report at bugs.python.org (Paul Davis) Date: Sun, 30 Mar 2008 16:43:44 +0000 Subject: [issue2515] Segfault while operating on closed sqlite3 cursor. In-Reply-To: <1206895424.89.0.255529765862.issue2515@psf.upfronthosting.co.za> Message-ID: <1206895424.89.0.255529765862.issue2515@psf.upfronthosting.co.za> New submission from Paul Davis : Replicated on: #Ubuntu 7.0 Python 2.5.1 (r251:54863, Mar 7 2008, 03:39:23) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 #OS 10.4.11 Python 2.5.1 (r251:54863, Oct 26 2007, 16:52:32) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin #OS 10.5.2 Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin ---------- components: Library (Lib) files: sqlite_segfault.py messages: 64753 nosy: pjdavis severity: normal status: open title: Segfault while operating on closed sqlite3 cursor. type: crash versions: Python 2.5 Added file: http://bugs.python.org/file9903/sqlite_segfault.py __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 19:39:11 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 30 Mar 2008 17:39:11 +0000 Subject: [issue2506] Line tracing of continue after always-taken if is incorrect In-Reply-To: <1206824300.2.0.424117647453.issue2506@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Sat, Mar 29, 2008 at 4:58 PM, Raymond Hettinger wrote: > This has basically almost never been a problem in the real world. I believe Ned gave an important use case. In coverage testing, optimized runs can show false gaps in coverage. In addition, a no optimize option would provide a valuable learning tool. Python has an excellent simple VM very suitable for a case study in introductory CS courses. Unfortunately, inability to disable peephole optimizer makes understanding the resulting bytecode more difficult, particularly given some arbitrary choices made by the optimizer (such as 2*3+1 => 7, but 1+2*3 => 1+6). Furthermore, as Raymond suggested in another thread, peephole optimizer was deliberately kept to bare minimum out of concerns about compilation time. Given that most python code is pre-compiled, I think it is a rare case when code size/speed improvements would not be worth increased compilation time. In a rare case when compilation time is an issue, users can consider disabling optimization. Finally, an easy way to disable the optimizer would help in developing the optimizer itself by providing an easy way to measure improvements and debugging. > No need to complicate the world further by adding yet another option and > the accompanying implementation-specific knowledge of why you would > ever want to use it. > This would not really be a new option. Most users expect varying levels of optimization with -O option and python already has 3 levels: plain, -O, and -OO or Py_OptimizeFlag = 0,1, and 2. Moreover, in fact, Py_OptimizeFlag can be set to an arbitrary positive integer using undocumented -OOO.. option. I don't see how anyone would consider adding say -G with Py_OptimizeFlag = -1 that would disable all optimization as "complicating the world." > Also, when the peepholer is moved (after the AST is created, but before > the opcodes), then little oddities like this will go away. > I don't see how moving optimization up the chain will help with this particular issue. Note that the problem is not with peepholer emiting erroneous line number information, but the fact that the continue statement is optimized away by replacing the if statement's jump to continue with a direct jump to the start of the loop. As I stated in my first comment, trace output is correct and as long as the compiler avoids redundant double jumps, the continue statement will not show up in trace regardless where in compilation chain it is optimized. The only way to get correct coverage information is to disable double jump optimization. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 20:07:53 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 30 Mar 2008 18:07:53 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206900473.54.0.853573466804.issue1751@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Alexandre, is it normal that the unit tests look much less complete in your latest patch than they were in the previous one? Also, they don't test the Python fallback implementation anymore. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 20:20:54 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 30 Mar 2008 18:20:54 +0000 Subject: [issue2451] No way to disable socket timeouts in httplib, etc. In-Reply-To: <1206141378.11.0.857343736887.issue2451@psf.upfronthosting.co.za> Message-ID: <1206901254.6.0.704750565781.issue2451@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Marking just 2.6 is fine. The fix will be merged into 3.0 ---------- nosy: +benjamin.peterson __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 20:43:23 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 30 Mar 2008 18:43:23 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206902603.72.0.608101610717.issue1751@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Oops, I forgot to include the unit tests, with "svn add", when I made the diff. Added file: http://bugs.python.org/file9904/bytesio+misc-fixes-5.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 20:52:23 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 30 Mar 2008 18:52:23 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206903142.65.0.662061588782.issue1751@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: There is a small bug in the last patch I posted. The unit tests assumed (wrongly) that accelerator module for io.StringIO (i.e., _stringio) was present. Added file: http://bugs.python.org/file9905/bytesio+misc-fixes-6.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 21:06:00 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 30 Mar 2008 19:06:00 +0000 Subject: [issue2514] new AST init breaks on Store and other fieldless Nodes In-Reply-To: <1206874004.35.0.00269760141772.issue2514@psf.upfronthosting.co.za> Message-ID: <1206903960.74.0.964918402095.issue2514@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in r62051. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 21:23:48 2008 From: report at bugs.python.org (Alan Kennedy) Date: Sun, 30 Mar 2008 19:23:48 +0000 Subject: [issue2452] inaccuracy in httplib timeout documentation In-Reply-To: <1206141807.24.0.299665473683.issue2452@psf.upfronthosting.co.za> Message-ID: <1206905028.36.0.091837869343.issue2452@psf.upfronthosting.co.za> Changes by Alan Kennedy : ---------- nosy: +amak __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 22:06:56 2008 From: report at bugs.python.org (Senthil) Date: Sun, 30 Mar 2008 20:06:56 +0000 Subject: [issue2275] urllib2 header capitalization In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za> Message-ID: <1206907616.49.0.868621846049.issue2275@psf.upfronthosting.co.za> Senthil added the comment: Hi John, Greetings! I agree with both of your suggestions. Attached is the patch which aims to implement both in one go. Please provide your comments on that. If this method is okay, I shall go ahead with patches for tests and attach it also. Thanks, Senthil Added file: http://bugs.python.org/file9906/issue2275.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 22:09:22 2008 From: report at bugs.python.org (Senthil) Date: Sun, 30 Mar 2008 20:09:22 +0000 Subject: [issue2275] urllib2 header capitalization In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za> Message-ID: <1206907762.04.0.974998144201.issue2275@psf.upfronthosting.co.za> Changes by Senthil : Removed file: http://bugs.python.org/file9906/issue2275.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 22:09:42 2008 From: report at bugs.python.org (Senthil) Date: Sun, 30 Mar 2008 20:09:42 +0000 Subject: [issue2275] urllib2 header capitalization In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za> Message-ID: <1206907782.51.0.685641677748.issue2275@psf.upfronthosting.co.za> Changes by Senthil : Added file: http://bugs.python.org/file9907/issue2275.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 22:28:36 2008 From: report at bugs.python.org (Hans-Peter Jansen) Date: Sun, 30 Mar 2008 20:28:36 +0000 Subject: [issue2275] urllib2 header capitalization In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za> Message-ID: <1206908916.9.0.669630381126.issue2275@psf.upfronthosting.co.za> Hans-Peter Jansen added the comment: Hi Senthil, that looks promising, and the title() trick is nice, as it fixes my issue.. Thanks, Pete __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 22:29:52 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 30 Mar 2008 20:29:52 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206908992.14.0.262812677401.issue1751@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok I took a detailed look at _bytesio.c. In write_bytes() there is the following resizing logic: if (self->pos + len > self->string_size) { if (resize_buffer(self, self->pos + len) < 0) return -1; } Replacing `self->string_size` with `self->buf_size` should avoid some spurious reallocations. For some reason, using the help() function on a BytesIO instance does not display the class help. Overall, the new module looks fine. I can't say anything about the io.py or _fileio.c fixes. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 22:48:26 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 30 Mar 2008 20:48:26 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206910106.32.0.376334483486.issue1751@psf.upfronthosting.co.za> Antoine Pitrou added the comment: One last thing: you probably noticed it, but there is one test which needs correcting in test_StringIO. It's due to the fact that calling next() on a closed BytesIO object raises ValueError now rather than StopIteration. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 23:01:14 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 30 Mar 2008 21:01:14 +0000 Subject: [issue2506] Line tracing of continue after always-taken if is incorrect In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1206910874.68.0.914393785045.issue2506@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Weigh the cost/benefit carefully before pushing further. I don't doubt the legitimacy of the use case, but do think it affects far fewer than one percent of Python programmers. In contrast, introducing new command line options is a big deal and will cause its own issues (possibly needing its own buildbot runs to exercise the non-optimized version, having optimized code possibly have subtle differences from the code being traced/debugged/profiled, and more importantly the mental overhead of having to learn what it is, why it's there, and when to use it). My feeling is that adding a new compiler option using a cannon to kill a mosquito. If you decide to press the case for this one, it should go to python-dev since command line options affect everyone. This little buglet has been around since Py2.3. That we're only hearing about it now is a pretty good indicator that this is a very minor in the Python world and doesn't warrant a heavy-weight solution. It would be *much* more useful to direct effort improving the mis- reporting of the number of arguments given versus those required for instance methods: >>> a.f(1, 2) TypeError: f() takes exactly 1 argument (3 given) __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Mar 30 23:37:35 2008 From: report at bugs.python.org (Ned Batchelder) Date: Sun, 30 Mar 2008 21:37:35 +0000 Subject: [issue2506] Line tracing of continue after always-taken if is incorrect In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1206913055.36.0.0793121938607.issue2506@psf.upfronthosting.co.za> Ned Batchelder added the comment: Raymond, do you have a cannon-less recommendation of how to kill this particular mosquito? __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 00:05:05 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 30 Mar 2008 22:05:05 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206914705.52.0.175073021318.issue1751@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: I think that check in write_bytes() is a guard to avoid resize_buffer() from truncating the string stored in the buffer. However, I am not sure if it is still necessary. I don't know why help() doesn't work on BytesIO instances. But, the problem doesn't seems to be in my code, since `help(sys.stdin)` doesn't work either. Finally regarding test_StringIO, see msg59460. Anyway, test_StringIO is superseded by test_memoryio included my patch and should be removed from the stdlib. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 00:23:35 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 30 Mar 2008 22:23:35 +0000 Subject: [issue2516] Instance methods are misreporting the number of arguments In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za> Message-ID: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za> New submission from Alexander Belopolsky : Opening a new issue per Raymond's request at msg64764: """ It would be *much* more useful to direct effort improving the mis- reporting of the number of arguments given versus those required for instance methods: >>> a.f(1, 2) TypeError: f() takes exactly 1 argument (3 given) """ I would suggest that this misreporting may be dear to old-beards reminding the time when there was not as much difference between methods and functions as there is now. It does not seem to be that hard to change the diagnostic to >>> a.f(1, 2) TypeError: f() takes no arguments (2 given) but the novice users would much rather see "a.f() takes no arguments (2 given)." The later is unfortunately not possible. Raymond, what would you say to ".f() takes no arguments (2 given)" diagnostic? ---------- components: Interpreter Core messages: 64767 nosy: belopolsky, rhettinger severity: normal status: open title: Instance methods are misreporting the number of arguments type: behavior __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 00:24:44 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 30 Mar 2008 22:24:44 +0000 Subject: [issue2506] Line tracing of continue after always-taken if is incorrect In-Reply-To: <1206910874.68.0.914393785045.issue2506@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Sun, Mar 30, 2008 at 5:01 PM, Raymond Hettinger wrote: .. > It would be *much* more useful to direct effort improving the mis- > reporting of the number of arguments given versus those required for > instance methods: > >>> a.f(1, 2) > TypeError: f() takes exactly 1 argument (3 given) Please see issue2516. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 00:52:12 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 30 Mar 2008 22:52:12 +0000 Subject: [issue1751] Fast BytesIO implementation + misc changes In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za> Message-ID: <1206917532.42.0.817688719519.issue1751@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, by construction self->buf_size should always be greater than self->string_size, so I don't think there's any risk of truncating anything here. I tried the change, and the tests still ran fine. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 01:13:52 2008 From: report at bugs.python.org (Christoph Burgmer) Date: Sun, 30 Mar 2008 23:13:52 +0000 Subject: [issue2517] Error when printing an exception containing a Unicode string In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za> Message-ID: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za> New submission from Christoph Burgmer : Python seems to have problems when an exception is thrown that contains non-ASCII text as a message and is converted to a string. >>> try: ... raise Exception(u'Error when printing ?') ... except Exception, e: ... print e ... Traceback (most recent call last): File "", line 4, in ? UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 20: ordinal not in range(128) See http://www.stud.uni-karlsruhe.de/~uyhc/de/content/python-and-exceptions-containing-unicode-messages ---------- components: Unicode messages: 64770 nosy: christoph severity: normal status: open title: Error when printing an exception containing a Unicode string type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 01:21:26 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 30 Mar 2008 23:21:26 +0000 Subject: [issue2517] Error when printing an exception containing a Unicode string In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za> Message-ID: <1206919286.33.0.863704528492.issue2517@psf.upfronthosting.co.za> Benjamin Peterson added the comment: That is because Python encodes it's error messages as ASCII by default, and "?" is not in ASCII. You can fix this by using "print unicode_msg.encode("utf-8")" or something similar. ---------- nosy: +benjamin.peterson resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 01:26:41 2008 From: report at bugs.python.org (Ned Batchelder) Date: Sun, 30 Mar 2008 23:26:41 +0000 Subject: [issue2516] Instance methods are misreporting the number of arguments In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za> Message-ID: <1206919601.37.0.193231831908.issue2516@psf.upfronthosting.co.za> Changes by Ned Batchelder : ---------- nosy: +nedbat __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 02:37:28 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 31 Mar 2008 00:37:28 +0000 Subject: [issue2516] Instance methods are misreporting the number of arguments In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za> Message-ID: <1206923848.74.0.656358464271.issue2516@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Attached patch (issue2516poc.diff) presents proof-of-concept code which changes the problematic reporting as follows: >>> a.f(1,2) Traceback (most recent call last): File "", line 1, in TypeError: .f() takes exactly 0 arguments (2 given) More effort is needed to make this patch ready: support default/keyword arguments, respect English grammar in 1-argument case, etc. Before I do that, however, I would like to hear that this is a worthwhile fix and that I've chosen the right place in the code to implement it. ---------- keywords: +patch Added file: http://bugs.python.org/file9908/issue2516poc.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 03:14:00 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 31 Mar 2008 01:14:00 +0000 Subject: [issue2516] Instance methods are misreporting the number of arguments In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za> Message-ID: <1206926040.12.0.636313245857.issue2516@psf.upfronthosting.co.za> Benjamin Peterson added the comment: You have +1 from me to continue developing this patch. ---------- nosy: +benjamin.peterson priority: -> low __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 03:34:09 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 31 Mar 2008 01:34:09 +0000 Subject: [issue2506] Line tracing of continue after always-taken if is incorrect In-Reply-To: <1206910874.68.0.914393785045.issue2506@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Sun, Mar 30, 2008 at 5:01 PM, Raymond Hettinger wrote: .. > Weigh the cost/benefit carefully before pushing further. I don't doubt > the legitimacy of the use case, but do think it affects far fewer than > one percent of Python programmers. I agree with you, but only because fewer than 1% of Python programmers have complete test coverage for their code. :-) On the other hand, I wanted a no-optimize option regardless of the trace issue. Once it is there, I am sure everyone interested in how python compiler works will use it. (I am not sure what % of Python programmers would fall into that category.) I don't know how big of a deal an extra buildbot is, but I don't think it will be necessary. It is hard to imagine optimization that would fix (mask) errors in non-optimized code. Therefore, a non-optimized buildbot is unlikely to flag errors that ar not present in optimized runs. On the other hand errors introduced by optimizer will be easier to diagnose if they disappear when the code runs without optimization. Mental overhead is important, but I think it will be easier to explain the effect of no optimize option than to explain what -O does in the current version. As far as I can tell, -O has nothing to do with peephole optimization and only removes assert statements and replaces __debug__ with 0. I am sure most python users are not aware of the fact that peephole optimization is performed without -O option. > My feeling is that adding a new compiler option using a cannon to kill > a mosquito. If you decide to press the case for this one, it should go > to python-dev since command line options affect everyone. > As an alternative to the command line option, what would you say to making sys.flags.optimize writeable and disable peepholer if Py_OprimizeFlag < 0? This will allow python tracing tools to disable optimization from within python code. The fact that setting sys.flags.optimize flag will not affect modules that are already loaded is probably a good thing because tracing code itself will run optimized. Such tracing tools may also need to use a custom importer that would ignore precompiled code and effectively set dont_write_bytecode flag. > This little buglet has been around since Py2.3. That we're only > hearing about it now is a pretty good indicator that this is a very > minor in the Python world and doesn't warrant a heavy-weight solution. > I still maintain that this is not a bug. Not hearing about it before is probably an indication that users sophisticated enough to try to achieve full test coverage for their code were able to recognize false coverage gaps as such. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 03:59:38 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 31 Mar 2008 01:59:38 +0000 Subject: [issue2506] Line tracing of continue after always-taken if is incorrect In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1206928778.56.0.064655280715.issue2506@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Marking this one as closed. Also, rejecting the various ways to disable peephole optimization. This was discussed with Guido long ago and the decision essentially recognized that for most practical purposes the output of the peepholer is the generated code and no good would come from exposing upstream intermediate steps. Since then, I believe Neal got Guido's approval for either the -O or - OO option to generate new optimizations that potentially change semantics. In that situation, there is a worthwhile reason for the enable/disable option. ---------- resolution: -> wont fix status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 07:11:57 2008 From: report at bugs.python.org (HiroakiKawai) Date: Mon, 31 Mar 2008 05:11:57 +0000 Subject: [issue2518] smtpd.py to handle huge email In-Reply-To: <1206940317.15.0.464118270083.issue2518@psf.upfronthosting.co.za> Message-ID: <1206940317.15.0.464118270083.issue2518@psf.upfronthosting.co.za> New submission from HiroakiKawai : I had some problems when I wanted to do attach a huge data file (such as mp3, avi, or etc.) to an email. Current smtpd.py in Python2.5 calls process_message that takes a string for its argument. This cause python running process to consume too much memory. I'd like to suggest an alternative method for this purpose process_message_huge that takes a file-descriptor for its argument. The patch will use process_message_huge if the method exists, otherwise, it will call process_message with a string that will consume a huge memory for backward compatibility. ---------- components: Library (Lib) files: smtpd.patch keywords: patch messages: 64776 nosy: kawai severity: normal status: open title: smtpd.py to handle huge email type: security versions: Python 2.5 Added file: http://bugs.python.org/file9909/smtpd.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 07:12:27 2008 From: report at bugs.python.org (HiroakiKawai) Date: Mon, 31 Mar 2008 05:12:27 +0000 Subject: [issue2518] smtpd.py to handle huge email In-Reply-To: <1206940317.15.0.464118270083.issue2518@psf.upfronthosting.co.za> Message-ID: <1206940347.84.0.548827841228.issue2518@psf.upfronthosting.co.za> Changes by HiroakiKawai : ---------- type: security -> resource usage __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 07:23:12 2008 From: report at bugs.python.org (HiroakiKawai) Date: Mon, 31 Mar 2008 05:23:12 +0000 Subject: [issue2518] smtpd.py to handle huge email In-Reply-To: <1206940317.15.0.464118270083.issue2518@psf.upfronthosting.co.za> Message-ID: <1206940992.82.0.817399865515.issue2518@psf.upfronthosting.co.za> HiroakiKawai added the comment: My carelessness, missing importing cStringIO Added file: http://bugs.python.org/file9910/smtpd.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 07:23:26 2008 From: report at bugs.python.org (HiroakiKawai) Date: Mon, 31 Mar 2008 05:23:26 +0000 Subject: [issue2518] smtpd.py to handle huge email In-Reply-To: <1206940317.15.0.464118270083.issue2518@psf.upfronthosting.co.za> Message-ID: <1206941006.75.0.301543756296.issue2518@psf.upfronthosting.co.za> Changes by HiroakiKawai : Removed file: http://bugs.python.org/file9909/smtpd.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 09:39:56 2008 From: report at bugs.python.org (Dennis Kaarsemaker) Date: Mon, 31 Mar 2008 07:39:56 +0000 Subject: [issue2519] Typing 'modules' in the interactive help system fails when imports fail In-Reply-To: <1206949196.03.0.881908306183.issue2519@psf.upfronthosting.co.za> Message-ID: <1206949196.03.0.881908306183.issue2519@psf.upfronthosting.co.za> New submission from Dennis Kaarsemaker : If a certain module cannot be imported, this error is not caught and warned about by pydoc, but will cause 'modules' to fail. This could be considered a bug in the module but it would still be nice if 3rd party modules cannot break pydoc. Example: dennis at mirage:~$ python Python 2.5.2 (r252:60911, Mar 12 2008, 13:36:25) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> help() Welcome to Python 2.5! This is the online help utility. [... snip ...] help> modules Please wait a moment while I gather a list of all available modules... Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/site.py", line 342, in __call__ return pydoc.help(*args, **kwds) File "/usr/lib/python2.5/pydoc.py", line 1649, in __call__ self.interact() File "/usr/lib/python2.5/pydoc.py", line 1667, in interact self.help(request) File "/usr/lib/python2.5/pydoc.py", line 1683, in help elif request == 'modules': self.listmodules() File "/usr/lib/python2.5/pydoc.py", line 1804, in listmodules ModuleScanner().run(callback) File "/usr/lib/python2.5/pydoc.py", line 1855, in run for importer, modname, ispkg in pkgutil.walk_packages(): File "/usr/lib/python2.5/pkgutil.py", line 125, in walk_packages for item in walk_packages(path, name+'.', onerror): [... snip -- the actual error isn't important ...] OperationalError: no such table: falcon_configurationkey >>> I think it would be relatively easy to work around such bugs in 3rd party modules by passing a callable to walk_packages that will give a warning when an import fails instead of breaking. ---------- components: Library (Lib) messages: 64778 nosy: dennis severity: normal status: open title: Typing 'modules' in the interactive help system fails when imports fail __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 09:40:45 2008 From: report at bugs.python.org (Dennis Kaarsemaker) Date: Mon, 31 Mar 2008 07:40:45 +0000 Subject: [issue2519] Typing 'modules' in the interactive help system fails when imports fail In-Reply-To: <1206949196.03.0.881908306183.issue2519@psf.upfronthosting.co.za> Message-ID: <1206949245.85.0.534583164856.issue2519@psf.upfronthosting.co.za> Changes by Dennis Kaarsemaker : ---------- versions: +Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 11:47:49 2008 From: report at bugs.python.org (Christoph Burgmer) Date: Mon, 31 Mar 2008 09:47:49 +0000 Subject: [issue2517] Error when printing an exception containing a Unicode string In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za> Message-ID: <1206956869.87.0.556020328352.issue2517@psf.upfronthosting.co.za> Christoph Burgmer added the comment: To be more precise: I see no way to convert the encapsulated non-ASCII data from the string in an easy way. Taking e from my last post none of the following will work: str(e) # UnicodeDecodeError e.__str__() # UnicodeDecodeError e.__unicode__() # AttributeError unicode(e) # UnicodeDecodeError unicode(e, 'utf8') # TypeError My solution around this right now is raising an exception with an already converted string (see the link I provided). But as the tutorials speak of simply "print e" I guess the behaviour described above is some kind of a bug. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 12:11:08 2008 From: report at bugs.python.org (Brett Cannon) Date: Mon, 31 Mar 2008 10:11:08 +0000 Subject: [issue1631171] implement warnings module in C Message-ID: <1206958268.11.0.89856938179.issue1631171@psf.upfronthosting.co.za> Brett Cannon added the comment: On another note, the warnings module should be made to work with or without _warnings. that way IronPython, Jython, and PyPy won't have to re- implement stuff. This also means that test cases need to be changed to test this. ---------- priority: normal -> high _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 31 12:44:01 2008 From: report at bugs.python.org (Peter Poeml) Date: Mon, 31 Mar 2008 10:44:01 +0000 Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails Message-ID: <1206960241.7.0.842040733798.issue1424152@psf.upfronthosting.co.za> Changes by Peter Poeml : ---------- nosy: +poeml _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Mar 31 13:49:04 2008 From: report at bugs.python.org (Christian Heimes) Date: Mon, 31 Mar 2008 11:49:04 +0000 Subject: [issue2513] 64bit cross compilation on windows In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za> Message-ID: <1206964144.49.0.748090321473.issue2513@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 13:58:22 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 31 Mar 2008 11:58:22 +0000 Subject: [issue2517] Error when printing an exception containing a Unicode string In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za> Message-ID: <1206964702.59.0.341558279506.issue2517@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Use: print unicode(e.message).encode("utf-8") __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 14:19:25 2008 From: report at bugs.python.org (Christoph Burgmer) Date: Mon, 31 Mar 2008 12:19:25 +0000 Subject: [issue2517] Error when printing an exception containing a Unicode string In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za> Message-ID: <1206965965.45.0.955745951787.issue2517@psf.upfronthosting.co.za> Christoph Burgmer added the comment: Thanks, this does work. But, where can I find the piece of information you just gave to me in the docs? I couldn't find any interface definition for Exceptions. Further more will this be regarded as a bug? >From [1] I understand that "unicode(e)" and "unicode(e, 'utf8')" are supposed to work. No limitations are made on the type of the object. And I suppose that unicode() is the exact equivalent of str() in that it copes with unicode strings. Not expecting the string representation of an Exception to return a Unicode string when its content is non-ASCII where as this kind of behaviour of simple string conversion is wished for with ASCII text seems unlikely cumbersome. Please reopen if my report does have a point. [1] http://docs.python.org/lib/built-in-funcs.html __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 17:07:22 2008 From: report at bugs.python.org (John Buckley) Date: Mon, 31 Mar 2008 15:07:22 +0000 Subject: [issue2520] macerrors.py cannot be imported due to non-ascii characters in comments In-Reply-To: <1206976042.0.0.654029091605.issue2520@psf.upfronthosting.co.za> Message-ID: <1206976042.0.0.654029091605.issue2520@psf.upfronthosting.co.za> New submission from John Buckley : Cannot import macerrors due to non-ascii characters appearing in comments. Patch attached. ---------- components: Library (Lib), Macintosh files: macerrors.patch keywords: patch messages: 64783 nosy: thecube severity: normal status: open title: macerrors.py cannot be imported due to non-ascii characters in comments type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9911/macerrors.patch __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 17:12:30 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 31 Mar 2008 15:12:30 +0000 Subject: [issue2521] ABC caches should use weak refs In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za> Message-ID: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc : The following function seems to 8 references each time it is run: import io, gc def f(): class C: pass c=C() assert isinstance(c, io.StringIO) is False gc.collect();gc.collect();gc.collect() This is because io.StringIO._abc_negative_cache contains a strong reference to each "class C", as soon as isinstance() is called. These are never released. Python3.0 does use WeakSet for these caches, and does not leak. This is the (deep) reason why test_io.IOTest.test_destructor() leaks in the following report: http://mail.python.org/pipermail/python-checkins/2008-March/067918.html (The test derives from io.FileIO, and it is the call to the base class' method which calls isinstance() and put the class in the cache) ---------- components: Interpreter Core keywords: 26backport messages: 64784 nosy: amaury.forgeotdarc severity: normal status: open title: ABC caches should use weak refs versions: Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 17:25:39 2008 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 31 Mar 2008 15:25:39 +0000 Subject: [issue2016] Crash when modifying the **kwargs passed to a function. In-Reply-To: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za> Message-ID: <1206977139.7.0.117994846008.issue2016@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I am attaching my fix along the lines of a solution suggested by Amaury at http://mail.python.org/pipermail/python-dev/2008- February/076747.html: """ > Or is the proper fix to incref the values > going into the kw array and decref them upon exit? Yet Another Kind Of Tuple... However this seems the correct thing to do. """ I did not do any performance tests with this patch. ---------- keywords: +patch Added file: http://bugs.python.org/file9912/issue2016.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 18:14:00 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 31 Mar 2008 16:14:00 +0000 Subject: [issue2517] Error when printing an exception containing a Unicode string In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za> Message-ID: <1206980040.32.0.599256763506.issue2517@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Note the interpreter cannot print the exception either: >>> raise Exception(u'Error when printing ?') Traceback (most recent call last): File "", line 1, in Exception>>> ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 19:08:09 2008 From: report at bugs.python.org (Andrii V. Mishkovskyi) Date: Mon, 31 Mar 2008 17:08:09 +0000 Subject: [issue2522] locale.format() problems with decimal separator In-Reply-To: <1206983289.11.0.844443108334.issue2522@psf.upfronthosting.co.za> Message-ID: <1206983289.11.0.844443108334.issue2522@psf.upfronthosting.co.za> New submission from Andrii V. Mishkovskyi : locale.format() doesn't insert correct decimal separator to string representation when 'format' argument has '\r' or '\n' symbols in it. This bug has been reproduced on Python 2.5.2 and svn-trunk. Python 2.4.5 (#2, Mar 12 2008, 14:42:24) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.setlocale(locale.LC_ALL, "ru_RU.UTF-8") 'ru_RU.UTF-8' >>> a = 1.234 >>> print locale.format("%f", a) 1,234000 >>> print locale.format("%f\n", a) 1,234000 >>> print locale.format("%f\r", a) 1,234000 Python 2.6a1+ (trunk:62083, Mar 31 2008, 19:24:56) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu6)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.setlocale(locale.LC_ALL, "ru_RU.UTF-8") 'ru_RU.UTF-8' >>> a = 1.234 >>> print locale.format("%f", a) 1,234000 >>> print locale.format("%f\n", a) 1.234000 >>> print locale.format("%f\r", a) 1.234000 Python 2.5.2 (r252:60911, Mar 12 2008, 13:36:25) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.setlocale(locale.LC_ALL, "ru_RU.UTF-8") 'ru_RU.UTF-8' >>> a = 1.234 >>> print locale.format("%f", a) 1,234000 >>> print locale.format("%f\n", a) 1.234000 >>> print locale.format("%f\r", a) 1.234000 ---------- messages: 64787 nosy: mishok13 severity: normal status: open title: locale.format() problems with decimal separator type: behavior versions: Python 2.5, Python 2.6 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 20:21:43 2008 From: report at bugs.python.org (Thomas Heller) Date: Mon, 31 Mar 2008 18:21:43 +0000 Subject: [issue2152] make sqlite.Row hashable correctly In-Reply-To: <1203590912.21.0.769567830293.issue2152@psf.upfronthosting.co.za> Message-ID: <1206987703.44.0.645705277607.issue2152@psf.upfronthosting.co.za> Thomas Heller added the comment: Here's a patch against trunk that implements tp_richcompare. It does apply to and work also in the py3k branch. I have only implemented the '__eq__' and '__ne__' comparisons. Added file: http://bugs.python.org/file9913/sqliterow-richcmp.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 20:31:50 2008 From: report at bugs.python.org (Thomas Heller) Date: Mon, 31 Mar 2008 18:31:50 +0000 Subject: [issue2513] 64bit cross compilation on windows In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za> Message-ID: <1206988310.82.0.921316393629.issue2513@psf.upfronthosting.co.za> Changes by Thomas Heller : ---------- nosy: +theller __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 20:11:25 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 31 Mar 2008 18:11:25 +0000 Subject: [issue2523] binary buffered reading is quadratic In-Reply-To: <1206987085.65.0.944826780657.issue2523@psf.upfronthosting.co.za> Message-ID: <1206987085.65.0.944826780657.issue2523@psf.upfronthosting.co.za> New submission from Antoine Pitrou : In py3k, buffered binary IO can be quadratic when e.g. reading a whole file. This is a small test on 50KB, 100KB and 200KB files: -> py3k with buffering: ./python -m timeit -s "f = open('50KB', 'rb')" "f.seek(0); f.read()" 1000 loops, best of 3: 286 usec per loop ./python -m timeit -s "f = open('100KB', 'rb')" "f.seek(0); f.read()" 1000 loops, best of 3: 1.07 msec per loop ./python -m timeit -s "f = open('200KB', 'rb')" "f.seek(0); f.read()" 100 loops, best of 3: 4.85 msec per loop -> py3k without buffering (just the raw FileIO layer): ./python -m timeit -s "f = open('50KB', 'rb', buffering=0)" "f.seek(0); f.read()" 10000 loops, best of 3: 46 usec per loop ./python -m timeit -s "f = open('100KB', 'rb', buffering=0)" "f.seek(0); f.read()" 10000 loops, best of 3: 88.7 usec per loop ./python -m timeit -s "f = open('200KB', 'rb', buffering=0)" "f.seek(0); f.read()" 10000 loops, best of 3: 156 usec per loop -> for comparison, Python 2.5: python -m timeit -s "f = open('50KB', 'rb')" "f.seek(0); f.read()" 10000 loops, best of 3: 34.4 usec per loop python -m timeit -s "f = open('100KB', 'rb')" "f.seek(0); f.read()" 10000 loops, best of 3: 62.3 usec per loop python -m timeit -s "f = open('200KB', 'rb')" "f.seek(0); f.read()" 10000 loops, best of 3: 119 usec per loop I'm posting this issue as a reminder, but perhaps someone is already working on this, or the goal is to translate it to C ultimately? ---------- components: Library (Lib) messages: 64788 nosy: pitrou severity: normal status: open title: binary buffered reading is quadratic type: performance versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 20:52:58 2008 From: report at bugs.python.org (Thomas Heller) Date: Mon, 31 Mar 2008 18:52:58 +0000 Subject: [issue2513] 64bit cross compilation on windows In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za> Message-ID: <1206989578.01.0.231436979187.issue2513@psf.upfronthosting.co.za> Thomas Heller added the comment: I had to make additional changes to PCBuild\pcbuild.sln to create a 64-bit wininst-9.0-amd64.exe (but I was not able to try out if it works or not). Added file: http://bugs.python.org/file9914/pcbuild.diff __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 22:36:42 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Mon, 31 Mar 2008 20:36:42 +0000 Subject: [issue2524] IDLE 3.0 Message-ID: <1206995802.65.0.739781306453.issue2524@psf.upfronthosting.co.za> Changes by Kurt B. Kaiser : ---------- components: IDLE nosy: kbk severity: normal status: open title: IDLE 3.0 versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 22:40:30 2008 From: report at bugs.python.org (Kurt B. Kaiser) Date: Mon, 31 Mar 2008 20:40:30 +0000 Subject: [issue2524] IDLE 3.0 In-Reply-To: <1206996030.78.0.0596201784267.issue2524@psf.upfronthosting.co.za> Message-ID: <1206996030.78.0.0596201784267.issue2524@psf.upfronthosting.co.za> New submission from Kurt B. Kaiser : oops ---------- assignee: -> kbk components: +None -IDLE priority: -> low resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 22:46:12 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 31 Mar 2008 20:46:12 +0000 Subject: [issue2515] Segfault while operating on closed sqlite3 cursor. In-Reply-To: <1206895424.89.0.255529765862.issue2515@psf.upfronthosting.co.za> Message-ID: <1206996372.18.0.0514848023587.issue2515@psf.upfronthosting.co.za> Ralf Schmitt added the comment: this works with python 2.6. for python 2.5.1 I get the following gdb backtrace: (gdb) bt #0 0x00002b0d95118e2d in cursor_iternext (self=0x2b0d93bae870) at /root/src/Python-2.5.1/Modules/_sqlite/cursor.c:854 #1 0x00002b0d93dd1769 in wrap_next (self=0x2b0d94085b50, args=0x2b0d93b5f468, wrapped=0x2b0d95118d90) at Objects/typeobject.c:3897 #2 0x00002b0d93d7e0e3 in PyObject_Call (func=0x2b0d94085b50, arg=0x2b0d93b5f468, kw=0x2b0d95118d90) at Objects/abstract.c:1860 #3 0x00002b0d93df9549 in PyEval_EvalFrameEx (f=0x664430, throwflag=) at Python/ceval.c:3775 #4 0x00002b0d93dfe308 in PyEval_EvalCodeEx (co=0x2b0d93ba8300, globals=, locals=, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2831 #5 0x00002b0d93dfe422 in PyEval_EvalCode (co=0x2b0d94085b50, globals=0x2b0d93b5f468, locals=0x2b0d95118d90) at Python/ceval.c:494 #6 0x00002b0d93e20f01 in PyRun_FileExFlags (fp=0x601010, filename=0x7fff16f87a77 "sqlite_segfault.py", start=, globals=0x6246d0, locals=0x6246d0, closeit=1, flags=0x7fff16f86600) at Python/pythonrun.c:1271 #7 0x00002b0d93e2119b in PyRun_SimpleFileExFlags (fp=0x601010, filename=0x7fff16f87a77 "sqlite_segfault.py", closeit=1, flags=0x7fff16f86600) at Python/pythonrun.c:877 #8 0x00002b0d93e29f2a in Py_Main (argc=, argv=) at Modules/main.c:523 ---------- nosy: +schmir __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Mar 31 22:48:34 2008 From: report at bugs.python.org (Jeffrey Yasskin) Date: Mon, 31 Mar 2008 20:48:34 +0000 Subject: [issue815646] thread unsafe file objects cause crash Message-ID: <1206996514.72.0.451401527328.issue815646@psf.upfronthosting.co.za> Changes by Jeffrey Yasskin : ---------- nosy: +jyasskin ____________________________________ Tracker ____________________________________ From report at bugs.python.org Mon Mar 31 23:36:02 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 31 Mar 2008 21:36:02 +0000 Subject: [issue2517] Error when printing an exception containing a Unicode string In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za> Message-ID: <1206999362.71.0.318786121665.issue2517@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I am going to reopen this issue for Py3k. The recommended encoding for Python source files in 2.x is ASCII; I wouldn't say correctly dealing with non-ASCII exceptions is fully supported. In 3.x, however, the recommended encoding is UTF-8, so this should work. In Py3k, str(e) # str is unicode in Py3k does work correctly, and that'll have to be used because the message attribute is gone is 3.x. However, the problem Amaury pointed out is not fixed. Exceptions that cannot encoding into ASCII are silently not printed. I think a warning should at least be printed. ---------- priority: -> normal resolution: invalid -> status: closed -> open versions: +Python 3.0 -Python 2.4, Python 2.5 __________________________________ Tracker __________________________________