From report at bugs.python.org Sun Apr 1 00:34:17 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 Mar 2012 22:34:17 +0000 Subject: [issue14316] Broken link in grammar.rst In-Reply-To: <1331821519.86.0.740460407781.issue14316@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b038bfc67e3d by Sandro Tosi in branch 'default': Issue #14316: fix broken link; fix by ?ric Araujo http://hg.python.org/devguide/rev/b038bfc67e3d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 00:37:03 2012 From: report at bugs.python.org (Sandro Tosi) Date: Sat, 31 Mar 2012 22:37:03 +0000 Subject: [issue14316] Broken link in grammar.rst In-Reply-To: <1331821519.86.0.740460407781.issue14316@psf.upfronthosting.co.za> Message-ID: <1333233423.62.0.816851885713.issue14316@psf.upfronthosting.co.za> Changes by Sandro Tosi : ---------- nosy: +sandro.tosi resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 00:47:07 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Mar 2012 22:47:07 +0000 Subject: [issue11273] asyncore creates selec (or poll) on every iteration In-Reply-To: <1298303363.56.0.939143119689.issue11273@psf.upfronthosting.co.za> Message-ID: <1333234027.94.0.174879594694.issue11273@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 00:54:28 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Mar 2012 22:54:28 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1331932171.45.0.56771909125.issue14339@psf.upfronthosting.co.za> Message-ID: <1333234468.68.0.298257569031.issue14339@psf.upfronthosting.co.za> Antoine Pitrou added the comment: While optimizing stuff is nice, I'm not sure there's a use case here. Does it significantly speed up a real-world workload you're having? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 01:07:44 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Mar 2012 23:07:44 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1333235264.12.0.984926106604.issue14304@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The solution outlined in the issue title ("utf-8-bmp codec") sounds like a rather dubious idea. ---------- nosy: +loewis, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 01:08:02 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 Mar 2012 23:08:02 +0000 Subject: [issue13872] socket.detach doesn't mark socket._closed In-Reply-To: <1327582652.34.0.856044764189.issue13872@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 3a220feafa15 by Antoine Pitrou in branch '3.2': Issue #13872: socket.detach() now marks the socket closed (as mirrored in the socket repr()). http://hg.python.org/cpython/rev/3a220feafa15 New changeset d2f0c3eb1eed by Antoine Pitrou in branch 'default': Issue #13872: socket.detach() now marks the socket closed (as mirrored in the socket repr()). http://hg.python.org/cpython/rev/d2f0c3eb1eed ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 01:09:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Mar 2012 23:09:03 +0000 Subject: [issue13872] socket.detach doesn't mark socket._closed In-Reply-To: <1327582652.34.0.856044764189.issue13872@psf.upfronthosting.co.za> Message-ID: <1333235343.76.0.15558404109.issue13872@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you Matt. I've now committed the patch in relevant versions. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: -Python 2.6, Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 01:18:54 2012 From: report at bugs.python.org (Sven Marnach) Date: Sat, 31 Mar 2012 23:18:54 +0000 Subject: [issue14456] Relation between threads and signals unclear In-Reply-To: <1333149178.59.0.333821086904.issue14456@psf.upfronthosting.co.za> Message-ID: <1333235934.72.0.768799459203.issue14456@psf.upfronthosting.co.za> Sven Marnach added the comment: Thanks, Antoine! It's perfectly clear now, and the newly introduces headlines are a definite improvement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 01:25:22 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 Mar 2012 23:25:22 +0000 Subject: [issue14300] dup_socket() on Windows should use WSA_FLAG_OVERLAPPED In-Reply-To: <1331729986.5.0.388536898962.issue14300@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 5be4d8fc9c44 by Antoine Pitrou in branch 'default': Issue #14300: Under Windows, sockets created using socket.dup() now allow overlapped I/O. http://hg.python.org/cpython/rev/5be4d8fc9c44 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 01:26:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Mar 2012 23:26:05 +0000 Subject: [issue14300] dup_socket() on Windows should use WSA_FLAG_OVERLAPPED In-Reply-To: <1331729986.5.0.388536898962.issue14300@psf.upfronthosting.co.za> Message-ID: <1333236365.38.0.658841370837.issue14300@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I've committed the patch to 3.3 since it can be useful with the new wait() method. Thanks! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 01:28:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Mar 2012 23:28:03 +0000 Subject: [issue14286] xxlimited.obj: unresolved external symbol __imp__PyObject_New In-Reply-To: <1331634330.54.0.0691133791003.issue14286@psf.upfronthosting.co.za> Message-ID: <1333236483.22.0.983921641679.issue14286@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 01:29:31 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Mar 2012 23:29:31 +0000 Subject: [issue14286] xxlimited.obj: unresolved external symbol __imp__PyObject_New In-Reply-To: <1331634330.54.0.0691133791003.issue14286@psf.upfronthosting.co.za> Message-ID: <1333236571.41.0.0519576911808.issue14286@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hmm... seems to work here (in release mode, for some reason it's skipped in debug mode). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 01:33:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Mar 2012 23:33:18 +0000 Subject: [issue14116] threading classes' __enter__ should return self In-Reply-To: <1330117381.1.0.499178307418.issue14116@psf.upfronthosting.co.za> Message-ID: <1333236798.75.0.267330836585.issue14116@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Closing then. ---------- resolution: -> rejected stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 01:35:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Mar 2012 23:35:29 +0000 Subject: [issue1641544] rlcompleter tab completion in pdb Message-ID: <1333236929.71.0.116413507287.issue1641544@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +georg.brandl stage: test needed -> patch review versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 01:36:36 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Mar 2012 23:36:36 +0000 Subject: [issue14141] 2.7.2 64-bit Windows library has __impt_Py* for several symbols instead of __imp__Py* In-Reply-To: <1330360352.45.0.311661027338.issue14141@psf.upfronthosting.co.za> Message-ID: <1333236996.38.0.176628355155.issue14141@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 01:39:07 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Mar 2012 23:39:07 +0000 Subject: [issue14151] multiprocessing.connection.Listener fails with invalid address In-Reply-To: <1330437098.57.0.315162934772.issue14151@psf.upfronthosting.co.za> Message-ID: <1333237147.7.0.800133504208.issue14151@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the patch. I don't think it deserves to be a public API (it could be a private function, i.e. starting with an underscore). Also, it's better if you can add a test (to Lib/test/test_multiprocessing.py) checking that ValueError is raised when applicable. ---------- nosy: +pitrou versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 01:41:32 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Mar 2012 23:41:32 +0000 Subject: [issue672115] Assignment to __bases__ of direct object subclasses Message-ID: <1333237292.78.0.921448710823.issue672115@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- assignee: mwh -> nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 01:42:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Mar 2012 23:42:54 +0000 Subject: [issue14059] Implement multiprocessing.Barrier In-Reply-To: <1329699138.74.0.937439869593.issue14059@psf.upfronthosting.co.za> Message-ID: <1333237374.11.0.00853783288491.issue14059@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- dependencies: +multiprocessing.Condition.wait_for missing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 01:54:07 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Mar 2012 23:54:07 +0000 Subject: [issue14087] multiprocessing.Condition.wait_for missing In-Reply-To: <1329922885.58.0.881756065062.issue14087@psf.upfronthosting.co.za> Message-ID: <1333238047.52.0.590590273789.issue14087@psf.upfronthosting.co.za> Antoine Pitrou added the comment: AFAICT (Raw)Value relies on ctypes, so the tests should be skipped if ctypes is unavailable. Or I guess you could use a Semaphore instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 01:58:21 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 31 Mar 2012 23:58:21 +0000 Subject: [issue14440] Close background process if IDLE closes abnormally. In-Reply-To: <1333027712.59.0.103811521392.issue14440@psf.upfronthosting.co.za> Message-ID: <1333238301.04.0.17183805275.issue14440@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Just a bit more info: ^D and ^\ in Command Prompt interpreter print '^D' or '^\'. Return causes syntax error. ^Z\n in interpreter causes silent close. (Because DOS used ^Z as end-of-file.) ^D in IDLE causes silent close. IDLE ignores ^\ and ^Z both -- nothing printed or stored. Following \n gets prompt back. The difference is not nice for Windows users, but I presume IDLE behavior is same as on *nix and consider consistency across platforms good and should be kept. If I understand, IDLE needs to install a SIGQUIT handler to terminate the background process 'resource'. That should work on Windows too as either SIGQUIT will never happens, or if it does, same should happen on Windows too. I know SIGKILL cannot be caught. What about SIGTERM? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 02:50:08 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 01 Apr 2012 00:50:08 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1333216265.49.0.971968767396.issue3177@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > (1) Platform doesn't support this feature -> raise NotImplemented It's better to not define the function if the platform doesn't support the feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 03:01:40 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 01 Apr 2012 01:01:40 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1333242100.81.0.325401772738.issue3177@psf.upfronthosting.co.za> ?ric Araujo added the comment: >> [...] do we get ENOENT if xdg-open exists but not the file?). > It's unambiguous. Python itself never opens the target file, it just passes the filepath string > along to the xdg-open command. If Popen raises EnvironmentError, then xdg-open could not be > executed. If the target file is nonexistent, then xdg-open will exit with status 2 (see > aforelinked manpage). Entirely different error mechanisms. You are right, I was confusing the layers! Good then. > So, the failure cases are: > (1) Platform doesn't support this feature -> raise NotImplemented Actually the exception is NotImplementedError. Its doc says that it?s to be used in a method that is intended to be overriden in subclasses, but I think it?s not wrong to > (2) Target file doesn't exist > (3) Target file is inaccessible > (4) No application is associated with the file type in question I think that instead of mapping error codes to custom exceptions, which is fragile and not trivial to maintain, we should just catch stderr and raise something like OSError(stderr). [Victor] >> It's better to not define the function if the platform doesn't support the feature. That?s easy to do if we can say detect the availability of a function in the libc, but here the function would depend on a program which could get removed or added between two calls to the function, so we have no choice. ---------- dependencies: -Finding programs in PATH, adding shutil.which _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 03:35:45 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 01 Apr 2012 01:35:45 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1333244145.27.0.542948647833.issue14304@psf.upfronthosting.co.za> Martin v. L?wis added the comment: pitrou: can you elaborate? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 03:42:26 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 01 Apr 2012 01:42:26 +0000 Subject: [issue14286] xxlimited.obj: unresolved external symbol __imp__PyObject_New In-Reply-To: <1331634330.54.0.0691133791003.issue14286@psf.upfronthosting.co.za> Message-ID: <1333244546.42.0.969977430088.issue14286@psf.upfronthosting.co.za> Martin v. L?wis added the comment: There is no debug version of the stable ABI, hence you can't build it in debug mode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 05:02:43 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 01 Apr 2012 03:02:43 +0000 Subject: [issue13238] Add shell command helpers to subprocess module In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za> Message-ID: <1333249363.52.0.295426083398.issue13238@psf.upfronthosting.co.za> Nick Coghlan added the comment: Bumping the target version for this issue to 3.4. There's a lot of active development in the shell convenience function space at the moment, including my shell_command, Vinay Sajip's sarge, Kenneth Reitz's envoy and the possibility of doing something inspired by Julia's approach to this problem. I'm not convinced enough that shell_command gets the security trade-offs right to push for this in the two months we have left before 3.3b1 (plus I have other things I want to work on). In the meantime, "pip install shell_command" is fairly straightforward (or similar for sarge, envoy or one of the other shell helper libraries). ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 05:05:38 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 01 Apr 2012 03:05:38 +0000 Subject: [issue14321] Do not run pgen during the build if files are up to date In-Reply-To: <1331831244.15.0.8026915878.issue14321@psf.upfronthosting.co.za> Message-ID: <1333249538.67.0.695831215317.issue14321@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: References to no longer used Parser/pgen.stamp file should be removed in: Makefile.pre.in .bzrignore .gitignore .hgignore ---------- nosy: +Arfrever resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 05:20:02 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 01 Apr 2012 03:20:02 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1333250402.95.0.457783276567.issue3177@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 05:28:26 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 01 Apr 2012 03:28:26 +0000 Subject: [issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za> Message-ID: <1333250906.43.0.133200637509.issue7839@psf.upfronthosting.co.za> Nick Coghlan added the comment: For the record, my shell access convenience API proposal is in issue 13238. I'm not going to push that for 3.3 though - convenient shell access from Python is currently an area with a lot of active third party development, so I think it's worthwhile continuing to be conservative on this topic rather than rushing ahead with blessing any particular approach for stdlib inclusion. To get back to RDM's specific proposal (that shell=True/False should constrain the acceptable types for the first positional argument to str/list respectively), I'm -1 on the idea. The reason I'm not a fan is the fact that, with "shell=True", you can use the *executable* argument to Popen to select a non-default shell. At that point, passing a list can make sense, even if it isn't useful for the default shell. On Windows, the implicit invocation of list2cmdline can already make this a useful thing to do. For the other way around, passing a string with "shell=False" can be a straightforward way to launch GUI applications from a script. Specifying executable directly can also have an effect on this case, too (although I forget the consequences) Now, what may make sense is to provide separate Popen.exec and Popen.shell *class methods* that correspond to shell=False and shell=True with the stricter type checking on the first argument (i.e. Popen.exec only accepts a list, POpen.shell only accepts a string). Another advantage of adding the two new class methods is that it would give us the opportunity to *change some of the defaults* (e.g making close_fds=True the default behaviour). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 06:00:02 2012 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 01 Apr 2012 04:00:02 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1332785811.84.0.616508221107.issue14417@psf.upfronthosting.co.za> Message-ID: <1333252802.42.0.271694929012.issue14417@psf.upfronthosting.co.za> Guido van Rossum added the comment: But the sleep(0.1) forces a thread switch so I consider that still cheating -- nobody in their right mind would consider calling sleep() inside __hash__. You can probably get it to fail without this by just doing a bunch of random computation in the __hash__ (and using a low sys.setswitchinterval() value). Or consider creating a key that consists of e.g. a tuple of 100 or 1000 Key instances -- hashing that will call the __hash__ on each of those, wasting a lot of cycles. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 07:08:48 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Sun, 01 Apr 2012 05:08:48 +0000 Subject: [issue14443] Distutils test failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <1333256928.81.0.830852005072.issue14443@psf.upfronthosting.co.za> Ross Lagerwall added the comment: The first bad revision is: changeset: 72818:27a36b05caed branch: 3.2 user: ?ric Araujo date: Sat Oct 08 00:34:13 2011 +0200 summary: Fix distutils byte-compilation to comply with PEP 3147 (#11254). Cheers ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 07:52:51 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 01 Apr 2012 05:52:51 +0000 Subject: [issue1641544] rlcompleter tab completion in pdb Message-ID: <1333259571.8.0.657453344926.issue1641544@psf.upfronthosting.co.za> Georg Brandl added the comment: Meanwhile I've added more comprehensive tab-completion to 3.3 for #14210. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 08:14:55 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 01 Apr 2012 06:14:55 +0000 Subject: [issue1396946] %ehrntDRT support for time.strptime Message-ID: <1333260895.62.0.737995808613.issue1396946@psf.upfronthosting.co.za> Georg Brandl added the comment: #3173 proposes an OS-independent strftime implementation. ---------- resolution: -> duplicate status: open -> closed superseder: -> external strftime for Python? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 08:31:36 2012 From: report at bugs.python.org (Chris Rebert) Date: Sun, 01 Apr 2012 06:31:36 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1333261896.41.0.117948428769.issue3177@psf.upfronthosting.co.za> Chris Rebert added the comment: >> (2) Target file doesn't exist >> (4) No application is associated with the file type in question > I think that instead of mapping error codes to custom exceptions, which is fragile and not trivial to maintain, we should just catch stderr and raise something like OSError(stderr) It runs counter to the goal of a cross-platform API if *all* the errors are platform-specific. I grant that a generic API cannot wrap *every* possible error, but (2) and (4) are amongst the most common+obvious failure modes and are (FWICT) explicitly reported by all 3 native interfaces. If we don't consolidate them, we'll basically be condemning non-trivial users to copying (or writing themselves, probably inferiorly) a chunk of boilerplate recipe code, and if we're fine with that, then why bother having (this in) the std lib at all? I don't think the handling code for them would be particularly fragile/onerous; we're talking a mere ~2 constants per platform, all tied to pretty-unlikely-to-change native interfaces. For context, here would be (AFAICT; I only have a Mac ATM) the constants in question: Windows: function return value: ERROR_FILE_NOT_FOUND, ERROR_PATH_NOT_FOUND SE_ERR_NOASSOC xdg-open (*nix): exit code: 2 3 Mac OS X: exit code 1 w/ stderr output: "The file XXX does not exist." "No application knows how to open XXX." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 08:58:09 2012 From: report at bugs.python.org (Chris Rebert) Date: Sun, 01 Apr 2012 06:58:09 +0000 Subject: [issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za> Message-ID: <1333263489.29.0.672519296645.issue7839@psf.upfronthosting.co.za> Chris Rebert added the comment: > The reason I'm not a fan is the fact that, with "shell=True", you can use the *executable* argument to Popen to select a non-default shell. At that point, passing a list can make sense, even if it isn't useful for the default shell. Modulo Windows, at that point, why not just run the shell explicitly (i.e. shell=False, args=['my_sh', ...])? Also, a '-c' argument will be forcibly prepended to the passed-in `args` in your case, which may frustrate such use-cases. > For the other way around, passing a string with "shell=False" can be a straightforward way to launch GUI applications from a script. And they may need to eventually pass it (an) argument(s), and when that happens, cue confusion! There's a reason the `subprocess` docs feature the not-strictly-necessary clause "[a str `args` w/ shell=False] will only work if the program is being given no arguments". The distinction regularly trips/tripped users up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 09:10:30 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Apr 2012 07:10:30 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1331932171.45.0.56771909125.issue14339@psf.upfronthosting.co.za> Message-ID: <1333264230.5.0.438674047248.issue14339@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No, I do not think that any application will significantly speeded up. In fact, it is not optimization, and getting rid of the apparent pessimization. In addition to increasing the speed, memory fragmentation is reduced. The patch has a minimum size, the new code is not larger and not more complex than the old one, it is similar to code already used in this file, there are small nonconditional advantages. I see no reason not to accept the changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 09:20:10 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 01 Apr 2012 07:20:10 +0000 Subject: [issue13507] Modify OS X installer builds to package liblzma for the new lzma module In-Reply-To: <1322647679.29.0.297920473861.issue13507@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 0e1177499762 by Ned Deily in branch 'default': Issue #13507: OS X installer builds now build liblzma for the new http://hg.python.org/cpython/rev/0e1177499762 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 09:23:18 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 01 Apr 2012 07:23:18 +0000 Subject: [issue13507] Modify OS X installer builds to package liblzma for the new lzma module In-Reply-To: <1322647679.29.0.297920473861.issue13507@psf.upfronthosting.co.za> Message-ID: <1333264998.67.0.0365604043751.issue13507@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the patch. Applied to default for 3.3. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 09:38:48 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Apr 2012 07:38:48 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1333265928.34.0.251914421838.issue14304@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: ''.join(c if ord(c) < 0x10000 else escape(c) for c in s) ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 10:07:51 2012 From: report at bugs.python.org (py.user) Date: Sun, 01 Apr 2012 08:07:51 +0000 Subject: [issue14460] In re's positive lookbehind assertion repetition works Message-ID: <1333267671.53.0.559378302882.issue14460@psf.upfronthosting.co.za> New submission from py.user : >>> import re >>> re.search(r'(?<=a){100,200}bc', 'abc', re.DEBUG) max_repeat 100 200 assert -1 literal 97 literal 98 literal 99 <_sre.SRE_Match object at 0xb7429f38> >>> re.search(r'(?<=a){100,200}bc', 'abc', re.DEBUG).group() 'bc' >>> I expected "nothing to repeat" ---------- components: Regular Expressions messages: 157264 nosy: ezio.melotti, mrabarnett, py.user priority: normal severity: normal status: open title: In re's positive lookbehind assertion repetition works type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 10:12:00 2012 From: report at bugs.python.org (py.user) Date: Sun, 01 Apr 2012 08:12:00 +0000 Subject: [issue14461] In re's positive lookbehind assertion documentation match() cannot match Message-ID: <1333267920.68.0.0890741084259.issue14461@psf.upfronthosting.co.za> New submission from py.user : http://docs.python.org/py3k/library/re.html "Note that patterns which start with positive lookbehind assertions will never match at the beginning of the string being searched; you will most likely want to use the search() function rather than the match() function:" >>> re.match(r'(?<=^)abc', 'abc').group() 'abc' >>> re.match(r'(?<=\b)abc', 'abc').group() 'abc' >>> re.match(r'(?<=\A)abc', 'abc').group() 'abc' >>> re.match(r'(?<=\A)abc', 'abc', re.DEBUG).group() assert -1 at at_beginning_string literal 97 literal 98 literal 99 'abc' >>> in some cases match() can match ---------- assignee: docs at python components: Documentation, Regular Expressions messages: 157265 nosy: docs at python, ezio.melotti, mrabarnett, py.user priority: normal severity: normal status: open title: In re's positive lookbehind assertion documentation match() cannot match versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 10:16:48 2012 From: report at bugs.python.org (py.user) Date: Sun, 01 Apr 2012 08:16:48 +0000 Subject: [issue14462] In re's named group the name cannot contain unicode characters Message-ID: <1333268208.65.0.802050679023.issue14462@psf.upfronthosting.co.za> New submission from py.user : http://docs.python.org/py3k/library/re.html "(?P...) Similar to regular parentheses, but the substring matched by the group is accessible within the rest of the regular expression via the symbolic group name name. Group names must be valid Python identifiers, and each group name must be defined only once within a regular expression." >>> chr(255) '?' >>> '?'.isidentifier() True >>> import re >>> re.search(r'(?Pa)', 'abc') Traceback (most recent call last): File "/usr/local/lib/python3.2/functools.py", line 176, in wrapper result = cache[key] KeyError: (, '(?Pa)', 0) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.2/re.py", line 158, in search return _compile(pattern, flags).search(string) File "/usr/local/lib/python3.2/re.py", line 255, in _compile return _compile_typed(type(pattern), pattern, flags) File "/usr/local/lib/python3.2/functools.py", line 180, in wrapper result = user_function(*args, **kwds) File "/usr/local/lib/python3.2/re.py", line 267, in _compile_typed return sre_compile.compile(pattern, flags) File "/usr/local/lib/python3.2/sre_compile.py", line 491, in compile p = sre_parse.parse(p, flags) File "/usr/local/lib/python3.2/sre_parse.py", line 692, in parse p = _parse_sub(source, pattern, 0) File "/usr/local/lib/python3.2/sre_parse.py", line 315, in _parse_sub itemsappend(_parse(source, state)) File "/usr/local/lib/python3.2/sre_parse.py", line 552, in _parse raise error("bad character in group name") sre_constants.error: bad character in group name >>> also: (?P=name) (?(name)yes|no) \g ---------- assignee: docs at python components: Documentation, Regular Expressions messages: 157266 nosy: docs at python, ezio.melotti, mrabarnett, py.user priority: normal severity: normal status: open title: In re's named group the name cannot contain unicode characters type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 11:27:52 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 01 Apr 2012 09:27:52 +0000 Subject: [issue14463] _decimal.so compile fails in OS X installer builds Message-ID: <1333272472.49.0.502934035814.issue14463@psf.upfronthosting.co.za> New submission from Ned Deily : It may also fail in other builds where the build directory is not the same as the source directory. The problem is in setup.py function _decimal_ext which fails to create an absolute path for the libmpdec include source directory. Patch follows. ---------- assignee: ned.deily components: Build messages: 157267 nosy: ned.deily, skrah priority: normal severity: normal status: open title: _decimal.so compile fails in OS X installer builds versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 11:31:42 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 01 Apr 2012 09:31:42 +0000 Subject: [issue14463] _decimal.so compile fails in OS X installer builds In-Reply-To: <1333272472.49.0.502934035814.issue14463@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset ac60138522fc by Ned Deily in branch 'default': Issue #14463: Prevent _decimal.so compile failures in OS X installer builds. http://hg.python.org/cpython/rev/ac60138522fc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 11:32:49 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 01 Apr 2012 09:32:49 +0000 Subject: [issue14463] _decimal.so compile fails in OS X installer builds In-Reply-To: <1333272472.49.0.502934035814.issue14463@psf.upfronthosting.co.za> Message-ID: <1333272769.66.0.662067198606.issue14463@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 12:06:50 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 01 Apr 2012 10:06:50 +0000 Subject: [issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za> Message-ID: <1333274810.53.0.552288872847.issue7839@psf.upfronthosting.co.za> Andrew Svetlov added the comment: After trying to make a patch I found what current test suite itself has calls like (str, shell=False), (bytes, shell=True) and (['shell command'], shell=True). We can: 1. Implement Eric's suggestion with fixing/removing broken tests. 2. Add Pope.shell and Popen.exec as Nick propose. I don't like former because it changes already existing contracts fixed and published by explicit unittests without strong reason. Also Nick pointed reasons why user may need existing functionality. Adding new 'safe' shell and exec classmethods as prime entrypoints for Popen make sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 12:10:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 10:10:09 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1333252802.42.0.271694929012.issue14417@psf.upfronthosting.co.za> Message-ID: <1333274704.3449.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > But the sleep(0.1) forces a thread switch so I consider that still > cheating -- nobody in their right mind would consider calling sleep() > inside __hash__. Well, cheating is fair game when trying to test borderline cases, isn't it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 12:17:17 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 01 Apr 2012 10:17:17 +0000 Subject: [issue14440] Close background process if IDLE closes abnormally. In-Reply-To: <1333027712.59.0.103811521392.issue14440@psf.upfronthosting.co.za> Message-ID: <1333275437.34.0.629484311122.issue14440@psf.upfronthosting.co.za> Andrew Svetlov added the comment: We can install signal handlers for everything what can stop process but I prefer to pass IDLE pid to subintepreter and periodically check for prime process existing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 13:05:59 2012 From: report at bugs.python.org (Matt Joiner) Date: Sun, 01 Apr 2012 11:05:59 +0000 Subject: [issue14408] Support ./python -m unittest in the stdlib tests In-Reply-To: <1332735237.61.0.855199980132.issue14408@psf.upfronthosting.co.za> Message-ID: <1333278359.34.0.0328384763958.issue14408@psf.upfronthosting.co.za> Matt Joiner added the comment: The patch attached, rejigs the TestCase inheritance in test.test_socket so that tests run correctly using unittest discovery. Recent changes have made test_queue, and test_threading run without similar fixes, so I don't think fixes for those are necessary anymore. ---------- Added file: http://bugs.python.org/file25087/test.test_socket-discoverability.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 13:08:49 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 01 Apr 2012 11:08:49 +0000 Subject: [issue14394] missing links on performance claims of cdecimal In-Reply-To: <1332496271.62.0.623566153633.issue14394@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 6ba569924986 by Stefan Krah in branch 'default': Issue #14394: Use elaborate phrases that boil down to "one to two orders http://hg.python.org/cpython/rev/6ba569924986 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 13:10:46 2012 From: report at bugs.python.org (Thomas Spura) Date: Sun, 01 Apr 2012 11:10:46 +0000 Subject: [issue13934] sqlite3 test typo In-Reply-To: <1328294661.43.0.135509150445.issue13934@psf.upfronthosting.co.za> Message-ID: <1333278646.27.0.0419328023917.issue13934@psf.upfronthosting.co.za> Thomas Spura added the comment: It might be good to add some documentation to the sqlite3 module and describe that version_info is only the PYSQLITE_VERSION and not the version of the sqlite library. ---------- nosy: +tomspur _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 13:17:46 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 01 Apr 2012 11:17:46 +0000 Subject: [issue14394] Add speed improvement note to the decimal docs. In-Reply-To: <1332496271.62.0.623566153633.issue14394@psf.upfronthosting.co.za> Message-ID: <1333279066.77.0.304714918179.issue14394@psf.upfronthosting.co.za> Stefan Krah added the comment: Leaving this open since a "New in version 3.3" speed improvement note in the docs would be useful. ---------- title: missing links on performance claims of cdecimal -> Add speed improvement note to the decimal docs. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 13:29:55 2012 From: report at bugs.python.org (Matt Joiner) Date: Sun, 01 Apr 2012 11:29:55 +0000 Subject: [issue14408] Support ./python -m unittest in the stdlib tests In-Reply-To: <1332735237.61.0.855199980132.issue14408@psf.upfronthosting.co.za> Message-ID: <1333279795.45.0.0629369731735.issue14408@psf.upfronthosting.co.za> Matt Joiner added the comment: Attached is a patch for test_concurrent_futures, similar to the patch for test_socket. ---------- Added file: http://bugs.python.org/file25088/test_concurrent_futures-unittest-discoverability.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 13:48:08 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 01 Apr 2012 11:48:08 +0000 Subject: [issue14387] Include\accu.h incompatible with Windows.h In-Reply-To: <1332417184.03.0.15615521555.issue14387@psf.upfronthosting.co.za> Message-ID: <1333280888.87.0.587275702453.issue14387@psf.upfronthosting.co.za> Stefan Krah added the comment: > Should I contact the extension's author(s)/maintainer(s) and tell them about this ordering requirement? FWIW, it is the recommended way in the docs. The Python build itself has been fixed. Does the http://code.google.com/p/apsw/ module build now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 14:14:24 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 01 Apr 2012 12:14:24 +0000 Subject: [issue14419] Faster ascii decoding In-Reply-To: <1332795378.48.0.327832712874.issue14419@psf.upfronthosting.co.za> Message-ID: <1333282464.79.0.582974568219.issue14419@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 14:14:46 2012 From: report at bugs.python.org (Yuval Greenfield) Date: Sun, 01 Apr 2012 12:14:46 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1333282486.34.0.300291546851.issue13968@psf.upfronthosting.co.za> Yuval Greenfield added the comment: I found this comprehensive description of the '**' convention at http://www.codeproject.com/Articles/2809/Recursive-patterned-File-Globbing that can translate directly to unittests. I'd like to fix the patch for these specs but should it be in a new rglob function or in the existing glob.glob()? I think it should be a new one to avoid any edge-case compatibility concerns even though on face value there shouldn't be any. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 14:16:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 12:16:35 +0000 Subject: [issue14464] reference loss in test_xml_etree_c Message-ID: <1333282595.42.0.638497827613.issue14464@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This is quite recent. $ ./python -m test -R 3:2 test_xml_etree_c [1/1] test_xml_etree_c beginning 5 repetitions 12345 ..... test_xml_etree_c leaked [-2, -2] references, sum=-4 ---------- assignee: eli.bendersky components: Library (Lib) messages: 157279 nosy: eli.bendersky, flox, pitrou priority: critical severity: normal stage: needs patch status: open title: reference loss in test_xml_etree_c type: resource usage versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 14:20:44 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 12:20:44 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1333282486.34.0.300291546851.issue13968@psf.upfronthosting.co.za> Message-ID: <1333282537.3449.2.camel@localhost.localdomain> Antoine Pitrou added the comment: > I found this comprehensive description of the '**' convention at > http://www.codeproject.com/Articles/2809/Recursive-patterned-File-Globbing that can translate directly to unittests. > > I'd like to fix the patch for these specs but should it be in a new > rglob function or in the existing glob.glob()? I think it should be a > new one to avoid any edge-case compatibility concerns even though on > face value there shouldn't be any. I think it should be the existing glob.glob(). We won't introduce a new function any time we add a new syntactic feature in the glob mini-language. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 14:25:51 2012 From: report at bugs.python.org (Yuval Greenfield) Date: Sun, 01 Apr 2012 12:25:51 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1333283151.5.0.655801777197.issue13968@psf.upfronthosting.co.za> Yuval Greenfield added the comment: I don't have a strong opinion on "rglob vs glob" so whichever way the majority here thinks is fine by me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 14:58:20 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 01 Apr 2012 12:58:20 +0000 Subject: [issue14464] reference loss in test_xml_etree_c In-Reply-To: <1333282595.42.0.638497827613.issue14464@psf.upfronthosting.co.za> Message-ID: <1333285100.61.0.286261862252.issue14464@psf.upfronthosting.co.za> Eli Bendersky added the comment: Thanks, I'll try to investigate this ASAP ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 14:59:58 2012 From: report at bugs.python.org (Stefan Krah) Date: Sun, 01 Apr 2012 12:59:58 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1332785811.84.0.616508221107.issue14417@psf.upfronthosting.co.za> Message-ID: <1333285198.25.0.724272912785.issue14417@psf.upfronthosting.co.za> Stefan Krah added the comment: OK, here's a version with a low switch interval. Of course it's also contrived, but it works. Generally I'd appreciate the RuntimeError, since it's a hint that something needs to be rewritten in an application. It might be a problem if this started to occur sporadically in a production app under a high system load. But I haven't managed to trigger the exception just by increasing the system load. I always had to use the same low switch interval. ---------- Added file: http://bugs.python.org/file25089/hammer_dict_switchinterval.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 15:18:23 2012 From: report at bugs.python.org (Ernest N. Mamikonyan) Date: Sun, 01 Apr 2012 13:18:23 +0000 Subject: [issue14449] argparse optional arguments should follow getopt_long(3) In-Reply-To: <1333071108.35.0.783642355211.issue14449@psf.upfronthosting.co.za> Message-ID: <1951895.RDbGZxQq7N@turing> Ernest N. Mamikonyan added the comment: Yes, it is incompatible. But that's because the current behavior is incompatible with standard (getopt_long(3)) practice. Or perhaps, you can add another option that implements the optional argument semantics of GNU's getopt_long(3). In any case, I understand. If you figure out some other way, please let me know (or document it). Thanks much, Ernest Mamikonyan ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 15:25:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 13:25:41 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1333285198.25.0.724272912785.issue14417@psf.upfronthosting.co.za> Message-ID: <1333286435.3449.4.camel@localhost.localdomain> Antoine Pitrou added the comment: > OK, here's a version with a low switch interval. Of course it's also > contrived, but it works. The drawback of using setswitchinterval() is that it makes the test less reusable by other implementations (or perhaps it will succeed without actually checking the desired behaviour). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 15:29:20 2012 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 01 Apr 2012 13:29:20 +0000 Subject: [issue14098] provide public C-API for reading/setting sys.exc_info() In-Reply-To: <1329983921.26.0.0291312337524.issue14098@psf.upfronthosting.co.za> Message-ID: <1333286960.44.0.182710302477.issue14098@psf.upfronthosting.co.za> Stefan Behnel added the comment: This is now implemented in PyPy: https://bitbucket.org/pypy/pypy/changeset/623bcea85df3 Are there any objections to applying the equivalent patch to CPython? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 15:42:42 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Apr 2012 13:42:42 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1333287762.84.0.000642888714539.issue13968@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For "**" globbing see http://ant.apache.org/manual/dirtasks.html#patterns . If we extend pattern syntax of templates, why not implement Perl, Tcl or Bash extensions? ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 15:43:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 13:43:13 +0000 Subject: [issue14464] reference loss in test_xml_etree_c In-Reply-To: <1333282595.42.0.638497827613.issue14464@psf.upfronthosting.co.za> Message-ID: <1333287793.23.0.979031579773.issue14464@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The culprit is 0ca32013d77e. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 16:03:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 14:03:26 +0000 Subject: [issue11668] _multiprocessing.Connection.poll with timeout uses polling under Windows In-Reply-To: <1301012856.06.0.501822966935.issue11668@psf.upfronthosting.co.za> Message-ID: <1333289006.54.0.34231671182.issue11668@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is totally outdated by the new Connection implementation in 3.3. ---------- resolution: -> out of date stage: -> committed/rejected status: open -> closed superseder: -> Parent process hanging in multiprocessing if children terminate unexpectedly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 16:04:52 2012 From: report at bugs.python.org (Yuval Greenfield) Date: Sun, 01 Apr 2012 14:04:52 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1333289092.83.0.261582533058.issue13968@psf.upfronthosting.co.za> Yuval Greenfield added the comment: On Sun, Apr 1, 2012 at 4:42 PM, Serhiy Storchaka wrote: > For "**" globbing see http://ant.apache.org/manual/dirtasks.html#patterns They mention that "mypackage/test/ is interpreted as if it were mypackage/test/**" so that's not really an option. I'm pretty sure we should only recurse if "**" appears explicitly. > If we extend pattern syntax of templates, why not implement Perl, Tcl or > Bash extensions? > I'm not sure what you mean here but if it's that ##{} stuff then it should probably be discussed in a separate issue as it's not related to recursive globs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 16:14:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 01 Apr 2012 14:14:43 +0000 Subject: [issue13019] bytearrayobject.c: refleak In-Reply-To: <1316530611.41.0.519397979389.issue13019@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 03396c9ffe8c by Antoine Pitrou in branch '3.2': Issue #13019: Fix potential reference leaks in bytearray.extend(). http://hg.python.org/cpython/rev/03396c9ffe8c New changeset 015c546615ca by Antoine Pitrou in branch 'default': Issue #13019: Fix potential reference leaks in bytearray.extend(). http://hg.python.org/cpython/rev/015c546615ca ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 16:17:12 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 01 Apr 2012 14:17:12 +0000 Subject: [issue13019] bytearrayobject.c: refleak In-Reply-To: <1316530611.41.0.519397979389.issue13019@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset d3a82a26c705 by Antoine Pitrou in branch '2.7': Issue #13019: Fix potential reference leaks in bytearray.extend(). http://hg.python.org/cpython/rev/d3a82a26c705 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 16:17:44 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 14:17:44 +0000 Subject: [issue13019] bytearrayobject.c: refleak In-Reply-To: <1316530611.41.0.519397979389.issue13019@psf.upfronthosting.co.za> Message-ID: <1333289864.93.0.0209712085934.issue13019@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the patch. Sorry it took so long to be committed... ---------- nosy: +pitrou resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 16:40:49 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 01 Apr 2012 14:40:49 +0000 Subject: [issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za> Message-ID: <1333291249.72.0.198379083962.issue7839@psf.upfronthosting.co.za> R. David Murray added the comment: Which just goes to show that using Popen correctly is not obvious, I suppose. Given that adding these errors *would* break backward compatibility, there would have to be a deprecation if it was done. Personally I don't see the point in adding new class methods (complicating the interface) unless we are going to deprecate the current methods...in which case why not just deprecate the incorrect way of calling it? (Note: I say incorrect because the 'call a different shell' variant *doesn't work* unless you write a custom shell that ignores '-c', and as Chris points out there's no functionality *gained* by the windows variation, and there is confusion introduced as to exactly what is going on). So, if we aren't going to deprecate the "incorrect" calls, I vote for just closing this issue as "won't fix". (I suppose that a third alternative exists: make the "incorrect" calls actually do something useful while preserving backward compatibility with the existing behavior. That may be difficult, especially doing it in a way that logically consistent cross-platform.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 16:41:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 01 Apr 2012 14:41:48 +0000 Subject: [issue14464] reference loss in test_xml_etree_c In-Reply-To: <1333282595.42.0.638497827613.issue14464@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset c5cf48752d81 by Eli Bendersky in branch 'default': Removing the test of Element that causes ref-leak in GC (issue #14464). http://hg.python.org/cpython/rev/c5cf48752d81 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 16:43:23 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 01 Apr 2012 14:43:23 +0000 Subject: [issue14065] Element should support cyclic GC In-Reply-To: <1329755208.03.0.143933032526.issue14065@psf.upfronthosting.co.za> Message-ID: <1333291403.31.0.279690043118.issue14065@psf.upfronthosting.co.za> Eli Bendersky added the comment: Re-opening, since GC collection of length-2 cycles cause refleaks (Issue #14464). For now the test was reverted in changeset c5cf48752d81 - it has to be put back when this is fixed. ---------- resolution: fixed -> stage: committed/rejected -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 16:44:10 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 01 Apr 2012 14:44:10 +0000 Subject: [issue14464] reference loss in test_xml_etree_c In-Reply-To: <1333282595.42.0.638497827613.issue14464@psf.upfronthosting.co.za> Message-ID: <1333291450.1.0.244809538467.issue14464@psf.upfronthosting.co.za> Eli Bendersky added the comment: For now the refcounts will be clean. Work on the problem will continue in its original issue (#14065). ---------- resolution: -> duplicate stage: needs patch -> committed/rejected status: open -> closed superseder: -> Element should support cyclic GC _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 17:15:46 2012 From: report at bugs.python.org (Popa Claudiu) Date: Sun, 01 Apr 2012 15:15:46 +0000 Subject: [issue14151] multiprocessing.connection.Listener fails with invalid address In-Reply-To: <1330437098.57.0.315162934772.issue14151@psf.upfronthosting.co.za> Message-ID: <1333293346.27.0.46963158667.issue14151@psf.upfronthosting.co.za> Popa Claudiu added the comment: Here are the two diffs. Hope they are good this time. ---------- Added file: http://bugs.python.org/file25090/connection.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 17:15:59 2012 From: report at bugs.python.org (Popa Claudiu) Date: Sun, 01 Apr 2012 15:15:59 +0000 Subject: [issue14151] multiprocessing.connection.Listener fails with invalid address In-Reply-To: <1330437098.57.0.315162934772.issue14151@psf.upfronthosting.co.za> Message-ID: <1333293359.78.0.519029145718.issue14151@psf.upfronthosting.co.za> Changes by Popa Claudiu : Added file: http://bugs.python.org/file25091/test_multiprocessing.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 17:28:04 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 01 Apr 2012 15:28:04 +0000 Subject: [issue14465] add feature to prettify XML output Message-ID: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za> New submission from Tshepang Lekhonkhobe : I often miss lxml's "pretty_print=True" functionality. Can you implement something similar. ---------- components: Library (Lib) messages: 157299 nosy: eli.bendersky, tshepang priority: normal severity: normal status: open title: add feature to prettify XML output versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 17:29:13 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 01 Apr 2012 15:29:13 +0000 Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za> Message-ID: <1333294153.88.0.790500150011.issue14465@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- title: add feature to prettify XML output -> xml.etree.ElementTree: add feature to prettify XML output _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 17:30:59 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 01 Apr 2012 15:30:59 +0000 Subject: [issue14151] multiprocessing.connection.Listener fails with invalid address In-Reply-To: <1330437098.57.0.315162934772.issue14151@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 273d7502ced1 by Antoine Pitrou in branch '3.2': Issue #14151: Raise a ValueError, not a NameError, when trying to create http://hg.python.org/cpython/rev/273d7502ced1 New changeset 42b29aea1c98 by Antoine Pitrou in branch 'default': Issue #14151: Raise a ValueError, not a NameError, when trying to create http://hg.python.org/cpython/rev/42b29aea1c98 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 17:32:04 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 15:32:04 +0000 Subject: [issue14151] multiprocessing.connection.Listener fails with invalid address In-Reply-To: <1330437098.57.0.315162934772.issue14151@psf.upfronthosting.co.za> Message-ID: <1333294324.32.0.466834987018.issue14151@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you! For the record, the recommended workflow to produce patches is to use Mercurial: see http://docs.python.org/devguide/setup.html#getting-the-source-code so that you only have to type e.g. "hg diff" to get a diff of all your local changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 17:32:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 15:32:20 +0000 Subject: [issue14151] multiprocessing.connection.Listener fails with invalid address In-Reply-To: <1330437098.57.0.315162934772.issue14151@psf.upfronthosting.co.za> Message-ID: <1333294340.78.0.321349221256.issue14151@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 17:33:51 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 15:33:51 +0000 Subject: [issue14466] Rip out mq instructions Message-ID: <1333294431.46.0.420841825384.issue14466@psf.upfronthosting.co.za> New submission from Antoine Pitrou : The devguide describes a mq-based approach (*) for generating patches, but it seems nobody (almost) uses it. We should therefore replace that description with a more traditional one ("hg diff"). (*) http://docs.python.org/devguide/patch.html#tool-usage ---------- components: Devguide messages: 157302 nosy: ezio.melotti, pitrou priority: normal severity: normal stage: needs patch status: open title: Rip out mq instructions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 17:34:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 15:34:05 +0000 Subject: [issue14466] Rip out mq instructions In-Reply-To: <1333294431.46.0.420841825384.issue14466@psf.upfronthosting.co.za> Message-ID: <1333294445.82.0.472936413312.issue14466@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 17:35:04 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 15:35:04 +0000 Subject: [issue14467] Avoid exotic documentation in the devguide Message-ID: <1333294504.16.0.644587677187.issue14467@psf.upfronthosting.co.za> New submission from Antoine Pitrou : The devguide is growing exotic documentation about e.g. how to install GNU autoconf. I think this should be avoided, or relegated to the FAQ. ---------- components: Devguide messages: 157303 nosy: dmalcolm, eric.araujo, ezio.melotti, pitrou, rosslagerwall priority: normal severity: normal status: open title: Avoid exotic documentation in the devguide _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 17:39:53 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 15:39:53 +0000 Subject: [issue14229] On KeyboardInterrupt, the exit code should mirror the signal number In-Reply-To: Message-ID: <1333294486.3449.5.camel@localhost.localdomain> Antoine Pitrou added the comment: > Because calling exit() is the right way to end a process. For example, > it does the following: > - atexit()-registered finalizers are run > - stdio streams are flushed and closed (although it could probably > done by the interpreter) > - files created with tmpfile() are removed (on POSIX systems, they're > removed after creation, but you can imagine an implementation where > they would need to be explicitely removed upon close) > > This would not be performed if the signal is raised. > Since the user has the possibility of restoring default signal > handlers with SIG_DFL, I think we could stcik with the current > behavior. Ah, ok, I agree with you, then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 17:50:34 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 01 Apr 2012 15:50:34 +0000 Subject: [issue14467] Avoid exotic documentation in the devguide In-Reply-To: <1333294504.16.0.644587677187.issue14467@psf.upfronthosting.co.za> Message-ID: <1333295434.29.0.988488083496.issue14467@psf.upfronthosting.co.za> ?ric Araujo added the comment: Agreed. The autoconf doc comes from #7997, which required a FAQ entry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 17:50:44 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 01 Apr 2012 15:50:44 +0000 Subject: [issue14467] Avoid exotic documentation in the devguide In-Reply-To: <1333294504.16.0.644587677187.issue14467@psf.upfronthosting.co.za> Message-ID: <1333295444.35.0.96411677394.issue14467@psf.upfronthosting.co.za> ?ric Araujo added the comment: asked for* ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 17:59:35 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 01 Apr 2012 15:59:35 +0000 Subject: [issue14466] Rip out mq instructions In-Reply-To: <1333294431.46.0.420841825384.issue14466@psf.upfronthosting.co.za> Message-ID: <1333295975.69.0.627020030564.issue14466@psf.upfronthosting.co.za> ?ric Araujo added the comment: Yes please. We already have text if we look at the history before 73e11f64a704; we only need to agree on recommending ?uncommitted changes in a clone? (which is okay to share patches but not for not ideal for more than one person working on something), named branches (what was in the previous text, because it makes it easy to run hg diff -r default and such commands) or bookmarks (lightweight named branches that some people recommend; I?m not sure how they?re better, given that in the end we generate a patch and make a new commit). I, for one, use both uncommitted-changes and named branches; the former is easiest, but the latter safer: if I screw up a merge in a clone where I use a named branch, I can revert and retry the merge, but if I screw up merging pulled changes with my uncommitted edits, I risk losing them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 18:01:14 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 16:01:14 +0000 Subject: [issue14466] Rip out mq instructions In-Reply-To: <1333295975.69.0.627020030564.issue14466@psf.upfronthosting.co.za> Message-ID: <1333295768.3449.6.camel@localhost.localdomain> Antoine Pitrou added the comment: > I, for one, use both uncommitted-changes and named branches; the > former is easiest, but the latter safer: if I screw up a merge in a > clone where I use a named branch, I can revert and retry the merge, > but if I screw up merging pulled changes with my uncommitted edits, I > risk losing them. I think uncommitted changes is fine for a simple introduction. hg experts can use whatever they want without needing our help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 18:05:39 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Sun, 01 Apr 2012 16:05:39 +0000 Subject: [issue14467] Avoid exotic documentation in the devguide In-Reply-To: <1333294504.16.0.644587677187.issue14467@psf.upfronthosting.co.za> Message-ID: <1333296339.01.0.945063038794.issue14467@psf.upfronthosting.co.za> Ross Lagerwall added the comment: I'm happy to remove the bit about *installing* autoconf altogether. Do you think the Autoconf section (about regenerating configure) should stay where it is or be moved somewhere else? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 18:07:14 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 16:07:14 +0000 Subject: [issue14467] Avoid exotic documentation in the devguide In-Reply-To: <1333296339.01.0.945063038794.issue14467@psf.upfronthosting.co.za> Message-ID: <1333296128.3449.7.camel@localhost.localdomain> Antoine Pitrou added the comment: > Do you think the Autoconf section (about regenerating configure) > should stay where it is or be moved somewhere else? I think it's a fairly rare thing to do (regenerating configure), so perhaps it can migrate to a FAQ entry. (besides, I think most people knowing how to edit a configure script would also know you have to regenerate it) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 18:07:47 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 01 Apr 2012 16:07:47 +0000 Subject: [issue14468] Update cloning guidelines in devguide Message-ID: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> New submission from ?ric Araujo : The devguide recommends using hg update to switch between branches in one repository. This is only practical if you build Python in a custom (sub)directory, otherwise you?d need to either do the configure-make-test dance when merging/porting patches, or skip testing. I?ve always used one clone per Python version, where I can keep the compiled artifacts; it makes it easy to see what a file looks like in any of the three versions, easy to work on different things in the different repos (like fixing something in 3.2 that you noticed while you were adding something to 3.3), it is cheap thanks to hardlinks, fast because you run hg pull instead of hg update to merge a patch from 3.2, and is just the simplest thing that works. I don?t think anyone uses the one-clone-with-update approach, so I think we should rewrite the instructions to talk about one clone per version. ---------- components: Devguide messages: 157311 nosy: eric.araujo, ezio.melotti, ncoghlan, pitrou priority: normal severity: normal status: open title: Update cloning guidelines in devguide _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 18:20:10 2012 From: report at bugs.python.org (shinta.nakayama) Date: Sun, 01 Apr 2012 16:20:10 +0000 Subject: [issue14450] Log rotate cant execute in Windows. (logging module) In-Reply-To: <1333089873.7.0.17857342525.issue14450@psf.upfronthosting.co.za> Message-ID: <1333297210.39.0.740681849012.issue14450@psf.upfronthosting.co.za> shinta.nakayama added the comment: Thank you Armaury. Allowing your advice,I tried that code on other machine(Windows7 without Antivirus). But it was same result. Windows says "process cant access to file. that file is using other process.". And could not rotate the logs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 18:27:05 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 01 Apr 2012 16:27:05 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1332785811.84.0.616508221107.issue14417@psf.upfronthosting.co.za> Message-ID: <1333297625.14.0.513992446401.issue14417@psf.upfronthosting.co.za> R. David Murray added the comment: Antoine: I don't think the point of this code is to come up with a unit (or other) test for the behavior, but to try to determine empirically whether or not this error is likely to be an issue in naive production code (whether it is existing 3.x code or stuff ported from Python2). Thus the mention of "cheating" (doing things production code would not be doing). The answer so far appears to be "no", which is good. Which in the context of this particular issue then raises the question of whether there is in fact any additional support beyond the normal threading lock facilities that we want to provide in the stdlib. And the answer to that is thus probably no as well, since code likely to run into the error is also likely to need locking around the dict in question *anyway*. Which is what Guido's intuition was to begin with. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 18:32:11 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 01 Apr 2012 16:32:11 +0000 Subject: [issue14467] Avoid exotic documentation in the devguide In-Reply-To: <1333294504.16.0.644587677187.issue14467@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 27be97280cff by Ross Lagerwall in branch 'default': Issue 14467: Simplify Autoconf section and move it to FAQ. http://hg.python.org/devguide/rev/27be97280cff ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 18:39:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 16:39:06 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1333297625.14.0.513992446401.issue14417@psf.upfronthosting.co.za> Message-ID: <1333298039.3449.11.camel@localhost.localdomain> Antoine Pitrou added the comment: > Antoine: I don't think the point of this code is to come up with a > unit (or other) test for the behavior, but to try to determine > empirically whether or not this error is likely to be an issue in > naive production code (whether it is existing 3.x code or stuff ported > from Python2). Thus the mention of "cheating" (doing things production > code would not be doing). > > The answer so far appears to be "no", which is good. I find this a bit lacking. Production code is used in all kinds of settings that we didn't simulate here. Besides, a very sporadic bug is no better than an easily reproduced one. The tracker already has its share of people pointing at weird sporadic errors in their log files. > And the answer to that is thus probably no as well, since code likely > to run into the error is also likely to need locking around the dict > in question *anyway*. Depends on the application really. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 18:43:00 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Apr 2012 16:43:00 +0000 Subject: [issue14469] Python 3 documentation links Message-ID: <1333298580.51.0.119482106967.issue14469@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : "Other resources" links in the Python 3 documentation refer to the Python 2.7 online documentation. It is also strange that http://python.org/doc (for example from issue tracker sidebar) refer to the Python 2.7 documentation. ---------- assignee: docs at python components: Documentation messages: 157316 nosy: docs at python, storchaka priority: normal severity: normal status: open title: Python 3 documentation links versions: Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 18:43:46 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 01 Apr 2012 16:43:46 +0000 Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za> Message-ID: <1333298626.96.0.453716453944.issue14465@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 18:49:33 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 01 Apr 2012 16:49:33 +0000 Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za> Message-ID: <1333298973.39.0.747586545329.issue14465@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Would you like to provide a patch? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 18:51:48 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 01 Apr 2012 16:51:48 +0000 Subject: [issue14469] Python 3 documentation links In-Reply-To: <1333298580.51.0.119482106967.issue14469@psf.upfronthosting.co.za> Message-ID: <1333299108.43.0.728144361406.issue14469@psf.upfronthosting.co.za> R. David Murray added the comment: The FAQ link (and removing the new style class link, but I think there is already an issue for that) is the only one I see that should be pointing to 3.x that isn't. python.org/doc and docs.python.org is intentionally the 2.7 docs for now. We haven't decided when we are going to change it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 19:38:16 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 01 Apr 2012 17:38:16 +0000 Subject: [issue14469] Python 3 documentation links In-Reply-To: <1333298580.51.0.119482106967.issue14469@psf.upfronthosting.co.za> Message-ID: <1333301896.02.0.353681172217.issue14469@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think that it would be appropriate to start redirect (HTTP 302) http://docs.python.org/something/ to the http://docs.python.org/2.7/something/. Today, the situation is Vice versa. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 19:59:20 2012 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 01 Apr 2012 17:59:20 +0000 Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za> Message-ID: <1333303160.57.0.969360538213.issue14465@psf.upfronthosting.co.za> Eli Bendersky added the comment: Tshepang, Frankly, there are a lot of issues to solve in ElementTree (it hasn't been given love in a long time...) and such features would be low priority, as I'm not getting much help and am swamped already. As Martin said, patches can go a long way here... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 20:06:27 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 01 Apr 2012 18:06:27 +0000 Subject: [issue14470] Remove use of w9xopen in subporcess module Message-ID: <1333303587.03.0.401233973218.issue14470@psf.upfronthosting.co.za> New submission from Andrew Svetlov : As Python 3.3 declare: Windows 2000 and Windows platforms which set COMSPEC to command.com are no longer supported due to maintenance burden. We need to drop corresponding code from subprocess. ---------- keywords: easy messages: 157321 nosy: asvetlov priority: normal severity: normal status: open title: Remove use of w9xopen in subporcess module type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 20:10:06 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 01 Apr 2012 18:10:06 +0000 Subject: [issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za> Message-ID: <1333303806.97.0.904990879435.issue7839@psf.upfronthosting.co.za> Andrew Svetlov added the comment: BTW we need to drop win9x and win2000 support, see #14470 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 20:12:34 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 01 Apr 2012 18:12:34 +0000 Subject: [issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za> Message-ID: <1333303954.32.0.693608943928.issue7839@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I'm +1 for going though deprecation process for Popen args to make parameters combination clean and obvious. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 20:27:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 18:27:48 +0000 Subject: [issue14467] Avoid exotic documentation in the devguide In-Reply-To: <1333294504.16.0.644587677187.issue14467@psf.upfronthosting.co.za> Message-ID: <1333304868.02.0.878456649161.issue14467@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you for doing it :) ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 21:08:11 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 01 Apr 2012 19:08:11 +0000 Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za> Message-ID: <1333307291.16.0.179139673775.issue14465@psf.upfronthosting.co.za> Tshepang Lekhonkhobe added the comment: Okay, I will try, even though C scares me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 21:29:21 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 01 Apr 2012 19:29:21 +0000 Subject: [issue14470] Remove use of w9xopen in subporcess module In-Reply-To: <1333303587.03.0.401233973218.issue14470@psf.upfronthosting.co.za> Message-ID: <1333308561.93.0.91688171377.issue14470@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- components: +Library (Lib), Windows priority: normal -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 21:29:49 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 01 Apr 2012 19:29:49 +0000 Subject: [issue14470] Remove using of w9xopen in subporcess module In-Reply-To: <1333303587.03.0.401233973218.issue14470@psf.upfronthosting.co.za> Message-ID: <1333308589.04.0.67336007101.issue14470@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- title: Remove use of w9xopen in subporcess module -> Remove using of w9xopen in subporcess module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 21:57:01 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 01 Apr 2012 19:57:01 +0000 Subject: [issue14300] dup_socket() on Windows should use WSA_FLAG_OVERLAPPED In-Reply-To: <1331729986.5.0.388536898962.issue14300@psf.upfronthosting.co.za> Message-ID: <1333310221.26.0.45388646315.issue14300@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: I already included this fix in my "socket share" patch, see issue 14310. I think this was a bug that should be checked in to all relevant branches. The reason is this text from msdn documentation for WsaDuplicateSocket: " Both the source process and the destination process should pass the same flags to their respective WSASocket function calls. If the source process uses the socket function to create the socket, the destination process _must_ [underline KVJ] pass the WSA_FLAG_OVERLAPPED flag to its WSASocket function call." See http://msdn.microsoft.com/en-us/library/windows/desktop/ms741565(v=vs.85).aspx ---------- nosy: +krisvale _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 21:58:59 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 01 Apr 2012 19:58:59 +0000 Subject: [issue14466] Rip out mq instructions In-Reply-To: <1333294431.46.0.420841825384.issue14466@psf.upfronthosting.co.za> Message-ID: <1333310339.81.0.779942968089.issue14466@psf.upfronthosting.co.za> Ned Deily added the comment: No one uses it? I'm surprised. I do and it seems to me by far the easiest and safest way to maintain patches in progress when there is constant churn. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 22:03:04 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 01 Apr 2012 20:03:04 +0000 Subject: [issue14470] Remove using of w9xopen in subprocess module In-Reply-To: <1333303587.03.0.401233973218.issue14470@psf.upfronthosting.co.za> Message-ID: <1333310584.58.0.980352757407.issue14470@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +brian.curtin title: Remove using of w9xopen in subporcess module -> Remove using of w9xopen in subprocess module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 22:15:32 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 01 Apr 2012 20:15:32 +0000 Subject: [issue14300] dup_socket() on Windows should use WSA_FLAG_OVERLAPPED In-Reply-To: <1331729986.5.0.388536898962.issue14300@psf.upfronthosting.co.za> Message-ID: <1333311332.85.0.163024250456.issue14300@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Also, see this: http://support.microsoft.com/kb/179942/EN-US applies to windows 2000 only, as far as I can tell, though. Don't know if we still support that. I have scoured the docs, but found yet no reason to _not_ use this attribute. I wonder why it is optional at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 22:24:32 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 01 Apr 2012 20:24:32 +0000 Subject: [issue14471] Buffer oferrun in winreg.c Message-ID: <1333311872.78.0.659875130211.issue14471@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson : I found this issue with code analyzer in VS2010. The problem applies to all 3.x versions, but there is no corresponding winreg.c file in 2.x. Since I'm not sure of the maintenance state of the individual branches, I'm creating this defect hoping for guidance. Which branches should be fixed? ---------- components: Interpreter Core files: winreg.patch keywords: patch messages: 157329 nosy: krisvale priority: normal severity: normal status: open title: Buffer oferrun in winreg.c type: crash versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file25092/winreg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 22:24:41 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 01 Apr 2012 20:24:41 +0000 Subject: [issue14471] Buffer overrun in winreg.c In-Reply-To: <1333311872.78.0.659875130211.issue14471@psf.upfronthosting.co.za> Message-ID: <1333311881.09.0.576452063732.issue14471@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- title: Buffer oferrun in winreg.c -> Buffer overrun in winreg.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 22:58:10 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 01 Apr 2012 20:58:10 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1332785811.84.0.616508221107.issue14417@psf.upfronthosting.co.za> Message-ID: <1333313890.64.0.879232167517.issue14417@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Well, cheating is fair game when trying to test > borderline cases, isn't it? It is fair game (and necessary) when it comes to exposing bugs that are hard to reproduce. I'm wary of the original RuntimeError patch because * it modifies code that has been stable for over a decade * in order to "fix" a crasher that no one cares about * while possibly breaking code that currently works * and breaking it in a way that is hard to reproduce or diagnose. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 23:00:48 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 01 Apr 2012 21:00:48 +0000 Subject: [issue14394] Add speed improvement note to the decimal docs. In-Reply-To: <1332496271.62.0.623566153633.issue14394@psf.upfronthosting.co.za> Message-ID: <1333314048.59.0.37197571039.issue14394@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The correct place for the note is in the "optimizations" section of whatsnew. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 1 23:54:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 01 Apr 2012 21:54:50 +0000 Subject: [issue14471] Buffer overrun in winreg.c In-Reply-To: <1333311872.78.0.659875130211.issue14471@psf.upfronthosting.co.za> Message-ID: <1333317290.69.0.177647014802.issue14471@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 00:48:23 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 01 Apr 2012 22:48:23 +0000 Subject: [issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True In-Reply-To: <1333303954.32.0.693608943928.issue7839@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Everyone missed my other argument in favour of alternate constructor methods: fixing the currently wrong default arguments. There is no good reason to break working code when beginner confusion can be better addressed by telling them to avoid calling the Popen constructor directly in favour of newer APIs that have benefitted from years of experience with the current API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 01:01:13 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 01 Apr 2012 23:01:13 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1333313890.64.0.879232167517.issue14417@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: A thought prompted by Raymond's comment: did we ever try just protecting the retry as a recursive call? If we can stop the stack blowing up, it seems to me we'd get the best of both worlds (that is, crashes become RuntimeError, but naive multi-threaded code is unaffected). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 01:26:21 2012 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 01 Apr 2012 23:26:21 +0000 Subject: [issue14205] Raise an error if a dict is modified during a lookup In-Reply-To: <1330982395.54.0.88630927528.issue14205@psf.upfronthosting.co.za> Message-ID: <1333322781.23.0.894304382439.issue14205@psf.upfronthosting.co.za> Guido van Rossum added the comment: Was the crasher ever converted into a unittest? I think that should be done regardless of the outcome of the ongoing discussion about this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 01:44:30 2012 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 01 Apr 2012 23:44:30 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1333313890.64.0.879232167517.issue14417@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: On Sun, Apr 1, 2012 at 1:58 PM, Raymond Hettinger wrote: [...] > I'm wary of the original RuntimeError patch because [...] I had retorts to most of what you wrote, but decided not to post them. Instead, I really want to have a serious discussion about this issue, without falling back on "if it ain't broke don't fix it". There was definitely *something* wrong with the original code: there was a known crasher and it had XXX comments in it, and some folks cared enough to attempt to fix it. In the end I see this more as a matter of clarifying the semantics and limitations of dict operations: *should* the language guarantee that the built-in dict implementation supports correct lookup even if the in the middle of the lookup the hash table is resized by another thread? Is this a reasonable guarantee to impose on all Python implementations? Because I don't see how this can be guaranteed without a lock; but I haven't tried very hard, so this is not a rhetorical question. - - - On Sun, Apr 1, 2012 at 4:01 PM, Nick Coghlan wrote: > A thought prompted by Raymond's comment: did we ever try just protecting > the retry as a recursive call? If we can stop the stack blowing up, it > seems to me we'd get the best of both worlds (that is, crashes become > RuntimeError, but naive multi-threaded code is unaffected). Hm... We considered a variety of fixes in http://bugs.python.org/issue14205 but I don't think we tried that. (The nastiness is that it's strictly a C-level recursion -- lookdict() calls lookdict().) Another thing we didn't try was manually eliminating the tail recursion in lookdict() using a goto (and perhaps some variable assignments). I don't see the potential for an infinite loop as a problem, since one could be created just as easily by putting "while True: pass" inside a user-defined __hash__(). PS. I'm not surprised your originall hammer_dict.py didn't provoke the problem -- it only overrides __hash__(), but lookdict() never calls that. It only calls the compare function; the hash is computed once and passed into it. Finally, the guard in lookdict() looks fishy to me: if (ep0 == mp->ma_table && ep->me_key == startkey) { Can't this evaluate to true when the dict has shrunk dramatically in size? I think an extra test for "mask == mp->ma_mask" ought to be added. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 01:47:55 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 01 Apr 2012 23:47:55 +0000 Subject: [issue14471] Buffer overrun in winreg.c In-Reply-To: <1333311872.78.0.659875130211.issue14471@psf.upfronthosting.co.za> Message-ID: <1333324075.2.0.711363733129.issue14471@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The patch looks fine. As it's not a security fix, it should go into 3.2 and default. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 01:48:09 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 01 Apr 2012 23:48:09 +0000 Subject: [issue14471] Buffer overrun in winreg.c In-Reply-To: <1333311872.78.0.659875130211.issue14471@psf.upfronthosting.co.za> Message-ID: <1333324089.65.0.149752683171.issue14471@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 01:51:28 2012 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 01 Apr 2012 23:51:28 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1332785811.84.0.616508221107.issue14417@psf.upfronthosting.co.za> Message-ID: <1333324288.21.0.845847141933.issue14417@psf.upfronthosting.co.za> Guido van Rossum added the comment: Here's a hack that uses goto instead of recursion to restore the original behavior, less the stack overflow. With this, hammer_dict_switchinterval.py loops forever (which is I think what it's supposed to do if RuntimeError is never raised). ---------- keywords: +patch Added file: http://bugs.python.org/file25093/dictobject.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 01:56:55 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 01 Apr 2012 23:56:55 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1332785811.84.0.616508221107.issue14417@psf.upfronthosting.co.za> Message-ID: <1333324615.1.0.900014822231.issue14417@psf.upfronthosting.co.za> Raymond Hettinger added the comment: IIRC, Jython uses concurrent mappings, so this isn't an issue for them. CPython's dictresize() relies on the GIL to atomically resize the ma_table. There are no pure python calls (the existing hash values are reused) and the ref counts are neutral. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 01:58:29 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 01 Apr 2012 23:58:29 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1332785811.84.0.616508221107.issue14417@psf.upfronthosting.co.za> Message-ID: <1333324709.4.0.936854691303.issue14417@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg157338 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 02:16:30 2012 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 02 Apr 2012 00:16:30 +0000 Subject: [issue14450] Log rotate cant execute in Windows. (logging module) In-Reply-To: <1333089873.7.0.17857342525.issue14450@psf.upfronthosting.co.za> Message-ID: <1333325790.64.0.792849593461.issue14450@psf.upfronthosting.co.za> Vinay Sajip added the comment: This is not a logging bug. You called basicConfig with a file name, so the file is opened using a FileHandler and with file name LOG_FILENAME. You then add a RotatingFileHandler with the same name, so the file has two handles referring to it. When the time comes to rotate, the file is still open (with the FileHandler), which is why the rename fails on Windows (though Linux allows it). Closing as invalid. ---------- nosy: +vinay.sajip resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 03:02:38 2012 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 02 Apr 2012 01:02:38 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1333324709.51.0.398295077826.issue14417@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Why delete that? On Sunday, April 1, 2012, Raymond Hettinger wrote: > > Changes by Raymond Hettinger >: > > > ---------- > Removed message: http://bugs.python.org/msg157338 > > _______________________________________ > Python tracker > > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 04:10:12 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 02 Apr 2012 02:10:12 +0000 Subject: [issue14466] Rip out mq instructions In-Reply-To: <1333294431.46.0.420841825384.issue14466@psf.upfronthosting.co.za> Message-ID: <1333332612.9.0.66624027114.issue14466@psf.upfronthosting.co.za> Ezio Melotti added the comment: +1 Most of the time "hg diff > issue12345.diff" is all that it's needed to produce a patch, and whenever I point someone to the devguide they usually get confused because they think they have to use mq. FWIW I mostly use uncommitted changes, possibly on more clones, and since I usually upload the patch to the tracker I don't risk losing it in case I do something wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 04:11:48 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 02 Apr 2012 02:11:48 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1333332708.08.0.801137840126.issue14468@psf.upfronthosting.co.za> Ezio Melotti added the comment: +1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 09:20:16 2012 From: report at bugs.python.org (Matt Joiner) Date: Mon, 02 Apr 2012 07:20:16 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1333351216.11.0.988829384465.issue14373@psf.upfronthosting.co.za> Matt Joiner added the comment: > * it incorporate the recent lru_cache algorithmic updates (moving the root around the circular queue to re-use old links). The existing C patch already does this. > * it shows which parts should be implemented in C using a regular type and shows how to call it from pure python. The existing patch already did this. > * it gives hints on use of #defines and PyDict_GetItem I'm familiar with C. I've retained PyDict_GetItemWithError so as not to suppress typing errors from keys constructed from bad arguments from the user. > * the critical sections are marked so you can use the GIL rather than using locks. The existing patch is already using the GIL, it didn't have any locks. > * there are hints for what datatypes to use (only the hits and misses need the ability to grow beyond sys.maxsize). The existing patch already had this. > * it shows how to access the named tuple from within the C code (using a straight PyObject_Call). I incorporated this. > * this code passes the test suite and should be directly translatable (and very fast). So did the old code. > * please follow the model and use PyList objects instead of C structure for links I've left this as is, the linked list in C is idiomatic, avoids a lot of branching and reference counting and is also more readable than the equivalent C/Python. ---------- Added file: http://bugs.python.org/file25094/functools.lru_cache-in-c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 09:20:31 2012 From: report at bugs.python.org (Matt Joiner) Date: Mon, 02 Apr 2012 07:20:31 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1333351231.97.0.62166533336.issue14373@psf.upfronthosting.co.za> Changes by Matt Joiner : Removed file: http://bugs.python.org/file25026/functools.lru_cache-in-c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 09:20:41 2012 From: report at bugs.python.org (Matt Joiner) Date: Mon, 02 Apr 2012 07:20:41 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1333351241.29.0.89375420482.issue14373@psf.upfronthosting.co.za> Changes by Matt Joiner : Removed file: http://bugs.python.org/file24984/functools.lru_cache-in-c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 10:57:56 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 02 Apr 2012 08:57:56 +0000 Subject: [issue14471] Buffer overrun in winreg.c In-Reply-To: <1333311872.78.0.659875130211.issue14471@psf.upfronthosting.co.za> Message-ID: <1333357076.95.0.0517093781375.issue14471@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: In 2.7, the file is named _winreg.c. But the patch does not apply there, because it's using the ANSI (=bytes) API. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 11:16:08 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 02 Apr 2012 09:16:08 +0000 Subject: [issue14471] Buffer overrun in winreg.c In-Reply-To: <1333311872.78.0.659875130211.issue14471@psf.upfronthosting.co.za> Message-ID: <1333358168.45.0.819698852204.issue14471@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Thanks. Martin, what constitutes a security fix for Python? For example, isn't it conceivable that one could place a long key into some registry setting used by python and thus interfere with its stack? Aren't stack buffer overruns a classic security hole? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 12:20:42 2012 From: report at bugs.python.org (Matej Cepl) Date: Mon, 02 Apr 2012 10:20:42 +0000 Subject: [issue14472] .gitignore is outdated Message-ID: <1333362042.78.0.183970961684.issue14472@psf.upfronthosting.co.za> New submission from Matej Cepl : Patch for the port of .hgignore to .gitignore is attached ---------- components: Build files: _gitignore.patch keywords: patch messages: 157346 nosy: mcepl priority: normal severity: normal status: open title: .gitignore is outdated Added file: http://bugs.python.org/file25095/_gitignore.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 12:52:13 2012 From: report at bugs.python.org (Thomas Spura) Date: Mon, 02 Apr 2012 10:52:13 +0000 Subject: [issue14472] .gitignore is outdated In-Reply-To: <1333362042.78.0.183970961684.issue14472@psf.upfronthosting.co.za> Message-ID: <1333363933.46.0.312535030546.issue14472@psf.upfronthosting.co.za> Thomas Spura added the comment: AFAIK hg supports symlinks. Why not just symlink .gitignore to .hgignore and keep .hgignore up to date? But in this case "$" and "^" need to be avoided, e.g. this doesn't work for git: Makefile$ Makefile.pre$ ---------- nosy: +tomspur _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 13:16:50 2012 From: report at bugs.python.org (Mark Shannon) Date: Mon, 02 Apr 2012 11:16:50 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1333365410.23.0.617880253493.issue13903@psf.upfronthosting.co.za> Changes by Mark Shannon : Added file: http://bugs.python.org/file25096/372d0bca85ae.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 13:51:32 2012 From: report at bugs.python.org (Federico Reghenzani) Date: Mon, 02 Apr 2012 11:51:32 +0000 Subject: [issue14473] Regex Howto error Message-ID: <1333367492.14.0.400451963757.issue14473@psf.upfronthosting.co.za> New submission from Federico Reghenzani : There's an error in Regex Howto, when explain the operator '?', I attached the patch. ---------- assignee: docs at python components: Documentation files: regex_doc.diff keywords: patch messages: 157348 nosy: docs at python, federico.reghenzani priority: normal severity: normal status: open title: Regex Howto error versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25097/regex_doc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 13:58:00 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 02 Apr 2012 11:58:00 +0000 Subject: [issue14473] Regex Howto error In-Reply-To: <1333367492.14.0.400451963757.issue14473@psf.upfronthosting.co.za> Message-ID: <1333367880.74.0.963586940124.issue14473@psf.upfronthosting.co.za> Senthil Kumaran added the comment: That's not an error, but in fact a correct statement. Please test it in the interpreter. ---------- nosy: +orsenthil resolution: -> invalid stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 14:08:20 2012 From: report at bugs.python.org (Pierre Ossman) Date: Mon, 02 Apr 2012 12:08:20 +0000 Subject: [issue14474] mishandling of AttributeError in threads Message-ID: <1333368500.29.0.652267156106.issue14474@psf.upfronthosting.co.za> New submission from Pierre Ossman : These three things do not mix: - AttributeError - Threads - Object methods An unhandled AttributeError thrown in a thread will not call sys.excepthook if the thread's start function is a class/object method. Test case: import sys import thread class Dummy: def worker(self): raise AttributeError thread.start_new_thread(Dummy().worker, ()) sys.stdin.readline() Note that you do not get a traceback here. Throwing any other exception type works fine, as does having worker() be a simple function. I think I've traced the issue to Objects/classobject.c:instance_repr(). It tries to look up the method, making sure to handle any AttributeError this might cause. But it fails to save and restore and Exception currently already active, effectively clearing out the current exception. ---------- components: Interpreter Core messages: 157350 nosy: ossman priority: normal severity: normal status: open title: mishandling of AttributeError in threads versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 14:16:59 2012 From: report at bugs.python.org (Jeff Robbins) Date: Mon, 02 Apr 2012 12:16:59 +0000 Subject: [issue14387] Include\accu.h incompatible with Windows.h In-Reply-To: <1333280888.87.0.587275702453.issue14387@psf.upfronthosting.co.za> Message-ID: <060AD9574BAB473F820DD3F4AEEDDAE7@FamilyPC> Jeff Robbins added the comment: I'm happy to try another build of apsw, but am not up-to-speed with how to get development copies of Python. As a user, I typically download the latest Windows .msi file and install it. If you can point me to a document on how to proceed, I'll give it a try. I'm Bcc'ing the APSW author in the event he can give it a try. ----- Original Message ----- From: "Stefan Krah" To: Sent: Sunday, April 01, 2012 7:48 AM Subject: [issue14387] Include\accu.h incompatible with Windows.h Stefan Krah added the comment: > Should I contact the extension's author(s)/maintainer(s) and tell them > about this ordering requirement? FWIW, it is the recommended way in the docs. The Python build itself has been fixed. Does the http://code.google.com/p/apsw/ module build now? ---------- _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 14:17:44 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 02 Apr 2012 12:17:44 +0000 Subject: [issue14471] Buffer overrun in winreg.c In-Reply-To: <1333358168.45.0.819698852204.issue14471@psf.upfronthosting.co.za> Message-ID: <20120402141742.Horde.EykberuWis5PeZjmmsLUFiA@webmail.df.eu> Martin v. L?wis added the comment: > Martin, what constitutes a security fix for Python? For example, > isn't it conceivable that one could place a long key into some > registry setting used by python and thus interfere with its stack? If it has a CVE identifier, it's a security fix. Otherwise, I'd apply standard risk assessment procedures, and ask the release manager for judgement. > Aren't stack buffer overruns a classic security hole? My personal risk assessment of this issue is that it has a fairly low risk, as the likelihood of an attack is low. Just placing a key in the registry is not sufficient as an attack: one would also need a different user who has a Python application that enumerates this part of the registry. In that scenario, the user would have to be unprivileged (*), i.e. would not have write permissions to either HKLM nor HKCR. Writing to HKCU does not constitute a threat, since it would only allow to crash your own Python applications. There may be opportunities where an administrator has a script that traverses HKEY_USERS while a different user is logged on. Given that the threat of being discovered is very high for the attacker, and given that the typical Windows installation does not use concurrent logins, and given that traversing HKEY_USERS is uncommon, I think the risk of this threat is really low. (*) an administrator user could just as well replace the Python DLL, causing a threat regardless of the winreg module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 14:30:49 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 02 Apr 2012 12:30:49 +0000 Subject: [issue14471] Buffer overrun in winreg.c In-Reply-To: <1333311872.78.0.659875130211.issue14471@psf.upfronthosting.co.za> Message-ID: <1333369849.96.0.125285570085.issue14471@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Thanks for the your info/insight, Martin. I'll update 3.2 and 3.3. as you suggest then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 14:34:40 2012 From: report at bugs.python.org (Matej Cepl) Date: Mon, 02 Apr 2012 12:34:40 +0000 Subject: [issue14472] .gitignore is outdated In-Reply-To: <1333362042.78.0.183970961684.issue14472@psf.upfronthosting.co.za> Message-ID: <1333370080.05.0.821073620795.issue14472@psf.upfronthosting.co.za> Matej Cepl added the comment: Right ... .gitignore doesn't support regexeps (they are not needed IMHO here, but that's another point). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 14:35:07 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 02 Apr 2012 12:35:07 +0000 Subject: [issue14405] Some "Other Resources" in the sidebar are hopelessly out of date In-Reply-To: <1332696210.48.0.175266420412.issue14405@psf.upfronthosting.co.za> Message-ID: <1333370107.61.0.957867305143.issue14405@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 15:13:34 2012 From: report at bugs.python.org (Mikko Rasa) Date: Mon, 02 Apr 2012 13:13:34 +0000 Subject: [issue14475] codecs.StreamReader.read behaves differently from regular files Message-ID: <1333372414.16.0.496350307965.issue14475@psf.upfronthosting.co.za> New submission from Mikko Rasa : For regular files, a read() call without arguments will read until EOF. codecs.StreamReader does its own buffering, and if there are characters in the buffer, a read() call will be satisfied from the buffer without an attempt to read the rest of the file. This discrepancy causes certain code that worked with regular open() fail if codecs.open() is substituted. The easiest way to reproduce this is to first call readline() and then read(). Since readline() can't know how many characters are on the line, it will almost always leave some characters in the buffer, triggering the problem with read(). ---------- messages: 157355 nosy: tdb priority: normal severity: normal status: open title: codecs.StreamReader.read behaves differently from regular files type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 15:31:20 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 02 Apr 2012 13:31:20 +0000 Subject: [issue14387] Include\accu.h incompatible with Windows.h In-Reply-To: <060AD9574BAB473F820DD3F4AEEDDAE7@FamilyPC> Message-ID: <20120402133119.GA29915@sleipnir.bytereef.org> Stefan Krah added the comment: Jeff Robbins wrote: > I'm happy to try another build of apsw, but am not up-to-speed with how to > get development copies of Python. As a user, I typically download the > latest Windows .msi file and install it. If you can point me to a document > on how to proceed, I'll give it a try. http://www.python.org/ftp/python/3.3.0/python-3.3a2.msi should have the fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 16:36:31 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 02 Apr 2012 14:36:31 +0000 Subject: [issue14474] mishandling of AttributeError in threads In-Reply-To: <1333368500.29.0.652267156106.issue14474@psf.upfronthosting.co.za> Message-ID: <1333377391.87.0.55520195059.issue14474@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: If Dummy is a new-style class, the traceback is correctly printed. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 16:57:06 2012 From: report at bugs.python.org (Pierre Ossman) Date: Mon, 02 Apr 2012 14:57:06 +0000 Subject: [issue14476] sudo breaks python Message-ID: <1333378626.33.0.624726791004.issue14476@psf.upfronthosting.co.za> New submission from Pierre Ossman : sudo breaks exception handling in Python in some subtle way. The following test program works fine when run directly, but breaks when run through sudo: #!/usr/bin/python import time def a(): try: while True: time.sleep(0.001) except KeyboardInterrupt: print "a" def b(): try: a() except KeyboardInterrupt: print "b" b() This is expected: pierre at pangolin:~$ ./test.py ^Ca But through sudo you get random behaviour: pierre at pangolin:~$ sudo ./test.py ^Ca b pierre at pangolin:~$ sudo ./test.py ^Ca b pierre at pangolin:~$ sudo ./test.py ^Ca b pierre at pangolin:~$ sudo ./test.py ^Ca pierre at pangolin:~$ sudo ./test.py ^Ca pierre at pangolin:~$ sudo ./test.py ^Cb Seen on Ubuntu 12.04 (alpha/beta) and on Fedora 16. Happens more often on Ubuntu though. ---------- components: Interpreter Core messages: 157358 nosy: ossman priority: normal severity: normal status: open title: sudo breaks python versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 16:58:51 2012 From: report at bugs.python.org (Pierre Ossman) Date: Mon, 02 Apr 2012 14:58:51 +0000 Subject: [issue14474] mishandling of AttributeError in threads In-Reply-To: <1333368500.29.0.652267156106.issue14474@psf.upfronthosting.co.za> Message-ID: <1333378731.93.0.594943585737.issue14474@psf.upfronthosting.co.za> Pierre Ossman added the comment: Indeed. I assume old style classes are still supported though? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 16:59:54 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 02 Apr 2012 14:59:54 +0000 Subject: [issue14476] sudo breaks python In-Reply-To: <1333378626.33.0.624726791004.issue14476@psf.upfronthosting.co.za> Message-ID: <1333378794.46.0.700498868347.issue14476@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 17:02:38 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 02 Apr 2012 15:02:38 +0000 Subject: [issue14476] sudo breaks python In-Reply-To: <1333378626.33.0.624726791004.issue14476@psf.upfronthosting.co.za> Message-ID: <1333378958.77.0.0901620096655.issue14476@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: It's probably not related to Python; see http://comments.gmane.org/gmane.comp.tools.sudo.user/3769 This threads ends with: """ Great. That change will be in the next sudo release. """ ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 17:10:34 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Apr 2012 15:10:34 +0000 Subject: [issue14476] sudo breaks python In-Reply-To: <1333378626.33.0.624726791004.issue14476@psf.upfronthosting.co.za> Message-ID: <1333379434.44.0.628636947198.issue14476@psf.upfronthosting.co.za> R. David Murray added the comment: See also http://www.gratisoft.us/bugzilla/show_bug.cgi?id=464, which lists versions. Sounds like the same bug Amaury linked to. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 17:11:49 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Apr 2012 15:11:49 +0000 Subject: [issue14476] sudo breaks python In-Reply-To: <1333378626.33.0.624726791004.issue14476@psf.upfronthosting.co.za> Message-ID: <1333379509.77.0.336892548664.issue14476@psf.upfronthosting.co.za> R. David Murray added the comment: I'm going to close this. If it turns out not to be a bug in sudo, please reopen. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 17:15:25 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 02 Apr 2012 15:15:25 +0000 Subject: [issue14474] mishandling of AttributeError in threads In-Reply-To: <1333368500.29.0.652267156106.issue14474@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 8609d7fcdcc7 by Benjamin Peterson in branch '2.7': prevent writing to stderr from messing up the exception state (closes #14474) http://hg.python.org/cpython/rev/8609d7fcdcc7 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 17:15:40 2012 From: report at bugs.python.org (Pierre Ossman) Date: Mon, 02 Apr 2012 15:15:40 +0000 Subject: [issue14476] sudo breaks python In-Reply-To: <1333378626.33.0.624726791004.issue14476@psf.upfronthosting.co.za> Message-ID: <1333379740.34.0.769513501487.issue14476@psf.upfronthosting.co.za> Pierre Ossman added the comment: Well that was fast. :) Sounds very much like the same bug I'm seeing here, yes. Unfortunately I'm not sure it's sufficient for us to rely on the distributions to update their sudo packages. A workaround would be preferable. I'll see if I can figure something out. Many thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 17:21:13 2012 From: report at bugs.python.org (Mark Shannon) Date: Mon, 02 Apr 2012 15:21:13 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1333380073.05.0.0268479977575.issue13903@psf.upfronthosting.co.za> Mark Shannon added the comment: I'm not bothered by the regression in "silent_logging", as it is a micro benchmark with a very short running time. The regression in "mako" is, I think, caused by competition for the data cache between the new dict implementation and the method-cache used by _PyType_Lookup. Although the new-dict uses less memory overall, the size of a single split-table dict (keys + value) is larger than a combined table. Reducing the method-cache size from 2**10 to 2**9 allows the working set to fit better in the cache. This fixes the regression in "mako", but makes OO programs that use few objects (such as richards) a bit slower. Compared with tip, the new-dict implementation is 4% slower, using 7% less memory for mako. 6% slower, using 5% less memory for richards. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 17:28:56 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 02 Apr 2012 15:28:56 +0000 Subject: [issue14474] mishandling of AttributeError in threads In-Reply-To: <1333368500.29.0.652267156106.issue14474@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 60ad83716733 by Benjamin Peterson in branch '3.2': prevent writing to stderr from messing up the exception state (closes #14474) http://hg.python.org/cpython/rev/60ad83716733 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 17:37:22 2012 From: report at bugs.python.org (Georges Martin) Date: Mon, 02 Apr 2012 15:37:22 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za> Message-ID: <1333381042.95.0.505196833718.issue14455@psf.upfronthosting.co.za> Changes by Georges Martin : ---------- nosy: +jrjsmrtn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 17:41:35 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 02 Apr 2012 15:41:35 +0000 Subject: [issue14471] Buffer overrun in winreg.c In-Reply-To: <1333311872.78.0.659875130211.issue14471@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b3639f6aaa2b by Kristj?n Valur J?nsson in branch '3.2': Issue #14471: Fix a possible buffer overrun in the winreg module. http://hg.python.org/cpython/rev/b3639f6aaa2b New changeset 80d814d7b886 by Kristj?n Valur J?nsson in branch 'default': Merge with 3.2 (Issue #14471) http://hg.python.org/cpython/rev/80d814d7b886 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 17:43:02 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 02 Apr 2012 15:43:02 +0000 Subject: [issue14471] Buffer overrun in winreg.c In-Reply-To: <1333311872.78.0.659875130211.issue14471@psf.upfronthosting.co.za> Message-ID: <1333381382.57.0.984237447902.issue14471@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 18:04:49 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 02 Apr 2012 16:04:49 +0000 Subject: [issue14477] Rietveld test issue Message-ID: <1333382689.52.0.891466185612.issue14477@psf.upfronthosting.co.za> New submission from Martin v. L?wis : This is to test issues with the Rietveld integration. ---------- messages: 157368 nosy: dmalcolm, loewis priority: normal severity: normal status: open title: Rietveld test issue _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 18:06:37 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 02 Apr 2012 16:06:37 +0000 Subject: [issue14477] Rietveld test issue In-Reply-To: <1333382689.52.0.891466185612.issue14477@psf.upfronthosting.co.za> Message-ID: <1333382797.68.0.0286045554475.issue14477@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- keywords: +patch Added file: http://bugs.python.org/file25098/readme.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 19:16:26 2012 From: report at bugs.python.org (James Hutchison) Date: Mon, 02 Apr 2012 17:16:26 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached Message-ID: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> New submission from James Hutchison : Tested on 3.2 Note that I noticed that Decimal is supposed to be faster in 3.3 but I thought I would bring this to light just in case its still relevant Decimal hashing is very slow, even for simple numbers. I found by caching the hash result, there is significant speed up whenever a Decimal value is reused. I created a class that inherits from Decimal and changed the __hash__ function to try/except a stored hash value as such: def __hash__(self): try: return self.myHash; except: self.myHash = super().__hash__(); return self.myHash; Example code: d = dict(); start = time.time(); i = int(1); j = int(2); k = int(3); for i in range(100000): d[i,j,k] = 5; print(time.time() - start); d = dict(); start = time.time(); i = Decimal(1); j = Decimal(2); k = Decimal(3); for i in range(100000): d[i,j,k] = 5; print(time.time() - start); d = dict(); start = time.time(); i = CachingDecimal(1); j = CachingDecimal(2); k = CachingDecimal(3); for i in range(100000): d[i,j,k] = 5; print(time.time() - start); Output int: 0.04699993133544922 Decimal: 2.312999963760376 CachingDecimal: 0.1100001335144043 In a real life example, I changed some of the values in my code from int to Decimal because non-whole numbers needed to be supported (and this seemed like the easiest way to do so without having to worry about my == comparisons breaking) and it slowed my code down massively. Changing to a CachingDecimal type sped up one code block from 92 seconds with Decimal to 7 seconds, which was much closer to the original int speed. Note that all of the relevant operations have to be overloaded to return the CachingDecimal type, which is a pain, so this makes a lot of sense to implement into the Decimal module. My understanding is that altering a Decimal value will always create a new Decimal object, so there shouldn't be any issues with the cached hash desyncing with the correct hash. Someone may want to check that though. Thanks, James ---------- components: Library (Lib) messages: 157369 nosy: Jimbofbx priority: normal severity: normal status: open title: Decimal hashing very slow, could be cached type: performance versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 19:22:00 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Apr 2012 17:22:00 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1333387320.8.0.269144079031.issue14478@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 19:23:49 2012 From: report at bugs.python.org (Jeff Robbins) Date: Mon, 02 Apr 2012 17:23:49 +0000 Subject: [issue14387] Include\accu.h incompatible with Windows.h In-Reply-To: <1332417184.03.0.15615521555.issue14387@psf.upfronthosting.co.za> Message-ID: <02AEAE825B884719AD4C4B21B083A5D6@corporate.cambridge.livedata.com> Jeff Robbins added the comment: Thanks for the pointer to the .msi. The fix solved my apsw build problem. I installed Python 3.3.a2 and apsw-3.7.11-r1. I ran this build: C:\Temp\apsw-3.7.11-r1>c:\Python33\python setup.py fetch --all build --enable-all-extensions install apsw built and installed fine. And my test app runs. This line in accu.h did the trick: #undef small /* defined by some Windows headers */ One of the apsw tests failed, but I don't think it had to do with the accu.h build problem. Could be something I did wrong, or some issue between APSW and Python 3.3? - Jeff ====================================================================== FAIL: testShell (tests.APSW) Check Shell functionality ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Temp\apsw-3.7.11-r1\tests.py", line 6703, in testShell self.assertEqual(data, newdata) AssertionError: Lists differ: [(3.1, 'xabc'), (3.2, 'xabfff"... != [(3.1, ''), ( 3.2, '')] First differing element 0: (3.1, 'xabc') (3.1, '') - [(3.1, 'xabc'), (3.2, 'xabfff"ffffc')] + [(3.1, ''), (3.2, '')] ---------------------------------------------------------------------- Ran 78 tests in 787.594s FAILED (failures=1) ----- Original Message ----- From: "Stefan Krah" To: Sent: Monday, April 02, 2012 09:31 Subject: [issue14387] Include\accu.h incompatible with Windows.h Stefan Krah added the comment: Jeff Robbins wrote: > I'm happy to try another build of apsw, but am not up-to-speed with how to > get development copies of Python. As a user, I typically download the > latest Windows .msi file and install it. If you can point me to a > document > on how to proceed, I'll give it a try. http://www.python.org/ftp/python/3.3.0/python-3.3a2.msi should have the fix. ---------- _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 19:26:38 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 02 Apr 2012 17:26:38 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1333387598.87.0.923296380711.issue14478@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 19:57:33 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 02 Apr 2012 17:57:33 +0000 Subject: [issue14472] .gitignore is outdated In-Reply-To: <1333362042.78.0.183970961684.issue14472@psf.upfronthosting.co.za> Message-ID: <1333389453.83.0.776912227766.issue14472@psf.upfronthosting.co.za> Georg Brandl added the comment: Symlinks don't work well on Windows. I think a comment in .hgignore asking to update the other two ignores as well is the best solution. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 20:16:05 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 02 Apr 2012 18:16:05 +0000 Subject: [issue14387] Include\accu.h incompatible with Windows.h In-Reply-To: <1332417184.03.0.15615521555.issue14387@psf.upfronthosting.co.za> Message-ID: <1333390565.59.0.17451568206.issue14387@psf.upfronthosting.co.za> Stefan Krah added the comment: > The fix solved my apsw build problem. Thanks for testing. As for the test failure, that could be really anything. Often these kinds of failures turn out to be overly strict assumptions in the test suite. Best ask the maintainer of the package. So 3.3 is covered. The fix isn't yet in 3.2.3rc2, but I guess aff7ff2aae8c will go automatically into the final release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 20:28:42 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 02 Apr 2012 18:28:42 +0000 Subject: [issue14387] Include\accu.h incompatible with Windows.h In-Reply-To: <1332417184.03.0.15615521555.issue14387@psf.upfronthosting.co.za> Message-ID: <1333391322.79.0.241085723921.issue14387@psf.upfronthosting.co.za> Georg Brandl added the comment: No it won't: but it's harmless enough that I think it can go into the final without creating another rc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 20:29:25 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 02 Apr 2012 18:29:25 +0000 Subject: [issue14387] Include\accu.h incompatible with Windows.h In-Reply-To: <1332417184.03.0.15615521555.issue14387@psf.upfronthosting.co.za> Message-ID: <1333391365.55.0.193852213011.issue14387@psf.upfronthosting.co.za> Georg Brandl added the comment: Transplanted to f91ecbc8bafc in 3.2.3 release clone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 21:18:45 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 02 Apr 2012 19:18:45 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1333394325.01.0.203184394671.issue14478@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It would be better if you provide a working script that demonstrates the issue. I have completed your example (attached). I ran the example on Python 3.1 and received: 0.249999046326 9.8737308979 0.587980985641 Then I ran on Python 3.3: 0.2100839614868164 0.8649246692657471 0.6062228679656982 As you can see, the new implementation is much faster. Benefit from caching decreased. I suppose, if we implement caching in C the difference will be more. Then I increased the size of the cycles in 10 times, and the time is almost equal (on Python 3): 1.8386573791503906 8.418540477752686 8.355770826339722 That I can't to explain. The time of cached version increased disproportionately, more than in 10 times. ---------- nosy: +storchaka Added file: http://bugs.python.org/file25099/CachingDecimal_example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 21:36:24 2012 From: report at bugs.python.org (James Hutchison) Date: Mon, 02 Apr 2012 19:36:24 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1333395384.26.0.71699867406.issue14478@psf.upfronthosting.co.za> James Hutchison added the comment: If I increase the cycles increased 10x with 3.2 I get: int: 0.4219999313354492 Decimal: 24.20299983024597 CachingDecimal: 1.7809998989105225 The sample you have provided is basically what I'm using. See attached What about worst case hash calculation time for Decimal? How does the C code handle that? This is if I increase the values themselves by 100x, same number of loops as above int: 0.5309998989105225 CachingDecimal: 2.078000068664551 Decimal: 41.2979998588562 ---------- Added file: http://bugs.python.org/file25100/cachedDecimal.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 21:38:20 2012 From: report at bugs.python.org (James Hutchison) Date: Mon, 02 Apr 2012 19:38:20 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1333395500.56.0.398679756054.issue14478@psf.upfronthosting.co.za> James Hutchison added the comment: 100x should be e100 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 21:50:08 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 02 Apr 2012 19:50:08 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1333396208.72.0.617651688468.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: Updated patch: - Implement time.get_clock_info() - time.monotonic() never fails: fallback to time.time() if needed TODO: time.monotonic() must use GetTickCount64() or GetTickCount() on Windows, with a detection of integer overflow on GetTickCount(). ---------- Added file: http://bugs.python.org/file25101/pep418-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 21:51:19 2012 From: report at bugs.python.org (Adam Tomjack) Date: Mon, 02 Apr 2012 19:51:19 +0000 Subject: [issue14432] Bug in generator if the generator in created in a C thread In-Reply-To: <1332948868.24.0.309034348776.issue14432@psf.upfronthosting.co.za> Message-ID: <1333396279.74.0.479270743636.issue14432@psf.upfronthosting.co.za> Adam Tomjack added the comment: For what it's worth, I think I've seen this bug in 2.6 and 2.5, using generators created in python threads, while profiling not tracing. I'm creating generators in one python thread and storing them in a variable. In a different python thread I overwrite the variable, which garbage collects the generator. Sometimes it causes an interpreter crash. Other times, it seems to trigger a return event in the profiler, but it's associated with an incorrect thread. The thread in question is often (always?) in the profiler code, so it looks like the profiler is profiling itself. ---------- nosy: +adamtj versions: +Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 22:03:59 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 02 Apr 2012 20:03:59 +0000 Subject: [issue14475] codecs.StreamReader.read behaves differently from regular files In-Reply-To: <1333372414.16.0.496350307965.issue14475@psf.upfronthosting.co.za> Message-ID: <1333397039.31.0.960245648912.issue14475@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, yet another bug in in codecs.StreamReader. I should add it to the PEP :-) http://www.python.org/dev/peps/pep-0400/ Use io.TextIOWrapper (open) instead of codecs.StreamReader (codecs.open), it's bugfree :-) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 22:17:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 02 Apr 2012 20:17:02 +0000 Subject: [issue14477] Rietveld test issue In-Reply-To: <1333382689.52.0.891466185612.issue14477@psf.upfronthosting.co.za> Message-ID: <1333397822.05.0.558334977069.issue14477@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 22:18:12 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 02 Apr 2012 20:18:12 +0000 Subject: [issue14466] Rip out mq instructions In-Reply-To: <1333294431.46.0.420841825384.issue14466@psf.upfronthosting.co.za> Message-ID: <1333397892.85.0.724018169192.issue14466@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > No one uses it? I'm surprised. I do and it seems to me by far the > easiest and safest way to maintain patches in progress when there is > constant churn. Ah, good to know :) My wording was a bit too strong then. However, I rarely see mq-produced patches when processing patches from contributors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 22:25:28 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Apr 2012 20:25:28 +0000 Subject: [issue14466] Rip out mq instructions In-Reply-To: <1333294431.46.0.420841825384.issue14466@psf.upfronthosting.co.za> Message-ID: <1333398328.88.0.146461149868.issue14466@psf.upfronthosting.co.za> R. David Murray added the comment: One person that I helped at the PyCon sprints was using it, because the devguide said to. But I think she was more confused by it than she would have been by 'hg diff', at least to start out. Or maybe not...but I wasn't able to help her with the mq commands, because I don't use mq myself. I should try it sometime, I suppose. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 22:28:15 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 02 Apr 2012 20:28:15 +0000 Subject: [issue14466] Rip out mq instructions In-Reply-To: <1333398328.88.0.146461149868.issue14466@psf.upfronthosting.co.za> Message-ID: <1333398186.3428.7.camel@localhost.localdomain> Antoine Pitrou added the comment: > One person that I helped at the PyCon sprints was using it, because > the devguide said to. But I think she was more confused by it than > she would have been by 'hg diff', at least to start out. Or maybe > not...but I wasn't able to help her with the mq commands, because I > don't use mq myself. mq is "advanced" compared to other workflows. It's a rather powerful and sophisticated tool. I think people familiar with hg will have no problem using mq even if we don't mention it. hg beginners, on the other hand, will be more comfortable with something simpler. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 22:32:37 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 02 Apr 2012 20:32:37 +0000 Subject: [issue14466] Rip out mq instructions In-Reply-To: <1333294431.46.0.420841825384.issue14466@psf.upfronthosting.co.za> Message-ID: <1333398757.94.0.671131635881.issue14466@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file25102/ripmq.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 22:33:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 02 Apr 2012 20:33:45 +0000 Subject: [issue14479] Replace transplant with graft in devguide Message-ID: <1333398825.72.0.80965455601.issue14479@psf.upfronthosting.co.za> New submission from Antoine Pitrou : hg has a new "graft" command that replaces and obsoletes the transplant extension. The devguide should be changed in that regard. ---------- components: Devguide messages: 157385 nosy: eric.araujo, ezio.melotti, pitrou, r.david.murray priority: normal severity: normal stage: needs patch status: open title: Replace transplant with graft in devguide _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 22:38:12 2012 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 02 Apr 2012 20:38:12 +0000 Subject: [issue13585] Add contextlib.CallbackStack In-Reply-To: <1323654590.86.0.53041507768.issue13585@psf.upfronthosting.co.za> Message-ID: <1333399092.98.0.281974443736.issue13585@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm unlikely to add the contextlib2.ContextStack API as written. I aim to have an updated variant (called contextlib.CallbackStack) available for alpha 3 in May: https://bitbucket.org/ncoghlan/contextlib2/issue/8/rename-contextstack-to-callbackstack-and ---------- title: Add contextlib.ContextStack -> Add contextlib.CallbackStack _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 2 23:21:35 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 02 Apr 2012 21:21:35 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1333401695.85.0.3110838561.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: Patch version 3: - fix compilation on non-Linux (e.g. on FreeBSD and OpenBSD) - time.monotonic() uses GetTickCount/GetTickCount64 on Windows - clock_getres() fills the accuracy field instead of the resolution field of time.get_clock_info() Clock information on different operating systems. Linux (Fedora 16) on x86_64: >>> pprint.pprint(time.get_clock_info('clock')) {'accuracy': 1e-06, 'function': 'clock()', 'is_adjusted': False, 'is_monotonic': True, 'resolution': 1e-06} >>> pprint.pprint(time.get_clock_info('highres')) {'accuracy': 1e-09, 'function': 'clock_gettime(CLOCK_MONOTONIC_RAW)', 'is_adjusted': False, 'is_monotonic': True, 'resolution': 1e-09} >>> pprint.pprint(time.get_clock_info('monotonic')) {'accuracy': 1e-09, 'function': 'clock_gettime(CLOCK_MONOTONIC_RAW)', 'is_adjusted': False, 'is_monotonic': True, 'resolution': 1e-09} >>> pprint.pprint(time.get_clock_info('time')) {'accuracy': 1e-09, 'function': 'clock_gettime(CLOCK_REALTIME)', 'is_adjusted': True, 'is_monotonic': False, 'resolution': 1e-09} FreeBSD 8.2 on x86_64: >>> pprint.pprint(time.get_clock_info('clock')) {'accuracy': 0.0078125, 'function': 'clock()', 'is_adjusted': False, 'is_monotonic': True, 'resolution': 0.0078125} >>> pprint.pprint(time.get_clock_info('highres')) {'accuracy': 1.1000000000000001e-08, 'function': 'clock_gettime(CLOCK_MONOTONIC)', 'is_monotonic': True, 'resolution': 1e-09} >>> pprint.pprint(time.get_clock_info('monotonic')) {'accuracy': 1.1000000000000001e-08, 'function': 'clock_gettime(CLOCK_MONOTONIC)', 'is_monotonic': True, 'resolution': 1e-09} >>> pprint.pprint(time.get_clock_info('time')) {'accuracy': 1.1000000000000001e-08, 'function': 'clock_gettime(CLOCK_REALTIME)', 'is_adjusted': True, 'is_monotonic': False, 'resolution': 1e-09} OpenBSD on x86_64: >>> pprint.pprint(time.get_clock_info('clock')) {'accuracy': 0.01, 'function': 'clock()', 'is_adjusted': False, 'is_monotonic': True, 'resolution': 0.01} >>> pprint.pprint(time.get_clock_info('highres')) {'accuracy': 0.01, 'function': 'clock_gettime(CLOCK_MONOTONIC)', 'is_monotonic': True, 'resolution': 1e-09} >>> pprint.pprint(time.get_clock_info('monotonic')) {'accuracy': 0.01, 'function': 'clock_gettime(CLOCK_MONOTONIC)', 'is_monotonic': True, 'resolution': 1e-09} >>> pprint.pprint(time.get_clock_info('time')) {'accuracy': 0.01, 'function': 'clock_gettime(CLOCK_REALTIME)', 'is_adjusted': True, 'is_monotonic': False, 'resolution': 1e-09} Python 32 bits on Windows 64 bits: >>> pprint.pprint(time.get_clock_info('clock')) {'accuracy': 1e-08, 'function': 'QueryPerformanceCounter()', 'is_adjusted': False, 'is_monotonic': True, 'resolution': 1e-08} >>> pprint.pprint(time.get_clock_info('highres')) {'accuracy': 1e-08, 'function': 'QueryPerformanceCounter()', 'is_adjusted': False, 'is_monotonic': True, 'resolution': 1e-08} >>> pprint.pprint(time.get_clock_info('monotonic')) {'accuracy': 0.015600099999999999, 'function': 'GetTickCount()', 'is_adjusted': False, 'is_monotonic': True, 'resolution': 0.001} >>> pprint.pprint(time.get_clock_info('time')) {'accuracy': 0.015600099999999999, 'function': 'GetSystemTimeAsFileTime()', 'is_adjusted': True, 'is_monotonic': False, 'resolution': 1e-07} Some remarks: - these 4 platforms provide a monotonic clock - these 4 platforms provide the accurary of the 4 clocks (it looks like Linux is cheating) - on OpenBSD, time.highres() resolution is not so "high". It has only an accuracy of 10 ms. - as expected, the accuracy is very different from the resolution in some cases (ex: 0.0156 vs 1e-07 for time.time() on Windows) ---------- Added file: http://bugs.python.org/file25103/pep418-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 00:14:16 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 02 Apr 2012 22:14:16 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1333404856.07.0.138448349764.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: Solaris on x86_64: >>> pprint.pprint(time.get_clock_info('clock')) {'accuracy': 1e-06, 'function': 'clock()', 'is_adjusted': False, 'is_monotonic': True, 'resolution': 1e-06} >>> pprint.pprint(time.get_clock_info('highres')) {'accuracy': 2e-09, 'function': 'clock_gettime(CLOCK_HIGHRES)', 'is_adjusted': False, 'is_monotonic': True, 'resolution': 1e-09} >>> pprint.pprint(time.get_clock_info('monotonic')) {'accuracy': 2e-09, 'function': 'clock_gettime(CLOCK_HIGHRES)', 'is_adjusted': False, 'is_monotonic': True, 'resolution': 1e-09} >>> pprint.pprint(time.get_clock_info('time')) {'accuracy': 0.01, 'function': 'clock_gettime(CLOCK_REALTIME)', 'is_adjusted': True, 'is_monotonic': False, 'resolution': 1e-09} ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 00:34:02 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 02 Apr 2012 22:34:02 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1333406042.66.0.100736120465.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: TODO (pep418-3.patch): - Use CLOCK_HIGHRES on Solaris - Maybe implement gethrtime() for Solaris ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 00:37:34 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 02 Apr 2012 22:37:34 +0000 Subject: [issue14341] sporadic (?) test_urllib2 failures In-Reply-To: <1331943969.2.0.17966534502.issue14341@psf.upfronthosting.co.za> Message-ID: <1333406254.0.0.393729551131.issue14341@psf.upfronthosting.co.za> Stefan Krah added the comment: This occurs quite frequently now. In the latest build four bots show this error. http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%203.x/builds/5605/steps/test/logs/stdio http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/2158/steps/test/logs/stdio http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6294/steps/test/logs/stdio http://www.python.org/dev/buildbot/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/1911/steps/test/logs/stdio ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 01:30:37 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 02 Apr 2012 23:30:37 +0000 Subject: [issue14466] Rip out mq instructions In-Reply-To: <1333294431.46.0.420841825384.issue14466@psf.upfronthosting.co.za> Message-ID: <1333409437.49.0.352014296787.issue14466@psf.upfronthosting.co.za> R. David Murray added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 01:48:09 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 02 Apr 2012 23:48:09 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1333410489.42.0.352489326049.issue2377@psf.upfronthosting.co.za> Changes by Brett Cannon : Added file: http://bugs.python.org/file25104/0fdf350657e3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 03:08:52 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 03 Apr 2012 01:08:52 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1333415332.96.0.220141376039.issue2377@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, everyone's code review comments have been addressed. That means I have test_pydoc still failing (and that won't get fixed until ImportError grows a module_name attribute; issue #1559549) and test_trace (it doesn't like frozen modules). I also have not plugged the memory leaks that Antoine pointed out (but then again I'm not sure where they might be considering how many people have gone over this code and not spotted a leak that I have not fixed). I also have not dealt with python -v or Windows registry imports. But once everything but the memory leaks are done I will generate a massive patch and commit to default. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 05:47:52 2012 From: report at bugs.python.org (Roger Serwy) Date: Tue, 03 Apr 2012 03:47:52 +0000 Subject: [issue14440] Close background process if IDLE closes abnormally. In-Reply-To: <1333027712.59.0.103811521392.issue14440@psf.upfronthosting.co.za> Message-ID: <1333424872.25.0.46213457686.issue14440@psf.upfronthosting.co.za> Roger Serwy added the comment: This bug is related to issue12540. The approach taken there is to have the IDLE frontend explicitly kill the subprocess. It's a band-aid to the problem that run.py doesn't exit when the socket to the IDLE frontend closes (either by shell restart or kill -9 on IDLE). Attached is a patch to cause the subprocess to exit. I have to admit not fully understanding why it works (on Ubuntu 11.04). It looks like the following code in _getresponse() in rpc.py is what keeps the subprocess running: cvar.acquire() while myseq not in self.responses: cvar.wait() I also tried disabling the "terminate_subprocess" in PyShell.py. With that change, the subprocess does not terminate on a shell restart (unless my patch is applied). Andrew, Terry: What are your thoughts? ---------- keywords: +patch Added file: http://bugs.python.org/file25105/issue14440.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 07:42:28 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 03 Apr 2012 05:42:28 +0000 Subject: [issue802310] tkFont may reuse font names Message-ID: <1333431748.56.0.934985294435.issue802310@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- assignee: -> asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 08:48:14 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Apr 2012 06:48:14 +0000 Subject: [issue802310] tkFont may reuse font names Message-ID: Roundup Robot added the comment: New changeset a77e23135675 by Andrew Svetlov in branch 'default': Issue #802310: Generate always unique tkinter font names if not directly passed http://hg.python.org/cpython/rev/a77e23135675 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 08:51:06 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 03 Apr 2012 06:51:06 +0000 Subject: [issue802310] tkFont may reuse font names Message-ID: <1333435866.54.0.521639924854.issue802310@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I've pushed fix inspired by Guilherme's suggestion. Fix has been applied to 3.3 only because: 1. It changes font name generation schema 2. It's definitelly minor issue as exists starting from 2003. Thanks. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 08:54:33 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 03 Apr 2012 06:54:33 +0000 Subject: [issue6015] Tkinter Scrollbar in OS X 10.5 In-Reply-To: <1242255714.91.0.667692922857.issue6015@psf.upfronthosting.co.za> Message-ID: <1333436073.43.0.435192651526.issue6015@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Can anybody confirm this bug for OS X? ---------- nosy: +asvetlov, ned.deily type: performance -> behavior versions: +Python 3.3 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 08:57:32 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Apr 2012 06:57:32 +0000 Subject: [issue14479] Replace transplant with graft in devguide In-Reply-To: <1333398825.72.0.80965455601.issue14479@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b1dfbaae4458 by Georg Brandl in branch 'default': Closes #14479: replace transplant advice with graft http://hg.python.org/devguide/rev/b1dfbaae4458 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 09:23:14 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 03 Apr 2012 07:23:14 +0000 Subject: [issue14480] os.kill on Windows should accept zero as signal Message-ID: <1333437794.42.0.926195578505.issue14480@psf.upfronthosting.co.za> New submission from Andrew Svetlov : Starting from 3.2 Python supports os.kill for Windows. It process signal.CTRL_C_EVENT and signal.CTRL_BREAK_EVENT, and kills pid for all other signals. Posix allows to pass zero signal to check pid for existing. It will be nice to keep that behavior for Windows also. The patch should be trivial: just don't call TerminateProcess in Modules/posixmodule.c:win32_kill if sig is zero. ---------- components: Library (Lib), Windows keywords: easy messages: 157398 nosy: asvetlov priority: normal severity: normal status: open title: os.kill on Windows should accept zero as signal type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 09:44:30 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 03 Apr 2012 07:44:30 +0000 Subject: [issue6015] Tkinter Scrollbar in OS X 10.5 In-Reply-To: <1242255714.91.0.667692922857.issue6015@psf.upfronthosting.co.za> Message-ID: <1333439070.86.0.321662643772.issue6015@psf.upfronthosting.co.za> Ned Deily added the comment: I am unable to reproduce this behavior with current versions of Python 2.7 or 3.2 on OS X 10.5.8 using either the most recent Apple-supplied Carbon Tcl/Tk 8.4 or with the latest ActiveState Tcl/Tk 8.4 nor with on OS X 10.7 with Tcl/Tk 8.4 or 8.5. There have been many fixes on the Python side to Tkinter and on the Tcl/Tk side. If you can reproduce with a current Python 2.7.2 (or later) or 3.2.2 (or later), please reopen with details including which Python build and Tcl/Tk are in use. ---------- resolution: -> out of date stage: -> committed/rejected status: open -> closed versions: +Python 2.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 10:01:44 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 03 Apr 2012 08:01:44 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1333406042.66.0.100736120465.issue14428@psf.upfronthosting.co.za> Message-ID: <4F7AAE5D.6000509@egenix.com> Marc-Andre Lemburg added the comment: Hi Victor, I think you need to reconsider the time.steady() name you're using in the PEP. For practical purposes, it's better to call it time.monotonic() and only make the function available if the OS provides a monotonic clock. The fallback to time.time() is not a good idea, since then the programmer has to check whether the timer really provides the features she's after every time it gets used. Regardless of this functional problem, I'm also not sure what you want to imply by the term "steady". A steady beat would mean that the timer never stops and keeps a constant pace, but that's not the case for the timers you're using to implement time.steady(). If you're after a mathematical term, "continuous" would be a better term, but again, time.time() is not always continuous. Instead of trying to tweak all the different clocks and timers into a single function, wouldn't it be better to expose each kind as a different function and then let the programmer decide which fits best ?! BTW: Thanks for the research you've done on the different clocks and timers. That's very useful information. Thanks, -- Marc-Andre Lemburg eGenix.com ________________________________________________________________________ 2012-04-03: Python Meeting Duesseldorf today ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 10:12:24 2012 From: report at bugs.python.org (Chris Rebert) Date: Tue, 03 Apr 2012 08:12:24 +0000 Subject: [issue14481] trivial formatting error in subprocess docs Message-ID: <1333440744.26.0.476663601501.issue14481@psf.upfronthosting.co.za> New submission from Chris Rebert : The final line under "17.1.4.2. Replacing shell pipeline" (http://docs.python.org/dev/library/subprocess.html#replacing-shell-pipeline ) isn't formatted as code (e.g. monospaced); it should be. ---------- assignee: docs at python components: Documentation messages: 157401 nosy: cvrebert, docs at python priority: normal severity: normal status: open title: trivial formatting error in subprocess docs versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 10:37:35 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 03 Apr 2012 08:37:35 +0000 Subject: [issue14466] Rip out mq instructions In-Reply-To: <1333294431.46.0.420841825384.issue14466@psf.upfronthosting.co.za> Message-ID: <1333442255.09.0.811841845127.issue14466@psf.upfronthosting.co.za> Ezio Melotti added the comment: + hg import --no-commit < mywork.patch Is the '<' correct here? I would also mention hg diff right away, and explain about adding/removing files after that. The rest looks good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 11:06:21 2012 From: report at bugs.python.org (Berker Peksag) Date: Tue, 03 Apr 2012 09:06:21 +0000 Subject: [issue14481] trivial formatting error in subprocess docs In-Reply-To: <1333440744.26.0.476663601501.issue14481@psf.upfronthosting.co.za> Message-ID: <1333443981.58.0.80321968016.issue14481@psf.upfronthosting.co.za> Berker Peksag added the comment: Attached a patch. ---------- keywords: +patch nosy: +berker.peksag Added file: http://bugs.python.org/file25106/issue14481.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 11:28:42 2012 From: report at bugs.python.org (Popa Claudiu) Date: Tue, 03 Apr 2012 09:28:42 +0000 Subject: [issue14482] multiprocessing.connection.Listener fails with invalid address on Windows Message-ID: <1333445322.44.0.595815869021.issue14482@psf.upfronthosting.co.za> New submission from Popa Claudiu : This is related to http://bugs.python.org/issue14151. When using an AF_UNIX address with multiprocessing.connection.Listener or Client, the following error will occur, due to the fact that AF_UNIX is not present in socket module. >>> import multiprocessing.connection as con >>> con.Listener('/var/a.pipe') Traceback (most recent call last): File "", line 1, in File "C:\Python31\lib\multiprocessing\connection.py", line 97, in __init__ self._listener = SocketListener(address, family, backlog) File "C:\Python31\lib\multiprocessing\connection.py", line 216, in __init__ self._socket = socket.socket(getattr(socket, family)) AttributeError: 'module' object has no attribute 'AF_UNIX' The attached patch fixes this issue, the check is done in the newly added _validate_family, where a similar check is done for AF_PIPE on Unix systems. ---------- components: Library (Lib) files: multiprocessing.patch keywords: patch messages: 157404 nosy: Popa.Claudiu, pitrou priority: normal severity: normal status: open title: multiprocessing.connection.Listener fails with invalid address on Windows type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25107/multiprocessing.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 11:56:32 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 03 Apr 2012 09:56:32 +0000 Subject: [issue14288] Make iterators pickleable In-Reply-To: <1331655020.29.0.612944465478.issue14288@psf.upfronthosting.co.za> Message-ID: <1333446992.6.0.499714122531.issue14288@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Good idea Antoine. So, I'll with your suggested fix to the unittests I'll commit this and then look on while Rome burns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 12:30:41 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 03 Apr 2012 10:30:41 +0000 Subject: [issue14466] Rip out mq instructions In-Reply-To: <1333442255.09.0.811841845127.issue14466@psf.upfronthosting.co.za> Message-ID: <20120403103033.GA2052@mathmagic> Senthil Kumaran added the comment: On Tue, Apr 03, 2012 at 08:37:35AM +0000, Ezio Melotti wrote: > > Ezio Melotti added the comment: > > + hg import --no-commit < mywork.patch > > Is the '<' correct here? No!. It should just be hg import --no-commit mywork.patch. I asked around at PyCon to see if there were people using 'mq' just to know about their workflow and it's advantages. I think only Ned mentioned that he was using it, but everyone "theoretically" agreed that it could be useful extension while working on a patch. When it is not being used by many, I think it is just adding to the confusion by it's mention in the devguide. +1 to remove it. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From senthil at uthcode.com Tue Apr 3 12:30:33 2012 From: senthil at uthcode.com (Senthil Kumaran) Date: Tue, 3 Apr 2012 18:30:33 +0800 Subject: [issue14466] Rip out mq instructions In-Reply-To: <1333442255.09.0.811841845127.issue14466@psf.upfronthosting.co.za> References: <1333294431.46.0.420841825384.issue14466@psf.upfronthosting.co.za> <1333442255.09.0.811841845127.issue14466@psf.upfronthosting.co.za> Message-ID: <20120403103033.GA2052@mathmagic> On Tue, Apr 03, 2012 at 08:37:35AM +0000, Ezio Melotti wrote: > > Ezio Melotti added the comment: > > + hg import --no-commit < mywork.patch > > Is the '<' correct here? No!. It should just be hg import --no-commit mywork.patch. I asked around at PyCon to see if there were people using 'mq' just to know about their workflow and it's advantages. I think only Ned mentioned that he was using it, but everyone "theoretically" agreed that it could be useful extension while working on a patch. When it is not being used by many, I think it is just adding to the confusion by it's mention in the devguide. +1 to remove it. From report at bugs.python.org Tue Apr 3 12:45:17 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 03 Apr 2012 10:45:17 +0000 Subject: [issue14482] multiprocessing.connection.Listener fails with invalid address on Windows In-Reply-To: <1333445322.44.0.595815869021.issue14482@psf.upfronthosting.co.za> Message-ID: <1333449917.37.0.233399292064.issue14482@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks. The patch looks good to me. ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 13:12:05 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Apr 2012 11:12:05 +0000 Subject: [issue14288] Make iterators pickleable In-Reply-To: <1331655020.29.0.612944465478.issue14288@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 4ff234337e24 by Kristj?n Valur J?nsson in branch 'default': Issue #14288: Serialization support for builtin iterators. http://hg.python.org/cpython/rev/4ff234337e24 New changeset 51c88d51aa4a by Kristj?n Valur J?nsson in branch 'default': Issue #14288: Modify Misc/NEWS http://hg.python.org/cpython/rev/51c88d51aa4a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 13:30:39 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 03 Apr 2012 11:30:39 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <4F7AAE5D.6000509@egenix.com> Message-ID: STINNER Victor added the comment: > I think you need to reconsider the time.steady() name you're using > in the PEP. For practical purposes, it's better to call it > time.monotonic() I opened a new thread on python-dev to discuss this topic. > and only make the function available if the OS provides > a monotonic clock. Oh, I should explain this choice in the PEP. Basically, the idea is to provide a best-effort portable function. > The fallback to time.time() is not a good idea, since then the programmer > has to check whether the timer really provides the features she's after > every time it gets used. Nope, time.get_clock_info('steady') does not change at runtime. So it can only be checked once. > Instead of trying to tweak all the different clocks and timers into > a single function, wouldn't it be better to expose each kind as a > different function and then let the programmer decide which fits > best ?! This is a completly different approach. It should be discussed on python-dev, not in the bug tracker please. I think that Python can help the developer to write portable code by providing high-level functions because clock properties are well known (e.g. see time.get_clock_info). > BTW: Thanks for the research you've done on the different clocks and > timers. That's very useful information. You're welcome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 13:33:45 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 03 Apr 2012 11:33:45 +0000 Subject: [issue14480] os.kill on Windows should accept zero as signal In-Reply-To: <1333437794.42.0.926195578505.issue14480@psf.upfronthosting.co.za> Message-ID: <1333452825.85.0.974675787949.issue14480@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +brian.curtin stage: -> needs patch type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 13:41:49 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 03 Apr 2012 11:41:49 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: Message-ID: <4F7AE1F2.4050102@egenix.com> Marc-Andre Lemburg added the comment: STINNER Victor wrote: > > STINNER Victor added the comment: > >> I think you need to reconsider the time.steady() name you're using >> in the PEP. For practical purposes, it's better to call it >> time.monotonic() > > I opened a new thread on python-dev to discuss this topic. > >> and only make the function available if the OS provides >> a monotonic clock. > > Oh, I should explain this choice in the PEP. Basically, the idea is to > provide a best-effort portable function. > >> The fallback to time.time() is not a good idea, since then the programmer >> has to check whether the timer really provides the features she's after >> every time it gets used. > > Nope, time.get_clock_info('steady') does not change at runtime. So it > can only be checked once. With "every time" I meant: in every application you use the function. That pretty much spoils the idea of a best effort portable function. It's better to use a try-except to test for availability of functions than to have to (remember to) call a separate function to find out the characteristics of the best effort approach. >> Instead of trying to tweak all the different clocks and timers into >> a single function, wouldn't it be better to expose each kind as a >> different function and then let the programmer decide which fits >> best ?! > > This is a completly different approach. It should be discussed on > python-dev, not in the bug tracker please. I think that Python can > help the developer to write portable code by providing high-level > functions because clock properties are well known (e.g. see > time.get_clock_info). Fair enough. BTW: Are aware of the existing systimes.py module in pybench, which already provides interfaces to high resolution timers usable for benchmarking in a portable way ? Perhaps worth mentioning in the PEP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 13:54:25 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 03 Apr 2012 11:54:25 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1333454065.95.0.98065739826.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: Patch version 4: - Rename time.monotonic() to time.steady() - Don't use CLOCK_MONOTONIC_RAW but CLOCK_MONOTONIC for time.highres() and time.steady() - Use CLOCK_HIGHRES, useful on Solaris - Rewrite time.highres() and time.steady() documentation ---------- Added file: http://bugs.python.org/file25108/pep418-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 13:54:31 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 03 Apr 2012 11:54:31 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1333454071.86.0.390478636562.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25053/pep418.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 13:54:33 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 03 Apr 2012 11:54:33 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1333454073.08.0.219929536974.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25101/pep418-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 13:54:34 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 03 Apr 2012 11:54:34 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1333454074.92.0.0576939936526.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25103/pep418-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 14:00:44 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 03 Apr 2012 12:00:44 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1333454444.91.0.571372478017.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: > BTW: Are aware of the existing systimes.py module in pybench, > which already provides interfaces to high resolution timers usable > for benchmarking in a portable way ? Perhaps worth mentioning in > the PEP. Nope, I didn't know it. It mentioned it in the PEP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 14:47:32 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Apr 2012 12:47:32 +0000 Subject: [issue14481] trivial formatting error in subprocess docs In-Reply-To: <1333440744.26.0.476663601501.issue14481@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2c1ce04ded55 by R David Murray in branch '2.7': #14481: fix formatting of example in subprocess docs. http://hg.python.org/cpython/rev/2c1ce04ded55 New changeset e5f5652bfe91 by R David Murray in branch '3.2': #14481: fix formatting of example in subprocess docs. http://hg.python.org/cpython/rev/e5f5652bfe91 New changeset 9599f091faa6 by R David Murray in branch 'default': Merge #14481: fix formatting of example in subprocess docs. http://hg.python.org/cpython/rev/9599f091faa6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 14:48:13 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 03 Apr 2012 12:48:13 +0000 Subject: [issue14481] trivial formatting error in subprocess docs In-Reply-To: <1333440744.26.0.476663601501.issue14481@psf.upfronthosting.co.za> Message-ID: <1333457293.71.0.713921465663.issue14481@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks. ---------- nosy: +r.david.murray resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 15:41:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Apr 2012 13:41:26 +0000 Subject: [issue14466] Rip out mq instructions In-Reply-To: <1333294431.46.0.420841825384.issue14466@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e1d4b6dc9702 by Antoine Pitrou in branch 'default': Issue #14466: remove mq-based workflow http://hg.python.org/devguide/rev/e1d4b6dc9702 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 15:41:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 03 Apr 2012 13:41:45 +0000 Subject: [issue14466] Rip out mq instructions In-Reply-To: <1333294431.46.0.420841825384.issue14466@psf.upfronthosting.co.za> Message-ID: <1333460505.1.0.388369459969.issue14466@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Done, thank you. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 15:51:54 2012 From: report at bugs.python.org (Sean Grider) Date: Tue, 03 Apr 2012 13:51:54 +0000 Subject: [issue14483] inspect.getsource fails to read a file of only comments Message-ID: <1333461114.24.0.345526771392.issue14483@psf.upfronthosting.co.za> New submission from Sean Grider : I have a custom parser that generates html files to describe what python scripts do depending on their source comments. I use inspect.getsourcelines to parse out different comments styles (I use #@, #@@ and #$ to signal custom comments) I recently found that getsource and getsourcelines return nothing if the file contains nothing other than a def main and it's comments. It seems that getsource stops reading after the last non-comment line. For example: def main(): """ description """ #comment1 #comment2 #comment3 getsource on the above file will return def main and the doc_string but nothing else. if however I change it to: def main(): """ description """ #comment1 #comment2 #comment3 return I now get the entire file, but just doing the following: def main(): """ description """ #comment1 my_var = 123 #comment2 #comment3 will now give me def main, the doc_string and comment1, but nothing else. Is this expected behavior? I would think that the parser should not care if the source is comments or code, I just want to read whatever is in the file. This behavior is present on 2.7.2 on both Windows 7x64 and RedHat 2.6.39.4-2.fc12.x86_64 ---------- messages: 157417 nosy: Sean.Grider priority: normal severity: normal status: open title: inspect.getsource fails to read a file of only comments type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 16:07:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 03 Apr 2012 14:07:02 +0000 Subject: [issue14483] inspect.getsource fails to read a file of only comments In-Reply-To: <1333461114.24.0.345526771392.issue14483@psf.upfronthosting.co.za> Message-ID: <1333462022.55.0.0681538550948.issue14483@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 16:08:14 2012 From: report at bugs.python.org (Brian Curtin) Date: Tue, 03 Apr 2012 14:08:14 +0000 Subject: [issue14480] os.kill on Windows should accept zero as signal In-Reply-To: <1333437794.42.0.926195578505.issue14480@psf.upfronthosting.co.za> Message-ID: <1333462094.38.0.570562885864.issue14480@psf.upfronthosting.co.za> Brian Curtin added the comment: -1 0 has no special meaning on Windows so I'd rather not add another special case for posix emulation. Additionally, 0 unfortunately already means two things as it is: signal.CTRL_C_EVENT and the int 0. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 16:10:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 03 Apr 2012 14:10:26 +0000 Subject: [issue14484] missing return in win32_kill? Message-ID: <1333462226.23.0.725280599354.issue14484@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Here is an excerpt from the os.kill implementation under Windows (in win32_kill(), posixmodule.c): if (sig == CTRL_C_EVENT || sig == CTRL_BREAK_EVENT) { if (GenerateConsoleCtrlEvent(sig, pid) == 0) { err = GetLastError(); PyErr_SetFromWindowsErr(err); } else Py_RETURN_NONE; } It seems there is a missing return in the first branch, when GenerateConsoleCtrlEvent() fails. ---------- components: Windows messages: 157419 nosy: asvetlov, brian.curtin, pitrou, tim.golden priority: normal severity: normal status: open title: missing return in win32_kill? type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 16:14:03 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 03 Apr 2012 14:14:03 +0000 Subject: [issue14440] Close background process if IDLE closes abnormally. In-Reply-To: <1333027712.59.0.103811521392.issue14440@psf.upfronthosting.co.za> Message-ID: <1333462443.07.0.593784727018.issue14440@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I still prefer to check in subprocess for parent proc existing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 16:19:03 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 03 Apr 2012 14:19:03 +0000 Subject: [issue14484] missing return in win32_kill? In-Reply-To: <1333462226.23.0.725280599354.issue14484@psf.upfronthosting.co.za> Message-ID: <1333462743.51.0.532220347564.issue14484@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Antonie, you right. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 16:20:00 2012 From: report at bugs.python.org (Brian Curtin) Date: Tue, 03 Apr 2012 14:20:00 +0000 Subject: [issue14484] missing return in win32_kill? In-Reply-To: <1333462226.23.0.725280599354.issue14484@psf.upfronthosting.co.za> Message-ID: <1333462800.02.0.13573522206.issue14484@psf.upfronthosting.co.za> Brian Curtin added the comment: I can't find where we talked about this, maybe just IRC, but that's there (perhaps poorly) as a special case. 0 is 0, but signal.CTRL_C_EVENT is also 0. We try the signal version first then fall back to TerminateProcess. I was just looking at this myself and it's not great. I actually wish we could change what signal.CTRL_C_EVENT means, or maybe add a flag to determine if the second parameter is supposed to be a return code or a signal? I'm open to anything. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 16:20:00 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 03 Apr 2012 14:20:00 +0000 Subject: [issue14127] add st_*time_ns fileds to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1333462800.55.0.754368295838.issue14127@psf.upfronthosting.co.za> Larry Hastings added the comment: Sorry to let this slide but I just got back from vacation. Unless anybody has any more feedback I'm checking this in tomorrow (Wednesday April 4). Phew! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 16:24:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 03 Apr 2012 14:24:10 +0000 Subject: [issue14484] missing return in win32_kill? In-Reply-To: <1333462800.02.0.13573522206.issue14484@psf.upfronthosting.co.za> Message-ID: <1333462738.3382.7.camel@localhost.localdomain> Antoine Pitrou added the comment: > I can't find where we talked about this, maybe just IRC, but that's > there (perhaps poorly) as a special case. > > 0 is 0, but signal.CTRL_C_EVENT is also 0. We try the signal version > first then fall back to TerminateProcess. Then why set the error? That said, abruptly killing another process and making it return 0 sounds a bit perverted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 16:35:12 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 03 Apr 2012 14:35:12 +0000 Subject: [issue14480] os.kill on Windows should accept zero as signal In-Reply-To: <1333437794.42.0.926195578505.issue14480@psf.upfronthosting.co.za> Message-ID: <1333463712.64.0.0926108233243.issue14480@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. I would think it would be a good idea to have os.kill do posix emulation where that makes sense, it makes cross-platform usage easier. That's what 'kill' with no signal does, right (kills the process, just like the posix default)? The posix spec says "If sig is 0 (the null signal), error checking is performed but no signal is actually sent. The null signal can be used to check the validity of pid." So *signal* zero doesn't have any special meaning on posix, either, but it does have a special meaning to the kill command. It seems like it would be nice to add support for that to the windows version, but I'm a little confused. First you say that signal 0 has no special meaning, and then you say that it does (signal.CTRL_C_EVENT). Which is it? ---------- nosy: +r.david.murray status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 16:38:46 2012 From: report at bugs.python.org (Brian Curtin) Date: Tue, 03 Apr 2012 14:38:46 +0000 Subject: [issue14484] missing return in win32_kill? In-Reply-To: <1333462226.23.0.725280599354.issue14484@psf.upfronthosting.co.za> Message-ID: <1333463926.18.0.62076489311.issue14484@psf.upfronthosting.co.za> Brian Curtin added the comment: I don't remember exactly why, but it can be removed. It may have just been left in while I was debugging it. As for the second point, why else are you calling os.kill if you don't want to kill the given process? I don't disagree that it's on the perverse side, but that's the functionality available. Perhaps we should *not* have the fallback and only operate on the signals? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 16:43:06 2012 From: report at bugs.python.org (Brian Curtin) Date: Tue, 03 Apr 2012 14:43:06 +0000 Subject: [issue14480] os.kill on Windows should accept zero as signal In-Reply-To: <1333437794.42.0.926195578505.issue14480@psf.upfronthosting.co.za> Message-ID: <1333464186.93.0.233696708361.issue14480@psf.upfronthosting.co.za> Brian Curtin added the comment: I meant that in the underlying, such as in the TerminateProcess API, 0 doesn't mean anything special. As is being debated over on #14484 we currently take all integers to be passed to TerminateProcess (the int becomes the killed proc's return code), and two signals to pass to GenerateConsoleCtrlEvent (which is more like posix os.kill). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 17:05:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 03 Apr 2012 15:05:13 +0000 Subject: [issue14484] missing return in win32_kill? In-Reply-To: <1333463926.18.0.62076489311.issue14484@psf.upfronthosting.co.za> Message-ID: <1333465201.3382.8.camel@localhost.localdomain> Antoine Pitrou added the comment: > As for the second point, why else are you calling os.kill if you don't > want to kill the given process? I don't disagree that it's on the > perverse side, but that's the functionality available. Perhaps we > should *not* have the fallback and only operate on the signals? I just meant that exiting with 0 isn't exactly expected when a process is forcibly killed (0 meaning success, as far as I know). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 17:07:47 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 03 Apr 2012 15:07:47 +0000 Subject: [issue14484] missing return in win32_kill? In-Reply-To: <1333462226.23.0.725280599354.issue14484@psf.upfronthosting.co.za> Message-ID: <1333465667.21.0.443606973017.issue14484@psf.upfronthosting.co.za> R. David Murray added the comment: I would think that if Windows doesn't support a specific signal, os.kill should raise a ValueError. But I'm an outsider here, I know nothing about how Windows works for this except what I'm reading here. To answer your question: there are many reasons to call kill on unix, and only a few of them kill the process. Kill is just an historical name, it really means 'send a signal'. In a broader picture, I think that os.kill calls should have the same "meaning", insofar as possible, on both linux and windows. Having a single API with the same syntax but different semantics on different platforms sounds bad to me. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 17:09:19 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 03 Apr 2012 15:09:19 +0000 Subject: [issue14480] os.kill on Windows should accept zero as signal In-Reply-To: <1333437794.42.0.926195578505.issue14480@psf.upfronthosting.co.za> Message-ID: <1333465759.12.0.217423729526.issue14480@psf.upfronthosting.co.za> Andrew Svetlov added the comment: There are no `kill` function in Windows API. >From my perspective win32_kill was added to emulate posix sibling if possible. If not ? better to give another Windows native name to that function. Really don't see good solution. Maybe better what we can do ? declare what os.kill cannot be called with 0 signum on Windows for proc presence checking and note that fact in os.rst. Terminating process looks like overcomplication. POSIX kill only sends signal to process and nothing more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 18:28:25 2012 From: report at bugs.python.org (junyan) Date: Tue, 03 Apr 2012 16:28:25 +0000 Subject: [issue14485] hi, thanks, nice to learn from you Message-ID: <1333470442.82661.YahooMailClassic@web114201.mail.gq1.yahoo.com> New submission from junyan : Thank you very much, thanks for your job of the free software opening to us, and I am a primary worker on this aspect research. best. Yours Junyan ---------- messages: 157431 nosy: james tao priority: normal severity: normal status: open title: hi, thanks, nice to learn from you _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 18:34:12 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 03 Apr 2012 16:34:12 +0000 Subject: [issue14485] hi, thanks, nice to learn from you In-Reply-To: <1333470442.82661.YahooMailClassic@web114201.mail.gq1.yahoo.com> Message-ID: <1333470852.0.0.434654705208.issue14485@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Dear Junyan, you are very welcome. Please understand that Python is really a contribution of many developers, so if you ever want to contribute to Python, please post your bug reports and patches here. ---------- nosy: +loewis resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 19:52:26 2012 From: report at bugs.python.org (Daniel Blanchard) Date: Tue, 03 Apr 2012 17:52:26 +0000 Subject: [issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions In-Reply-To: <1280333027.17.0.112361474517.issue9400@psf.upfronthosting.co.za> Message-ID: <1333475546.65.0.263227397965.issue9400@psf.upfronthosting.co.za> Daniel Blanchard added the comment: I believe I'm still encountering this issue in 2.7: Exception in thread Thread-3: Traceback (most recent call last): File "/opt/python/2.7/lib/python2.7/threading.py", line 552, in __bootstrap_inner self.run() File "/opt/python/2.7/lib/python2.7/threading.py", line 505, in run self.__target(*self.__args, **self.__kwargs) File "/opt/python/2.7/lib/python2.7/multiprocessing/pool.py", line 347, in _handle_results task = get() TypeError: ('__init__() takes at least 3 arguments (1 given)', , ()) ---------- nosy: +Daniel.Blanchard versions: +Python 2.7 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 20:20:38 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Apr 2012 18:20:38 +0000 Subject: [issue14482] multiprocessing.connection.Listener fails with invalid address on Windows In-Reply-To: <1333445322.44.0.595815869021.issue14482@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 57c0867fbf30 by Antoine Pitrou in branch '3.2': Issue #14482: Raise a ValueError, not a NameError, when trying to create http://hg.python.org/cpython/rev/57c0867fbf30 New changeset ddc5adcedf29 by Antoine Pitrou in branch 'default': Issue #14482: Raise a ValueError, not a NameError, when trying to create http://hg.python.org/cpython/rev/ddc5adcedf29 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 20:21:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 03 Apr 2012 18:21:42 +0000 Subject: [issue14482] multiprocessing.connection.Listener fails with invalid address on Windows In-Reply-To: <1333445322.44.0.595815869021.issue14482@psf.upfronthosting.co.za> Message-ID: <1333477302.89.0.256417031005.issue14482@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you for the patch. It's now committed. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 20:26:57 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 03 Apr 2012 18:26:57 +0000 Subject: [issue13700] imaplib.IMAP4.authenticate authobject fails with PLAIN mechanism In-Reply-To: <1325553089.14.0.504978991098.issue13700@psf.upfronthosting.co.za> Message-ID: <1333477617.41.0.362652281565.issue13700@psf.upfronthosting.co.za> R. David Murray added the comment: I made some time to work on this today. Attached is a new patch. I've incorporated the tests from the existing patches (though I'm doing the infrastructure a bit differently). PLAIN seems to be a specific case of the general authenticate, so I just have a generalized test. My fix is slightly different. I'm changing the _Authenticate class to except either bytes or string as input. String because that's more natural in Python3, bytes because there might be auth mechanisms that require bytes (since implementations can define 'X' auth mechanisms). The authentication callback always gets passed the data as bytes, for the same reasons of generality. So I'd be OK with the idea that the authentication handler always has to return bytes...which would require a different fix in login_cram_md5. My login_cram_md5 test passes, so I *think* the fix I made there is OK. However, I'm getting a traceback from SSL about the socket being shut down, which seems to arise from an imaplib.abort resulting from an unexpected 'b''' value. I'm out of time for working in this right now, so I'm uploading the patch to see if anyone else has time to figure it out. I'll come back to it as some point but I don't know when. ---------- assignee: docs at python -> r.david.murray components: -Documentation nosy: -docs at python stage: -> patch review versions: -Python 3.1 Added file: http://bugs.python.org/file25109/imaplib_authenticate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 20:47:48 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 03 Apr 2012 18:47:48 +0000 Subject: [issue12979] tkinter.font.Font object not usable as font option In-Reply-To: <1316025572.88.0.893423233334.issue12979@psf.upfronthosting.co.za> Message-ID: <1333478868.56.0.0848467875738.issue12979@psf.upfronthosting.co.za> Andrew Svetlov added the comment: The test from ilikepython is incorrect, but after changing to: import tkinter import tkinter.font root = tkinter.Tk() w = tkinter.Frame(root) f = tkinter.font.Font(root, family='Arial', size=30) label = tkinter.Label(w, text="Hello", font=f) label.pack() w.pack() root.mainloop() it works. Closing the issue. ---------- assignee: -> asvetlov nosy: +asvetlov resolution: -> works for me stage: -> committed/rejected status: open -> closed versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 20:50:48 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 03 Apr 2012 18:50:48 +0000 Subject: [issue3405] Add support for the new data option supported by event generate (Tk 8.5) In-Reply-To: <1216385566.01.0.7972232454.issue3405@psf.upfronthosting.co.za> Message-ID: <1333479048.42.0.596977727435.issue3405@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 20:52:52 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 03 Apr 2012 18:52:52 +0000 Subject: [issue1584] Mac OS X: building with X11 Tkinter In-Reply-To: <1197345898.75.0.132866639605.issue1584@psf.upfronthosting.co.za> Message-ID: <1333479172.74.0.924734011593.issue1584@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Is there actual? ---------- nosy: +asvetlov versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 21:04:30 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 03 Apr 2012 19:04:30 +0000 Subject: [issue14065] Element should support cyclic GC In-Reply-To: <1329755208.03.0.143933032526.issue14065@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 14abfa27ff19 by Eli Bendersky in branch 'default': Fixes and enhancements to _elementtree: http://hg.python.org/cpython/rev/14abfa27ff19 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 21:04:55 2012 From: report at bugs.python.org (Eli Bendersky) Date: Tue, 03 Apr 2012 19:04:55 +0000 Subject: [issue14065] Element should support cyclic GC In-Reply-To: <1329755208.03.0.143933032526.issue14065@psf.upfronthosting.co.za> Message-ID: <1333479895.28.0.357404276232.issue14065@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 21:14:08 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 03 Apr 2012 19:14:08 +0000 Subject: [issue3033] tkFont added displayof where necessary In-Reply-To: <1212515294.71.0.756028895858.issue3033@psf.upfronthosting.co.za> Message-ID: <1333480448.84.0.0407857208861.issue3033@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I've updated the patch. If nobody object I'll commit it soon. ---------- nosy: +asvetlov versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file25110/issue3033.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 22:03:03 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 03 Apr 2012 20:03:03 +0000 Subject: [issue1584] Mac OS X: building with X11 Tkinter In-Reply-To: <1197345898.75.0.132866639605.issue1584@psf.upfronthosting.co.za> Message-ID: <1333483383.04.0.993660677856.issue1584@psf.upfronthosting.co.za> Ned Deily added the comment: It certainly is still possible to patch current Pythons to build with the X11 Tk 8.5 on OS X. For example, the current MacPorts Python ports use an X11 Tk 8.5. Considering all the issues that have arisen with the other Tcl/Tk implementations on OS X (i.e. Cocoa Tk and Carbon Tk), I think it would be useful to provide better support for choosing which to build with. I'll take a look at this as a possible feature. ---------- assignee: -> ned.deily nosy: +ned.deily -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 22:04:43 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 03 Apr 2012 20:04:43 +0000 Subject: [issue1584] Mac OS X: building with X11 Tkinter In-Reply-To: <1197345898.75.0.132866639605.issue1584@psf.upfronthosting.co.za> Message-ID: <1333483483.9.0.173997620946.issue1584@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Thank you, Ned. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 22:17:35 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 03 Apr 2012 20:17:35 +0000 Subject: [issue14470] Remove using of w9xopen in subprocess module In-Reply-To: <1333303587.03.0.401233973218.issue14470@psf.upfronthosting.co.za> Message-ID: <1333484255.07.0.503447297105.issue14470@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Brian, please don't forget to cleanup subprocess code when you will be ready to. ---------- assignee: -> brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 22:33:02 2012 From: report at bugs.python.org (Brian Curtin) Date: Tue, 03 Apr 2012 20:33:02 +0000 Subject: [issue14470] Remove using of w9xopen in subprocess module In-Reply-To: <1333303587.03.0.401233973218.issue14470@psf.upfronthosting.co.za> Message-ID: <1333485182.6.0.83649488591.issue14470@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- priority: critical -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 23:11:08 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 03 Apr 2012 21:11:08 +0000 Subject: [issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions In-Reply-To: <1280333027.17.0.112361474517.issue9400@psf.upfronthosting.co.za> Message-ID: <1333487468.73.0.795126463622.issue9400@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Here is another patch, with test. ---------- nosy: +amaury.forgeotdarc stage: test needed -> patch review Added file: http://bugs.python.org/file25111/picklable_process_exception.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 3 23:47:30 2012 From: report at bugs.python.org (Sandro Tosi) Date: Tue, 03 Apr 2012 21:47:30 +0000 Subject: [issue2636] Adding a new regex module (compatible with re) In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za> Message-ID: <1333489650.34.0.921049054376.issue2636@psf.upfronthosting.co.za> Sandro Tosi added the comment: I've just uploaded regex into Debian: this will hopefully gives some more eyes looking at the module and reporting some feedbacks. ---------- nosy: +sandro.tosi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 01:09:07 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 03 Apr 2012 23:09:07 +0000 Subject: [issue11734] Add half-float (16-bit) support to struct module In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za> Message-ID: <1333494547.26.0.604253380856.issue11734@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +pitrou stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 01:14:04 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 03 Apr 2012 23:14:04 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1333494844.02.0.682554603539.issue14478@psf.upfronthosting.co.za> Stefan Krah added the comment: I agree that caching the hash would be useful for 3.2, but the request comes at a unfortunate time: 3.2.3 is about to be released, and there's no way that the change would go into it. So let's focus on the C version in 3.3. These are the timings on a 64-bit machine with the C version in 3.3: int: 0.537806510925293 CachingDecimal: 2.2549374103546143 Decimal: 1.8158345222473145 These are the timings with a hacked C version that caches the hash: int: 0.5755119323730469 CachingDecimal: 2.3034861087799072 Decimal: 0.4364290237426758 The hash calculation time depends on the size of the coefficient of the Decimal and the exponent. Note that the context is not applied when using the Decimal constructor: >>> Decimal(1e100) Decimal('10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104') So the numbers you are using have an unusually high precision for regular decimal floating point arithmetic. If you want well defined limits, I suggest using either: >>> Decimal('1e100') Decimal('1E+100') Or, if the input really must be a float: >>> c = getcontext() >>> c.create_decimal(1e100) Decimal('1.000000000000000015902891110E+100') In that latter case, of course the conversion is inexact and rounded (but hashing will be faster). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 01:29:42 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 03 Apr 2012 23:29:42 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1333495782.3.0.634643018746.issue14478@psf.upfronthosting.co.za> Stefan Krah added the comment: > but hashing will be faster. I retract that. The exponent actually makes things worse. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 01:45:25 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 03 Apr 2012 23:45:25 +0000 Subject: [issue14065] Element should support cyclic GC In-Reply-To: <1329755208.03.0.143933032526.issue14065@psf.upfronthosting.co.za> Message-ID: <1333496725.38.0.991817307688.issue14065@psf.upfronthosting.co.za> Stefan Krah added the comment: Just in case you missed it: The Windows buildbots fail to compile 14abfa27ff19: http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 02:01:42 2012 From: report at bugs.python.org (Roger Serwy) Date: Wed, 04 Apr 2012 00:01:42 +0000 Subject: [issue14440] Close background process if IDLE closes abnormally. In-Reply-To: <1333027712.59.0.103811521392.issue14440@psf.upfronthosting.co.za> Message-ID: <1333497702.04.0.422171473435.issue14440@psf.upfronthosting.co.za> Roger Serwy added the comment: Andrew, the reason the subprocess is not closing is due to a thread management problem. I found that a dummy thread handles cvar.wait() which is why the subprocess fails to terminate properly. If you change the tight loop in _getresponse to be: while myseq not in self.responses: print(threading.enumerate(), file=sys.__stderr__) sys.__stderr__.flush() cvar.wait(1) Then you'll get the following dumped to the terminal once a second: [<_DummyThread(Dummy-1, started daemon 139991862630176)>, ] The MainThread already stopped, but these two daemon threads don't terminate, which is strange. Is this a bug in itself? Polling the OS for the IDLE frontend process will give an indication to terminate the subprocess, but actually terminating the subprocess from within the subprocess is the main problem. Attached is a patch which takes a different approach to terminating the subprocess by using .shutdown instead. ---------- Added file: http://bugs.python.org/file25112/issue14440_rev2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 02:18:29 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Apr 2012 00:18:29 +0000 Subject: [issue14397] Use GetTickCount/GetTickCount64 instead of QueryPerformanceCounter for monotonic clock In-Reply-To: <1332585881.7.0.0863389959921.issue14397@psf.upfronthosting.co.za> Message-ID: <1333498709.3.0.904604274054.issue14397@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm closing this issue as a duplicate... of the PEP 418. See the python-dev mailing list for discussions on this PEP. ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 03:05:22 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 04 Apr 2012 01:05:22 +0000 Subject: [issue14486] Add some versionchanged notes in threading docs Message-ID: <1333501522.24.0.791616845298.issue14486@psf.upfronthosting.co.za> New submission from Nick Coghlan : A (very) minor irritation discovered today - the PEP 8 style names were added to the threading.Thread API in 2.6, but the only notice of this is up at the top of the module docs. Some embedded notices like: ..versionchanged:: 2.6 Added PEP 8 compliant interfaces. See note at top of page. might be helpful. ---------- assignee: docs at python components: Documentation keywords: easy messages: 157451 nosy: docs at python, ncoghlan priority: low severity: normal stage: needs patch status: open title: Add some versionchanged notes in threading docs type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 04:07:28 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Apr 2012 02:07:28 +0000 Subject: [issue14425] Improve handling of 'timeout' parameter default in urllib.urlopen In-Reply-To: <1332860558.06.0.334522792296.issue14425@psf.upfronthosting.co.za> Message-ID: <1333505248.13.0.827455866057.issue14425@psf.upfronthosting.co.za> R. David Murray added the comment: Well, it turns out that this design is intentional, because actually using the global socket timeout is deprecated (see issue 2451). (That is, the non-None default value of the timeout parameter is a backward compatibility hack.) So I'm closing this as invalid. Sorry for the confusion, and thanks for the patches, even though they didn't get used this time. (They did help me realize the issue was invalid though, because the tests didn't pass when I applied them!) I still don't like the doc artifact, but I can't think of a way to improve it given the nature of the API. ---------- nosy: +pitrou resolution: -> invalid stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 04:23:39 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 04 Apr 2012 02:23:39 +0000 Subject: [issue14487] Add pending() query method to Queue.Queue Message-ID: <1333506219.01.0.716621518629.issue14487@psf.upfronthosting.co.za> New submission from Nick Coghlan : The task management API in the Queue module doesn't let you check to see if there are any pending tasks still being processed. A pending() query API (analagous to empty() and full()) would resolve that problem. The use case is for a process that terminates when all current jobs are complete, but should immediately start processing any *new* jobs that arrive while waiting for the old ones. Using the current Queue.join() method would fail the second requirement (since the blocking calls means that no new jobs could be added while waiting for the old ones to finish). ---------- messages: 157453 nosy: ncoghlan priority: normal severity: normal status: open title: Add pending() query method to Queue.Queue _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 04:24:15 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 04 Apr 2012 02:24:15 +0000 Subject: [issue14487] Add pending() query method to Queue.Queue In-Reply-To: <1333506219.01.0.716621518629.issue14487@psf.upfronthosting.co.za> Message-ID: <1333506255.06.0.968071912483.issue14487@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- components: +Library (Lib) stage: -> needs patch type: -> enhancement versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 04:40:11 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 04 Apr 2012 02:40:11 +0000 Subject: [issue9634] Add timeout parameter to Queue.join() In-Reply-To: <1282153581.83.0.092560551276.issue9634@psf.upfronthosting.co.za> Message-ID: <1333507211.1.0.103312102962.issue9634@psf.upfronthosting.co.za> Nick Coghlan added the comment: I just created #14487 to request a documented API (Queue.pending()) that provides a formal mechanism for asking whether or not any jobs are still pending (analagous to the existing empty() and full() query methods). Specifically, what I have is a client process that is executed periodically, gathers up a set of tasks and uses a thread pool to submit them in parallel to a synchronous API. If all tasks complete with no new tasks being scheduled, then the client should terminate. However, if a new task arrives while any existing task is still in progress, then the client should submit it "immediately" (where, due to the time scales involved, "immediately" actually means "within the next few minutes" so I have plenty of scope to let the client block for a while instead of implementing a busy loop). So, a timeout on join() would actually fit my use case better than the pending() API I proposed in the other issue. The processing loop would then look something like: while have_tasks_to_process(): submit_tasks_to_queue() try: task_queue.join(timeout) except Pending: pass The advantage of having the timeout is that it would avoid the clumsy workarounds needed to avoid the busy loop created by the use of a query based approach. (Of course, I'm going to have to use the workaround anyway, since my client runs on Python 2.6, but still, I believe it meets the "concrete use case" criterion). >From a design aesthetic point of view, a pending() query API and a timeout on join() that throws a Pending exception would match the existing empty()/get()/Empty and full()/put()/Full API triples. ---------- nosy: +ncoghlan resolution: rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 04:41:23 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 04 Apr 2012 02:41:23 +0000 Subject: [issue14487] Add pending() query method to Queue.Queue In-Reply-To: <1333506219.01.0.716621518629.issue14487@psf.upfronthosting.co.za> Message-ID: <1333507283.77.0.99104738917.issue14487@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- resolution: -> duplicate status: open -> closed superseder: -> Add timeout parameter to Queue.join() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 04:42:46 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 04 Apr 2012 02:42:46 +0000 Subject: [issue9634] Add timeout parameter to Queue.join() In-Reply-To: <1282153581.83.0.092560551276.issue9634@psf.upfronthosting.co.za> Message-ID: <1333507366.88.0.991680647203.issue9634@psf.upfronthosting.co.za> Nick Coghlan added the comment: I killed off my new issue in favour of this one, since they're covering the same ground. ---------- versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 04:55:35 2012 From: report at bugs.python.org (Jeff McNeil) Date: Wed, 04 Apr 2012 02:55:35 +0000 Subject: [issue14487] Add pending() query method to Queue.Queue In-Reply-To: <1333506219.01.0.716621518629.issue14487@psf.upfronthosting.co.za> Message-ID: <1333508135.57.0.698062182346.issue14487@psf.upfronthosting.co.za> Jeff McNeil added the comment: I looked at doing this. The empty() and full() methods are marked with a disclaimer stating they're likely to be removed at some point? I'm curious, does just checking the value of .unfinished_tasks satisfy the requirement? It could still easily be non-zero even if the queue itself is empty, signifying work in progress. Another option might be to allow non-blocking use of join()? ---------- nosy: +mcjeff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 05:22:37 2012 From: report at bugs.python.org (Janice) Date: Wed, 04 Apr 2012 03:22:37 +0000 Subject: [issue14488] Can Message-ID: <1333509757.11.0.987059185448.issue14488@psf.upfronthosting.co.za> Changes by Janice : ---------- nosy: kiwii128 priority: normal severity: normal status: open title: Can _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 05:26:55 2012 From: report at bugs.python.org (Janice) Date: Wed, 04 Apr 2012 03:26:55 +0000 Subject: [issue14488] Can't install Python2.7.2 Message-ID: <1333510015.21.0.60972826548.issue14488@psf.upfronthosting.co.za> New submission from Janice : During the installation, an error occurred and I have no idea how to fix it. Please help!! The error says, An error occurred during the installation of assembly 'Microsoft.VC90.CRT,version="9.0.21022.8",publicKeyToken="1fc8b3b81e18e3b",processorArchitecture="x86",type="win32". Please help me~~ ---------- components: +Installation title: Can -> Can't install Python2.7.2 type: -> behavior versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 05:56:08 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 04 Apr 2012 03:56:08 +0000 Subject: [issue9634] Add timeout parameter to Queue.join() In-Reply-To: <1282153581.83.0.092560551276.issue9634@psf.upfronthosting.co.za> Message-ID: <1333511768.18.0.125428097694.issue9634@psf.upfronthosting.co.za> Nick Coghlan added the comment: The function below is the workaround I plan to use based on the undocumented-but-public Thread attributes that relate to the task queue (it's essentially just a combination of Queue.join() with the existing structure of the Queue.get() implementation): def join_queue(q, timeout=None): q.all_tasks_done.acquire() try: if timeout is None: while q.unfinished_tasks: self.all_tasks_done.wait() elif timeout < 0: raise ValueError("'timeout' must be a positive number") else: endtime = _time() + timeout while q.unfinished_tasks: remaining = endtime - _time() if remaining <= 0.0: raise Pending self.all_tasks_done.wait(remaining) finally: q.all_tasks_done.release() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 06:57:06 2012 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 04 Apr 2012 04:57:06 +0000 Subject: [issue14065] Element should support cyclic GC In-Reply-To: <1329755208.03.0.143933032526.issue14065@psf.upfronthosting.co.za> Message-ID: <1333515426.7.0.152610114133.issue14065@psf.upfronthosting.co.za> Eli Bendersky added the comment: Stefan, thanks. The windows bots were down when I was looking :-/ I'll work on a fix ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 07:13:07 2012 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 04 Apr 2012 05:13:07 +0000 Subject: [issue14065] Element should support cyclic GC In-Reply-To: <1329755208.03.0.143933032526.issue14065@psf.upfronthosting.co.za> Message-ID: <1333516387.84.0.984311624231.issue14065@psf.upfronthosting.co.za> Eli Bendersky added the comment: Attaching a patch that should fix the build - I don't have write access to commit where I am - will be able to commit it later today. ---------- Added file: http://bugs.python.org/file25113/issue14065_buildfix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 08:17:17 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 04 Apr 2012 06:17:17 +0000 Subject: [issue9634] Add timeout parameter to Queue.join() In-Reply-To: <1282153581.83.0.092560551276.issue9634@psf.upfronthosting.co.za> Message-ID: <1333520237.83.0.148437420931.issue9634@psf.upfronthosting.co.za> Nick Coghlan added the comment: The thread pool impl where I'm using this: http://git.fedorahosted.org/git/?p=pulpdist.git;a=blob;f=src/pulpdist/cli/thread_pool.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 08:24:39 2012 From: report at bugs.python.org (H Xu) Date: Wed, 04 Apr 2012 06:24:39 +0000 Subject: [issue14489] repr() function link on the built-in function documentation is incorrect Message-ID: <1333520679.63.0.90940412535.issue14489@psf.upfronthosting.co.za> New submission from H Xu : The `repr()` built-in function link in this page [ http://docs.python.org/library/functions.html ] should link to the built-in version of `repr()`. It should link to: http://docs.python.org/library/functions.html#repr However, it links to here: http://docs.python.org/library/repr.html#module-repr ---------- assignee: docs at python components: Documentation messages: 157462 nosy: H.Xu, docs at python priority: normal severity: normal status: open title: repr() function link on the built-in function documentation is incorrect versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 08:36:11 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 04 Apr 2012 06:36:11 +0000 Subject: [issue12723] Provide an API in tkSimpleDialog for defining custom validation functions In-Reply-To: <1312989791.6.0.177522419712.issue12723@psf.upfronthosting.co.za> Message-ID: <1333521371.05.0.367277535843.issue12723@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I think we have to reject this issue. Adding generic validation make sense, but adding just permanent check for non-empty string is wrong. ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 11:59:59 2012 From: report at bugs.python.org (Matej Cepl) Date: Wed, 04 Apr 2012 09:59:59 +0000 Subject: [issue8998] add crypto routines to stdlib In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za> Message-ID: <1333533599.93.0.905108768139.issue8998@psf.upfronthosting.co.za> Changes by Matej Cepl : ---------- nosy: +mcepl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 12:16:46 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 04 Apr 2012 10:16:46 +0000 Subject: [issue6181] Tkinter.Listbox several minor issues In-Reply-To: <1243977899.25.0.845872446641.issue6181@psf.upfronthosting.co.za> Message-ID: <1333534606.34.0.837675148051.issue6181@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 12:56:03 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 04 Apr 2012 10:56:03 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1333536963.09.0.877075927056.issue9141@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: I just noticed that PyTypeObjects have a gc slot already: inquiry tp_is_gc; /* For PyObject_IS_GC */ Now, this is used in only one place in 2.7, for type objects: return type->tp_flags & Py_TPFLAGS_HEAPTYPE; This is thus used to dynamically query if an object was allocated with a GC header or not, since static types cannot have this. Now, it would be perfectly possible to change the semantics of this function to return a bit flag, with bit 0 being the "has head" and bit 1 meaning "is collectable" This might simplify some stuff. Any thoughts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 13:21:02 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 04 Apr 2012 11:21:02 +0000 Subject: [issue14321] Do not run pgen during the build if files are up to date In-Reply-To: <1331831244.15.0.8026915878.issue14321@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 4e306c1a3c92 by Matthias Klose in branch 'default': Followup for issue #14321, remove references to Parser/pgen.stamp http://hg.python.org/cpython/rev/4e306c1a3c92 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 13:34:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 04 Apr 2012 11:34:05 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1333380073.05.0.0268479977575.issue13903@psf.upfronthosting.co.za> Message-ID: <1333538931.3503.3.camel@localhost.localdomain> Antoine Pitrou added the comment: > I'm not bothered by the regression in "silent_logging", > as it is a micro benchmark with a very short running time. I'm not concerned about the micro-benchmark itself but the fact that it might hint at a wider problem. Also, I don't get your remark about it running in a short time. Your patch AFAICT doesn't need any warm up period to exhibit any improvements. > Reducing the method-cache size from 2**10 to 2**9 allows the working > set to fit better in the cache. > This fixes the regression in "mako", but makes OO programs that use > few objects (such as richards) a bit slower. I don't think we should reduce the size of the method cache. 1024 is not a very large number, and might even be too small for complex OO programs. I also think that, apart from the dict storage changes, your patch should strive not to change any other tunables. Otherwise we're really comparing apples to oranges. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 13:45:22 2012 From: report at bugs.python.org (Popa Claudiu) Date: Wed, 04 Apr 2012 11:45:22 +0000 Subject: [issue14490] abitype.py wrong raise format Message-ID: <1333539922.74.0.14982794149.issue14490@psf.upfronthosting.co.za> New submission from Popa Claudiu : In Tools/abitype.py an exception is raised using the old format: raise Exception, '%s has no PyVarObject_HEAD_INIT' % name The attached patch fixes this problem. ---------- components: Demos and Tools files: abitype.patch keywords: patch messages: 157467 nosy: Popa.Claudiu priority: normal severity: normal status: open title: abitype.py wrong raise format type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25114/abitype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 13:52:13 2012 From: report at bugs.python.org (Matthias Klose) Date: Wed, 04 Apr 2012 11:52:13 +0000 Subject: [issue14321] Do not run pgen during the build if files are up to date In-Reply-To: <1331831244.15.0.8026915878.issue14321@psf.upfronthosting.co.za> Message-ID: <1333540333.7.0.888142966915.issue14321@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 13:55:51 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Apr 2012 11:55:51 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1333540551.71.0.135079009099.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: Patch version 5, updated to the last version of the PEP: - drop time.highres() - time.monotonic() is always monotonic but it not always available - add a test on time.monotonic() setting the system clock (jump backward wtih a delta of 1 hour) ---------- Added file: http://bugs.python.org/file25115/pep418-5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 13:57:36 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Apr 2012 11:57:36 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1333540656.72.0.65568464458.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: +#if defined(linux) || defined(__linux) || defined(__linux__) Hum, a better check should be done in configure and/or a macro like MS_WINDOWS should be added. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 13:58:26 2012 From: report at bugs.python.org (Popa Claudiu) Date: Wed, 04 Apr 2012 11:58:26 +0000 Subject: [issue14491] fixcid.py is using <> instead of != Message-ID: <1333540706.17.0.957403109352.issue14491@psf.upfronthosting.co.za> New submission from Popa Claudiu : Tools/fixcid.py uses <> instead of !=. The attached patched fixes this issue. ---------- components: Demos and Tools files: fixcid.patch keywords: patch messages: 157470 nosy: Popa.Claudiu priority: normal severity: normal status: open title: fixcid.py is using <> instead of != versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25116/fixcid.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 14:10:22 2012 From: report at bugs.python.org (Popa Claudiu) Date: Wed, 04 Apr 2012 12:10:22 +0000 Subject: [issue14492] pdeps.py has_key Message-ID: <1333541422.42.0.575169190211.issue14492@psf.upfronthosting.co.za> New submission from Popa Claudiu : Tools/pdeps.py is using has_key for a dictionary. The attached patch fixes this issue. ---------- files: pdeps.patch keywords: patch messages: 157471 nosy: Popa.Claudiu priority: normal severity: normal status: open title: pdeps.py has_key Added file: http://bugs.python.org/file25117/pdeps.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 14:10:33 2012 From: report at bugs.python.org (Popa Claudiu) Date: Wed, 04 Apr 2012 12:10:33 +0000 Subject: [issue14492] pdeps.py has_key In-Reply-To: <1333541422.42.0.575169190211.issue14492@psf.upfronthosting.co.za> Message-ID: <1333541433.08.0.854830339261.issue14492@psf.upfronthosting.co.za> Changes by Popa Claudiu : ---------- components: +Demos and Tools versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 14:17:20 2012 From: report at bugs.python.org (Matthias Klose) Date: Wed, 04 Apr 2012 12:17:20 +0000 Subject: [issue14493] use gvfs-open/xdg-open in Lib/webbrowser.py Message-ID: <1333541840.96.0.231691916093.issue14493@psf.upfronthosting.co.za> New submission from Matthias Klose : [forwarded from https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/971311] The webbrowser.py is using gnome-open. This is no longer supported by gnome, instead they use gvfs-open. The attached patch adds support for this and will also use xdg-open if available as this is meant to be the cross desktop tool to use for this kind of task, see http://portland.freedesktop.org/wiki/ ---------- assignee: doko components: Library (Lib) keywords: patch messages: 157472 nosy: doko priority: normal severity: normal status: open title: use gvfs-open/xdg-open in Lib/webbrowser.py versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 14:19:11 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 04 Apr 2012 12:19:11 +0000 Subject: [issue14493] use gvfs-open/xdg-open in Lib/webbrowser.py In-Reply-To: <1333541840.96.0.231691916093.issue14493@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 70c58903b52e by Matthias Klose in branch 'default': - Issue #14493: Use gvfs-open/xdg-open in Lib/webbrowser.py. http://hg.python.org/cpython/rev/70c58903b52e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 14:53:06 2012 From: report at bugs.python.org (Sven Marnach) Date: Wed, 04 Apr 2012 12:53:06 +0000 Subject: [issue14494] __future__.py and its documentation claim absolute imports became mandatory in 2.7, but they didn't Message-ID: <1333543986.45.0.920300905324.issue14494@psf.upfronthosting.co.za> New submission from Sven Marnach : As has been pointed out before on python-dev [1], the mandatory version of '__future__.absolute_import' does not match reality. In Python 2.7, absolute imports are not the default. [1]: http://article.gmane.org/gmane.comp.python.devel/125446 The attached patch should fix the documentation and Lib/__future__.py. I set the mandatory version to (3, 0, 0, "alpha", 0), in accordance with other features that became mandatory in Py3k, though there never was a 3.0a0 release. I double-checked that absolute imports already were the default in 3.0a1. The patch should probably be applied to all branches. ---------- assignee: docs at python components: Documentation, Library (Lib) files: absolute_import.patch keywords: patch messages: 157474 nosy: docs at python, smarnach priority: normal severity: normal status: open title: __future__.py and its documentation claim absolute imports became mandatory in 2.7, but they didn't type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25118/absolute_import.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 15:12:32 2012 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 04 Apr 2012 13:12:32 +0000 Subject: [issue14065] Element should support cyclic GC In-Reply-To: <1329755208.03.0.143933032526.issue14065@psf.upfronthosting.co.za> Message-ID: <1333545152.01.0.989503053828.issue14065@psf.upfronthosting.co.za> Eli Bendersky added the comment: Fix committed - Windows bots now compile successfully. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 15:17:29 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 04 Apr 2012 13:17:29 +0000 Subject: [issue11734] Add half-float (16-bit) support to struct module In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za> Message-ID: <1333545449.14.0.665155041742.issue11734@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Tests passed, looks good. Code is also looks ok. Documentation is out-of-date. Patch cannot be applied to struct.rst from default branch. Compilation generates warning messages on gcc 4.6.1: /home/andrew/projects/py3k/Modules/_struct.c: In function ?nu_halffloat?: /home/andrew/projects/py3k/Modules/_struct.c:489:5: warning: pointer targets in passing argument 1 of ?_PyFloat_Unpack2? differ in signedness [-Wpointer-sign] Include/floatobject.h:108:20: note: expected ?const unsigned char *? but argument is of type ?const char *? /home/andrew/projects/py3k/Modules/_struct.c: In function ?np_halffloat?: /home/andrew/projects/py3k/Modules/_struct.c:712:5: warning: pointer targets in passing argument 2 of ?_PyFloat_Pack2? differ in signedness [-Wpointer-sign] Include/floatobject.h:87:17: note: expected ?unsigned char *? but argument is of type ?char *? After fixing warnings and structure.rst I like to see that patch in standard library. ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 15:46:04 2012 From: report at bugs.python.org (Mark Shannon) Date: Wed, 04 Apr 2012 13:46:04 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1333538931.3503.3.camel@localhost.localdomain> Message-ID: <4F7C509D.2010809@hotpy.org> Mark Shannon added the comment: Antoine Pitrou wrote: > Antoine Pitrou added the comment: > >> I'm not bothered by the regression in "silent_logging", >> as it is a micro benchmark with a very short running time. > > I'm not concerned about the micro-benchmark itself but the fact that it > might hint at a wider problem. Or it might not. Micro-benchmarks produce micro-optimisations. That's why I dislike them. > Also, I don't get your remark about it running in a short time. Your > patch AFAICT doesn't need any warm up period to exhibit any > improvements. What I mean is that the runtime is so short, no one would notice any change, so who cares? > >> Reducing the method-cache size from 2**10 to 2**9 allows the working >> set to fit better in the cache. >> This fixes the regression in "mako", but makes OO programs that use >> few objects (such as richards) a bit slower. > > I don't think we should reduce the size of the method cache. 1024 is not > a very large number, and might even be too small for complex OO > programs. "not very large" or "too small", by what metric? The optimum size (for speed) of the method cache depends on the size of hardware data cache, the complexity of the program, and many other factors. Attempt to reason about it are pretty much futile. Empiricism is the only way to go. > > I also think that, apart from the dict storage changes, your patch > should strive not to change any other tunables. Otherwise we're really > comparing apples to oranges. If the implementation changes, shouldn't the tunable parameters be retuned? Cheers, Mark. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 15:51:39 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Apr 2012 13:51:39 +0000 Subject: [issue14493] use gvfs-open/xdg-open in Lib/webbrowser.py In-Reply-To: <1333541840.96.0.231691916093.issue14493@psf.upfronthosting.co.za> Message-ID: <1333547499.58.0.838978873494.issue14493@psf.upfronthosting.co.za> R. David Murray added the comment: If gvfs is preferred, should its if block come second, or perhaps those two should be an if/elif block? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 16:06:37 2012 From: report at bugs.python.org (Matthias Klose) Date: Wed, 04 Apr 2012 14:06:37 +0000 Subject: [issue14493] use gvfs-open/xdg-open in Lib/webbrowser.py In-Reply-To: <1333541840.96.0.231691916093.issue14493@psf.upfronthosting.co.za> Message-ID: <1333548397.39.0.205608996372.issue14493@psf.upfronthosting.co.za> Matthias Klose added the comment: I don't think so. the register calls append to the list, don't overwrite it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 16:19:03 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Apr 2012 14:19:03 +0000 Subject: [issue14489] repr() function link on the built-in function documentation is incorrect In-Reply-To: <1333520679.63.0.90940412535.issue14489@psf.upfronthosting.co.za> Message-ID: <1333549143.35.0.708373380599.issue14489@psf.upfronthosting.co.za> R. David Murray added the comment: This is only a problem in the 2.7 docs. I tried adding a .. py:currentmodule:: builtins directive to the page, hoping that would make all unqualified links local, but it didn't work. I think the fix will require someone with more Sphinx-foo than I have. ---------- nosy: +r.david.murray type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 16:25:58 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Apr 2012 14:25:58 +0000 Subject: [issue14490] abitype.py wrong raise format In-Reply-To: <1333539922.74.0.14982794149.issue14490@psf.upfronthosting.co.za> Message-ID: <1333549558.85.0.505189870977.issue14490@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the patch. Do you have an interest in trying your hand at writing a test for this to go into Lib/test/test_tools.py? ---------- nosy: +r.david.murray stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 16:26:53 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Apr 2012 14:26:53 +0000 Subject: [issue14491] fixcid.py is using <> instead of != In-Reply-To: <1333540706.17.0.957403109352.issue14491@psf.upfronthosting.co.za> Message-ID: <1333549613.45.0.175373586813.issue14491@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 16:28:11 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Apr 2012 14:28:11 +0000 Subject: [issue14492] pdeps.py has_key In-Reply-To: <1333541422.42.0.575169190211.issue14492@psf.upfronthosting.co.za> Message-ID: <1333549691.86.0.242945770921.issue14492@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> test needed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 16:29:12 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Apr 2012 14:29:12 +0000 Subject: [issue14494] __future__.py and its documentation claim absolute imports became mandatory in 2.7, but they didn't In-Reply-To: <1333543986.45.0.920300905324.issue14494@psf.upfronthosting.co.za> Message-ID: <1333549752.26.0.250899685585.issue14494@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> patch review versions: -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 16:33:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 04 Apr 2012 14:33:05 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <4F7C509D.2010809@hotpy.org> Message-ID: <1333549670.3401.3.camel@localhost.localdomain> Antoine Pitrou added the comment: > > Also, I don't get your remark about it running in a short time. Your > > patch AFAICT doesn't need any warm up period to exhibit any > > improvements. > > What I mean is that the runtime is so short, no one would notice any > change, so who cares? None of the benchmarks used here are real-world workloads, so you might as well claim that they are all irrelevant. But then we'll have a hard time assessing the consequences of your patch. > > I don't think we should reduce the size of the method cache. 1024 is not > > a very large number, and might even be too small for complex OO > > programs. > > "not very large" or "too small", by what metric? By the metric of the number of classes and methods in a complex OO application (for example something based on Twisted or SQLAlchemy). > > I also think that, apart from the dict storage changes, your patch > > should strive not to change any other tunables. Otherwise we're really > > comparing apples to oranges. > > If the implementation changes, shouldn't the tunable parameters be retuned? Only if there's a reasoning behind it. Perhaps the retuning would have given the same results without the rest of your patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 16:59:24 2012 From: report at bugs.python.org (Zachary Ware) Date: Wed, 04 Apr 2012 14:59:24 +0000 Subject: [issue14495] Minor typo in tkinter.ttk.Treeview.exists docstring Message-ID: <1333551564.21.0.378637170829.issue14495@psf.upfronthosting.co.za> New submission from Zachary Ware : I found a very very minor typo in the docstring of tkinter.ttk.Treeview.exists: "Returns True if the specified item is present in the *three*" I assume that should be "tree". The attached patch removes the "h". Thanks! --Note: This is the first time I've done anything on bugs.python.org, so if there's anything I've done wrong or could do better, please let me know! Thanks, Zach ---------- assignee: docs at python components: Documentation files: Treeview.exists docstring.diff keywords: patch messages: 157483 nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, gpolo, zach.ware priority: normal severity: normal status: open title: Minor typo in tkinter.ttk.Treeview.exists docstring versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25119/Treeview.exists docstring.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 17:02:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 04 Apr 2012 15:02:42 +0000 Subject: [issue11734] Add half-float (16-bit) support to struct module In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za> Message-ID: <1333551762.77.0.113481523338.issue11734@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Given than there is no native "half float" in C (AFAIK), does it make sense to have a native variant of half floats? Also: + {'e', sizeof(short), SHORT_ALIGN, nu_halffloat, np_halffloat}, Shouldn't it be 2 rather than sizeof(short)? And why SHORT_ALIGN? Other comments: - in the tests, please remove the commented out print() calls - in the tests, I don't understand why some examples are commented out; you should explain why (add a comment) - you can add the "import math" at the top-level, rather than in the test method - in the doc, you need a "versionchanged" or "versionadded" tag to specify that half-float support was added in 3.3 I'll let others review the numerical code, if necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 17:07:56 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Apr 2012 15:07:56 +0000 Subject: [issue14490] abitype.py wrong raise format In-Reply-To: <1333539922.74.0.14982794149.issue14490@psf.upfronthosting.co.za> Message-ID: <1333552076.54.0.294729745999.issue14490@psf.upfronthosting.co.za> R. David Murray added the comment: Nevermind, it occurred to me that what we really need is a 'test_sundry' style test for the tools. Here's a patch that adds that. I'll apply it after I fix the other bugs it reveals (which include the other two you pointed out as a subset...). ---------- Added file: http://bugs.python.org/file25120/tools_sundry.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 17:11:53 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Apr 2012 15:11:53 +0000 Subject: [issue14493] use gvfs-open/xdg-open in Lib/webbrowser.py In-Reply-To: <1333541840.96.0.231691916093.issue14493@psf.upfronthosting.co.za> Message-ID: <1333552313.05.0.279370146322.issue14493@psf.upfronthosting.co.za> R. David Murray added the comment: OK, sounds fine. Shall we close this as fixed then? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 17:16:01 2012 From: report at bugs.python.org (Popa Claudiu) Date: Wed, 04 Apr 2012 15:16:01 +0000 Subject: [issue14491] fixcid.py is using <> instead of != In-Reply-To: <1333540706.17.0.957403109352.issue14491@psf.upfronthosting.co.za> Message-ID: <1333552561.76.0.420211025535.issue14491@psf.upfronthosting.co.za> Popa Claudiu added the comment: Hello. I added a test for fixcid.py regression. ---------- nosy: +r.david.murray Added file: http://bugs.python.org/file25121/fixcid_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 17:17:47 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 04 Apr 2012 15:17:47 +0000 Subject: [issue11734] Add half-float (16-bit) support to struct module In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za> Message-ID: <1333552667.44.0.655510518384.issue11734@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I used half-float in GPU programming and from my perspective it was just native. There are no half-float in C, right. But there are half-floats used in NVIDIA libraries for example and I like to think used format is native and platform-depended in general. Correct me if I'm mistaking. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 17:19:25 2012 From: report at bugs.python.org (Popa Claudiu) Date: Wed, 04 Apr 2012 15:19:25 +0000 Subject: [issue14490] abitype.py wrong raise format In-Reply-To: <1333539922.74.0.14982794149.issue14490@psf.upfronthosting.co.za> Message-ID: <1333552765.36.0.26005007197.issue14490@psf.upfronthosting.co.za> Popa Claudiu added the comment: Oh, ok then. That makes the last file added in 14491 irrelevant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 17:25:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 04 Apr 2012 15:25:35 +0000 Subject: [issue11734] Add half-float (16-bit) support to struct module In-Reply-To: <1333552667.44.0.655510518384.issue11734@psf.upfronthosting.co.za> Message-ID: <1333552821.3401.7.camel@localhost.localdomain> Antoine Pitrou added the comment: > I used half-float in GPU programming and from my perspective it was > just native. There are no half-float in C, right. But there are > half-floats used in NVIDIA libraries for example and I like to think > used format is native and platform-depended in general. Correct me if > I'm mistaking. By "native", the struct module means there is a corresponding C type and therefore corresponding rules for size and alignment, as implemented by the C compiler. GPU structure layout is another matter, as the C compiler doesn't target that (not in a standard setup, anyway). Apparently the patch takes the stance that the corresponding C type (for size and alignment) is "short", which I guess is an acceptable compromise, but still a bit weird. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 17:32:27 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 04 Apr 2012 15:32:27 +0000 Subject: [issue11734] Add half-float (16-bit) support to struct module In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za> Message-ID: <1333553547.33.0.0124013163721.issue11734@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Antoine, agree with you after explanation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 17:46:51 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 04 Apr 2012 15:46:51 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1333554411.76.0.793136425051.issue9141@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > This might simplify some stuff. Any thoughts? I think you should float it on python-dev. ---------- versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 18:40:34 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 04 Apr 2012 16:40:34 +0000 Subject: [issue1053687] PyOS_InputHook not called in IDLE subprocess Message-ID: <1333557634.03.0.530318904402.issue1053687@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Closing as wan't fix. ---------- assignee: kbk -> asvetlov resolution: -> wont fix stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 19:33:00 2012 From: report at bugs.python.org (Popa Claudiu) Date: Wed, 04 Apr 2012 17:33:00 +0000 Subject: [issue14496] Wrong name in idlelib/tabbedpages.py Message-ID: <1333560780.31.0.2464741525.issue14496@psf.upfronthosting.co.za> New submission from Popa Claudiu : In the file from the subject, page_name was used instead of tab_name, increasing the chances of a NameError exception. I didn't find any tests for IDLE, so there are no tests attached. ---------- components: IDLE files: idlelib.patch keywords: patch messages: 157494 nosy: Popa.Claudiu priority: normal severity: normal status: open title: Wrong name in idlelib/tabbedpages.py type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25122/idlelib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 20:07:08 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 04 Apr 2012 18:07:08 +0000 Subject: [issue14496] Wrong name in idlelib/tabbedpages.py In-Reply-To: <1333560780.31.0.2464741525.issue14496@psf.upfronthosting.co.za> Message-ID: <1333562828.54.0.803128510814.issue14496@psf.upfronthosting.co.za> Andrew Svetlov added the comment: The patch looks good. Can you describe manual steps to reproduce the issue? ---------- assignee: -> asvetlov nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 20:17:24 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 04 Apr 2012 18:17:24 +0000 Subject: [issue14495] Minor typo in tkinter.ttk.Treeview.exists docstring In-Reply-To: <1333551564.21.0.378637170829.issue14495@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 45287f2799f5 by Georg Brandl in branch '3.2': Closes #14495: fix typo. http://hg.python.org/cpython/rev/45287f2799f5 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 20:44:23 2012 From: report at bugs.python.org (Popa Claudiu) Date: Wed, 04 Apr 2012 18:44:23 +0000 Subject: [issue14496] Wrong name in idlelib/tabbedpages.py In-Reply-To: <1333560780.31.0.2464741525.issue14496@psf.upfronthosting.co.za> Message-ID: <1333565063.85.0.981672607434.issue14496@psf.upfronthosting.co.za> Popa Claudiu added the comment: Yes. 1. inherit from TabbedPageSet 2. pass tabs keyword to the internal TabSet instance 3. when the GUI started, enter a page with the same name found in tabs list. NameError will be raised at this point. I'm curios if this script is used anywhere, I couldn't find any reference to it in the source code. ---------- Added file: http://bugs.python.org/file25123/test_tabbedpages.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 21:30:15 2012 From: report at bugs.python.org (moijes12) Date: Wed, 04 Apr 2012 19:30:15 +0000 Subject: [issue634412] RFC 2112 in email package Message-ID: <1333567815.02.0.0145526044638.issue634412@psf.upfronthosting.co.za> moijes12 added the comment: Is this still open for someone to work on? ---------- nosy: +moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 21:34:59 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Apr 2012 19:34:59 +0000 Subject: [issue14490] abitype.py wrong raise format In-Reply-To: <1333539922.74.0.14982794149.issue14490@psf.upfronthosting.co.za> Message-ID: <1333568099.86.0.103022046519.issue14490@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Hmm. I came across this error yesterday in the tests, when broke utf-16 decoder. The error was introduced in the module atexit. Until it all tests passed successfully, and this branch will not run. A simple search find -name '*.py' -exec egrep '\braise +\w+[^(]*,' '{}' + showed more than a thousand of problem lines. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 21:47:09 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 04 Apr 2012 19:47:09 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1333568829.41.0.734378082091.issue13903@psf.upfronthosting.co.za> Raymond Hettinger added the comment: [Antoine] >I also think that, apart from the dict storage changes, > your patch should strive not to change any other tunables. I agree. Please keep the patch focused on the single task, the shared keys. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 22:30:36 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Apr 2012 20:30:36 +0000 Subject: [issue14497] Invalid syntax Python files in Python sources tree Message-ID: <1333571436.48.0.541559960271.issue14497@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : I was very surprised to find in Python source code files that are not compatible with Python3. It turns out that this is not an exception, such files very much (see scanner script in attachment). Surely for many years no one had reached his hands run 2to3? These files need to be or to correct, or throw (when nobody needs them). Python 3.2 detects significantly less invalid syntax files. But Python 3.3 has become more severe. ---------- assignee: ronaldoussoren components: 2to3 (2.x to 3.x conversion tool), Demos and Tools, Library (Lib), Macintosh, Tests, Tkinter, Windows files: scanpy.py messages: 157501 nosy: ronaldoussoren, storchaka priority: normal severity: normal status: open title: Invalid syntax Python files in Python sources tree type: compile error versions: Python 3.3 Added file: http://bugs.python.org/file25124/scanpy.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 22:36:22 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Apr 2012 20:36:22 +0000 Subject: [issue14497] Invalid syntax Python files in Python sources tree In-Reply-To: <1333571436.48.0.541559960271.issue14497@psf.upfronthosting.co.za> Message-ID: <1333571782.1.0.782380985797.issue14497@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issues 14490, 14491, and 14492. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 22:38:14 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 04 Apr 2012 20:38:14 +0000 Subject: [issue14497] Invalid syntax Python files in Python sources tree In-Reply-To: <1333571436.48.0.541559960271.issue14497@psf.upfronthosting.co.za> Message-ID: <1333571894.4.0.383439851112.issue14497@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file25125/invalid.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 22:48:13 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Apr 2012 20:48:13 +0000 Subject: [issue14497] Invalid syntax Python files in Python sources tree In-Reply-To: <1333571436.48.0.541559960271.issue14497@psf.upfronthosting.co.za> Message-ID: <1333572493.42.0.328344782534.issue14497@psf.upfronthosting.co.za> R. David Murray added the comment: Some of these at least are intentional. There are test files (especially in 2to3!) that use python2 syntax, and test files that have specially crated syntax errors in them. Sphinx at one point was using Python2, I'm not sure if it has been upgraded to 3 yet or not. I'm sure there are also files that just haven't been checked and updated, such as the ones in Tools/scripts(*). So an audit is definitely in order. (*) I thought someone *had* done an audit of those, but the evidence says otherwise. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 22:49:28 2012 From: report at bugs.python.org (Matthew Scott) Date: Wed, 04 Apr 2012 20:49:28 +0000 Subject: [issue14498] Python 3.x distutils.util.get_platform returns incorrect value using Mac OSX 10.7 Message-ID: <1333572568.76.0.187073077098.issue14498@psf.upfronthosting.co.za> New submission from Matthew Scott : Using Python 3.2.2 and Python 3.3.0a2 (installed via 64-bit installers in official DMGs on python.org), 'distutils.util.get_platform()' returns an incorrect OS version when running on Mac OSX 10.7. Using Python 2.6.7, and Python 2.7.1 (the versions included with Mac OSX), the output indicates 'macosx-10.7' correctly. > for version in 2.6 2.7 3.2 3.3; do python${version} -c "from __future__ import print_function;import distutils.util,sys;print(sys.version.split()[0],distutils.util.get_platform())"; done 2.6.7 macosx-10.7-intel 2.7.1 macosx-10.7-intel 3.2.2 macosx-10.6-intel 3.3.0a2 macosx-10.6-intel Some packages make use of this in their setup.py to determine the proper location of libraries. For example, the 'readline' distribution's setup.py does so here: https://github.com/ludwigschwardt/python-readline/blob/6f0e801fa1632fcbb0e005eb9709aaa6051a0f28/setup.py#L33 It fails due to the incorrect assumption that it's running on 10.6 instead of 10.7. Excerpt from "python setup.py bdist_egg": building 'readline' extension Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/MacOSX10.6.sdk Please check your Xcode installation gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -isysroot /Developer/SDKs/MacOSX10.6.sdk -DHAVE_RL_CALLBACK -DHAVE_RL_CATCH_SIGNAL -DHAVE_RL_COMPLETION_APPEND_CHARACTER -DHAVE_RL_COMPLETION_DISPLAY_MATCHES_HOOK -DHAVE_RL_COMPLETION_MATCHES -DHAVE_RL_COMPLETION_SUPPRESS_APPEND -DHAVE_RL_PRE_INPUT_HOOK -I. -I/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m -c Modules/3.x/readline.c -o build/temp.macosx-10.6-intel-3.2/Modules/3.x/readline.o -Wno-strict-prototypes -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -arch x86_64 In file included from Modules/3.x/readline.c:8: /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/Python.h:11:20: error: limits.h: No such file or directory ---------- assignee: eric.araujo components: Distutils, Library (Lib), Macintosh messages: 157504 nosy: Matthew.Scott, eric.araujo, tarek priority: normal severity: normal status: open title: Python 3.x distutils.util.get_platform returns incorrect value using Mac OSX 10.7 type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 23:02:16 2012 From: report at bugs.python.org (Matthew Scott) Date: Wed, 04 Apr 2012 21:02:16 +0000 Subject: [issue14498] Python 3.x distutils.util.get_platform returns incorrect value using Mac OSX 10.7 In-Reply-To: <1333572568.76.0.187073077098.issue14498@psf.upfronthosting.co.za> Message-ID: <1333573336.54.0.79509595022.issue14498@psf.upfronthosting.co.za> Matthew Scott added the comment: In the cases of both Python 3.x and 2.x, get_platform() is deriving information about the version of OSX from the 'MACOSX_DEPLOYMENT_TARGET' dictionary returned by distutils.sysconfig.get_config_vars(). Using Python 3.2.2: In [1]: import distutils.sysconfig;distutils.sysconfig.get_config_vars()['MACOSX_DEPLOYMENT_TARGET'] Out[1]: '10.6' Using Python 2.7.1: In [1]: import distutils.sysconfig;distutils.sysconfig.get_config_vars()['MACOSX_DEPLOYMENT_TARGET'] Out[1]: '10.7' While the deployment target seems like a useful source of information, it does not seem to be accurate enough to "Return a string that identifies the current platform" as the docstring for distutils.util.get_platform() suggests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 23:06:32 2012 From: report at bugs.python.org (d9pouces) Date: Wed, 04 Apr 2012 21:06:32 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za> Message-ID: <1333573592.48.0.0909192464725.issue14455@psf.upfronthosting.co.za> d9pouces added the comment: storchaka > I'm trying to take care of your remarks. So, I'm working on a more object-oriented code, with both write and read functions. I just need to write some test cases. IMHO, we should add a new parameter to the writePlist function, to allow the use of the binary or the json format of plist files instead of the default XML one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 23:10:30 2012 From: report at bugs.python.org (Matthew Scott) Date: Wed, 04 Apr 2012 21:10:30 +0000 Subject: [issue14498] Python 3.x distutils.util.get_platform returns incorrect value using Mac OSX 10.7 In-Reply-To: <1333572568.76.0.187073077098.issue14498@psf.upfronthosting.co.za> Message-ID: <1333573830.95.0.550472267307.issue14498@psf.upfronthosting.co.za> Matthew Scott added the comment: Interestingly, the 2.x series allowed an os.environ override for the MACOSX_DEPLOYMENT_TARGET value, while the 3.x series did away with that, as a result of http://bugs.python.org/issue9516 > for version in 2.6 2.7 3.2 3.3; do MACOSX_DEPLOYMENT_TARGET=10.42 python${version} -c "from __future__ import print_function;import distutils.util,sys;print(sys.version.split()[0],distutils.util.get_platform())"; done 2.6.7 macosx-10.42-intel 2.7.1 macosx-10.42-intel 3.2.2 macosx-10.6-intel 3.3.0a2 macosx-10.6-intel ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 23:10:57 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 04 Apr 2012 21:10:57 +0000 Subject: [issue634412] RFC 2112 in email package Message-ID: <1333573857.07.0.852279752957.issue634412@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, that's why its status is still "open" :) As far as I know no one is actively working on it (email issues are all assigned to me so I can keep track of them, not because I'm actively working on all of them). At this point I haven't made any significant modifications to the way mime parts are handled in email6, so any development work you do should be valid whether you work against 3.3 trunk or the email6 feature branch. Joining the email-sig mailing list and discussing this there might also be helpful. Thank you for your interest! ---------- components: +Library (Lib) -Interpreter Core _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 23:50:51 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 04 Apr 2012 21:50:51 +0000 Subject: [issue14498] Python 3.x distutils.util.get_platform returns incorrect value using Mac OSX 10.7 In-Reply-To: <1333572568.76.0.187073077098.issue14498@psf.upfronthosting.co.za> Message-ID: <1333576251.49.0.873231625871.issue14498@psf.upfronthosting.co.za> Ned Deily added the comment: For OS X builds, the value returned in get_platform() is not intended to indicate what OS version the Python instance is running on. Rather, it indicates which ABI version was used to build the Python in use so that Distutils can use the same ABI for building C extension modules. The ABI is determined by the value of MACOSX_DEPLOYMENT_TARGET at build time. In this case, a value of "macosx_10.6-intel" means the resulting executables and object files are a universal build with both 32-bit (i386) and 64-bit (x64_64) Intel architectures and can run on Mac OS X 10.6 and higher. The reason the Apple-supplied system Pythons have a value of 10.7 is that they are built with a deployment target of 10.7; they have no need to run on earlier version of OS X. The issue with the readline extension build you cite is the error "Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/MacOSX10.6.sdk". Chances are you are using the most recent Xcode release (4.3.x) from Apple which unfortunately moved the location of the SDKs from /Developer, which now no longer is used by Xcode, to within the Xcode.app bundle itself, now located in /Applications. A workaround for Xcode 4.3 is to install a symlink to the old location: sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer /Developer ---------- nosy: +ned.deily resolution: -> rejected stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 4 23:55:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 04 Apr 2012 21:55:06 +0000 Subject: [issue9634] Add timeout parameter to Queue.join() In-Reply-To: <1282153581.83.0.092560551276.issue9634@psf.upfronthosting.co.za> Message-ID: <1333576506.95.0.836654749349.issue9634@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Nick, why don't you submit your "workaround" as a patch to Queue.join()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 00:01:40 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 04 Apr 2012 22:01:40 +0000 Subject: [issue14499] Extension module builds fail with Xcode 4.3 on OS X 10.7 due to SDK move Message-ID: <1333576900.91.0.0583021085072.issue14499@psf.upfronthosting.co.za> New submission from Ned Deily : With the release of Xcode 4.3 for OS X 10.7, Apple has moved the location of the OS X SDKs from their long-time path of /Developer to within the new Xcode.app bundle itself. This breaks the building of extension modules with any of Distutils or packaging/Distutils2 when Python was built as as universal build with an SDK in the former location, as is the case with the python.org installers. A workaround is to either leave the old /Developer directory in place when upgrading to Xcode 4.3 or to install a symlink to the new location: sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer /Developer ---------- assignee: ned.deily components: Distutils, Macintosh messages: 157511 nosy: ned.deily, tarek priority: critical severity: normal stage: needs patch status: open title: Extension module builds fail with Xcode 4.3 on OS X 10.7 due to SDK move versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 00:03:40 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 04 Apr 2012 22:03:40 +0000 Subject: [issue14498] Python 3.x distutils.util.get_platform returns incorrect value using Mac OSX 10.7 In-Reply-To: <1333572568.76.0.187073077098.issue14498@psf.upfronthosting.co.za> Message-ID: <1333577020.72.0.62862699645.issue14498@psf.upfronthosting.co.za> Ned Deily added the comment: BTW, Issue14499 is now open to track the Xcode 4.3 SDK problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 00:06:15 2012 From: report at bugs.python.org (Matthew Scott) Date: Wed, 04 Apr 2012 22:06:15 +0000 Subject: [issue14499] Extension module builds fail with Xcode 4.3 on OS X 10.7 due to SDK move In-Reply-To: <1333576900.91.0.0583021085072.issue14499@psf.upfronthosting.co.za> Message-ID: <1333577175.78.0.753380255017.issue14499@psf.upfronthosting.co.za> Changes by Matthew Scott : ---------- nosy: +Matthew.Scott _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 00:07:15 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Apr 2012 22:07:15 +0000 Subject: [issue14318] clarify "may not" in time.steady docs In-Reply-To: <1331829668.71.0.947018206764.issue14318@psf.upfronthosting.co.za> Message-ID: <1333577235.89.0.519207373712.issue14318@psf.upfronthosting.co.za> STINNER Victor added the comment: I close this issue as a duplicate because it is now discussed in the PEP 418 and this PEP is going to change the new time functions (time.highres and time.monotonic/steady). ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 00:13:14 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 04 Apr 2012 22:13:14 +0000 Subject: [issue14500] test_importlib fails in refleak mode Message-ID: <1333577594.41.0.849099540387.issue14500@psf.upfronthosting.co.za> New submission from Antoine Pitrou : $ ./python -m test -R 3:2 test_importlib [1/1] test_importlib beginning 5 repetitions 12345 test test_importlib failed -- Traceback (most recent call last): File "/home/antoine/cpython/default/Lib/importlib/test/import_/test_packages.py", line 41, in test_module_not_package_but_side_effects submodule = import_util.import_(subname) File "/home/antoine/cpython/default/Lib/importlib/test/import_/util.py", line 15, in import_ return importlib.__import__(*args, **kwargs) File "/home/antoine/cpython/default/Lib/importlib/_bootstrap.py", line 1046, in __import__ return sys.modules[name.partition('.')[0]] KeyError: 'mod' ---------- assignee: brett.cannon components: Library (Lib), Tests messages: 157514 nosy: brett.cannon, pitrou priority: normal severity: normal stage: needs patch status: open title: test_importlib fails in refleak mode type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 00:28:48 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 04 Apr 2012 22:28:48 +0000 Subject: [issue14497] Invalid syntax Python files in Python sources tree In-Reply-To: <1333571436.48.0.541559960271.issue14497@psf.upfronthosting.co.za> Message-ID: <1333578528.63.0.235240173587.issue14497@psf.upfronthosting.co.za> Ned Deily added the comment: There was some related work on this in the earlier Demo clean up issue (Issue7962) and the still open "make altnstall" shebang line cleanup (Issue10318). But I'm confused. From the list of files you show in invalid.txt appear to be from a Python 2 source directory not a Python 3 one. Many (most?) of the files in your list no longer exist in Python 3. What problem are you trying to solve here? ---------- assignee: ronaldoussoren -> nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 00:33:02 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Apr 2012 22:33:02 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1333578782.61.0.568622342818.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: Version 6: simplify the code handling GetTickCounter() integer overflow. We don't need a has_last_ticks variable. ---------- Added file: http://bugs.python.org/file25126/pep418-6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 00:33:09 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Apr 2012 22:33:09 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1333578789.09.0.0523025192946.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25108/pep418-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 00:33:10 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Apr 2012 22:33:10 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1333578790.19.0.103637586207.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25115/pep418-5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 01:02:39 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Apr 2012 23:02:39 +0000 Subject: [issue14386] Expose dict_proxy internal type as types.MappingViewType In-Reply-To: <1332381004.13.0.167648412562.issue14386@psf.upfronthosting.co.za> Message-ID: <1333580559.8.0.852095028843.issue14386@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Expose dictproxy as a public type -> Expose dict_proxy internal type as types.MappingViewType _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 01:05:13 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Apr 2012 23:05:13 +0000 Subject: [issue14386] Expose dict_proxy internal type as types.MappingViewType In-Reply-To: <1332381004.13.0.167648412562.issue14386@psf.upfronthosting.co.za> Message-ID: <1333580713.67.0.849714043697.issue14386@psf.upfronthosting.co.za> STINNER Victor added the comment: mappingproxy-5.patch is ready for a review. msg157036 contains a summary except that types.MappingViewType is now called types.MappingProxyType. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 01:06:52 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 04 Apr 2012 23:06:52 +0000 Subject: [issue9634] Add timeout parameter to Queue.join() In-Reply-To: <1282153581.83.0.092560551276.issue9634@psf.upfronthosting.co.za> Message-ID: <1333580812.72.0.283711006359.issue9634@psf.upfronthosting.co.za> Nick Coghlan added the comment: I probably will eventually - I'll be playing catchup a bit on other tasks this month after doing almost no coding for CPython since some time in Feb. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 01:43:51 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Apr 2012 23:43:51 +0000 Subject: [issue14309] Deprecate time.clock() In-Reply-To: <1331772722.48.0.0484604711161.issue14309@psf.upfronthosting.co.za> Message-ID: <1333583031.1.0.766068719154.issue14309@psf.upfronthosting.co.za> STINNER Victor added the comment: I misunderstood the time.clock() function. It counts the CPU time while the process is active, whereas a monotonic clock counts elapsed time even during a sleep. time.clock() and time.monotonic() are different clocks for different purposes. I wrote the PEP 418 which contains a list of all available OS clocks. It lists monotonic clocks, but also "process time" and "thread time" clocks. And it has a "Deferred API: time.perf_counter()" section. Something can be done to provide portable functions to get the user and system times. See for example Tools/pybench/systimes.py written by Marc-Andre Lemburg. Python 3.3 gives access to clock_gettime(CLOCK_PROCESS_CPUTIME_ID) and clock_gettime(CLOCK_THREAD_CPUTIME_ID). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 01:49:31 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Apr 2012 23:49:31 +0000 Subject: [issue14309] Deprecate time.clock() In-Reply-To: <1331772722.48.0.0484604711161.issue14309@psf.upfronthosting.co.za> Message-ID: <1333583371.26.0.228512240873.issue14309@psf.upfronthosting.co.za> STINNER Victor added the comment: > Something can be done to provide portable functions to get > the user and system times. Lib/profile.py tests also various functions to choose the best one in Profile constructor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 01:54:35 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 04 Apr 2012 23:54:35 +0000 Subject: [issue14222] Use time.steady() to implement timeout In-Reply-To: <1331149120.51.0.79082225225.issue14222@psf.upfronthosting.co.za> Message-ID: <1333583675.26.0.2056688744.issue14222@psf.upfronthosting.co.za> STINNER Victor added the comment: Other modules that should use a monotonic clock instead of the system time: - timeit: default_timer = time.time (but time.clock is still the best clock on Windows for this mmodule) - subprocess for Popen.communicate() timeoout - sched - socket, ssl: timeout. need a C function which uses a monotonic clock if available, or fallback to the system clock - trace See also issues #12338 and #14309. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 02:55:27 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 05 Apr 2012 00:55:27 +0000 Subject: [issue14222] Use time.steady() to implement timeout In-Reply-To: <1331149120.51.0.79082225225.issue14222@psf.upfronthosting.co.za> Message-ID: <1333587327.62.0.141208406246.issue14222@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I don't think *trace* and *timeit* should be changed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 02:58:11 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 05 Apr 2012 00:58:11 +0000 Subject: [issue14494] __future__.py and its documentation claim absolute imports became mandatory in 2.7, but they didn't In-Reply-To: <1333543986.45.0.920300905324.issue14494@psf.upfronthosting.co.za> Message-ID: <1333587491.15.0.988224017111.issue14494@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 02:58:31 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 05 Apr 2012 00:58:31 +0000 Subject: [issue14500] test_importlib fails in refleak mode In-Reply-To: <1333577594.41.0.849099540387.issue14500@psf.upfronthosting.co.za> Message-ID: <1333587511.4.0.882095517841.issue14500@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 03:08:49 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 05 Apr 2012 01:08:49 +0000 Subject: [issue14493] use gvfs-open/xdg-open in Lib/webbrowser.py In-Reply-To: <1333541840.96.0.231691916093.issue14493@psf.upfronthosting.co.za> Message-ID: <1333588129.53.0.631752680624.issue14493@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 03:19:36 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 01:19:36 +0000 Subject: [issue14490] abitype.py wrong raise format In-Reply-To: <1333539922.74.0.14982794149.issue14490@psf.upfronthosting.co.za> Message-ID: <1333588776.23.0.914766194824.issue14490@psf.upfronthosting.co.za> R. David Murray added the comment: Serhiy: I'm not sure what you are talking about. Does it relate to this specific issue (abitype.py)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 03:29:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Apr 2012 01:29:48 +0000 Subject: [issue14491] fixcid.py is using <> instead of != In-Reply-To: <1333540706.17.0.957403109352.issue14491@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 62dde5dd475e by R David Murray in branch '3.2': #14490, #14491: add 'sundry'-style import tests for Tools/scripts. http://hg.python.org/cpython/rev/62dde5dd475e New changeset 696cb524322a by R David Murray in branch 'default': Merge #14490, #14491: add 'sundry'-style import tests for Tools/scripts. http://hg.python.org/cpython/rev/696cb524322a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 03:31:03 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 01:31:03 +0000 Subject: [issue14491] fixcid.py is using <> instead of != In-Reply-To: <1333540706.17.0.957403109352.issue14491@psf.upfronthosting.co.za> Message-ID: <1333589463.82.0.162084818596.issue14491@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the patch. ---------- resolution: -> fixed stage: test needed -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 03:31:09 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 01:31:09 +0000 Subject: [issue14491] fixcid.py is using <> instead of != In-Reply-To: <1333540706.17.0.957403109352.issue14491@psf.upfronthosting.co.za> Message-ID: <1333589469.21.0.684254767645.issue14491@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 03:32:12 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 01:32:12 +0000 Subject: [issue14490] abitype.py wrong raise format In-Reply-To: <1333539922.74.0.14982794149.issue14490@psf.upfronthosting.co.za> Message-ID: <1333589532.8.0.441152668515.issue14490@psf.upfronthosting.co.za> R. David Murray added the comment: Fixed in 62dde5dd475e and 696cb524322a. Thanks for the patch. ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 03:33:23 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 01:33:23 +0000 Subject: [issue14492] pdeps.py has_key In-Reply-To: <1333541422.42.0.575169190211.issue14492@psf.upfronthosting.co.za> Message-ID: <1333589603.37.0.977904606463.issue14492@psf.upfronthosting.co.za> R. David Murray added the comment: This one is not a syntax error, so the new 'sundry' tests don't catch it. Want to write a test for this one? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 03:47:48 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 01:47:48 +0000 Subject: [issue14497] Invalid syntax Python files in Python sources tree In-Reply-To: <1333571436.48.0.541559960271.issue14497@psf.upfronthosting.co.za> Message-ID: <1333590468.01.0.540731461083.issue14497@psf.upfronthosting.co.za> R. David Murray added the comment: Here's a run of your script against Python3.3 I see nothing on this list that is a problem (after the recent fixes in Tools/scripts). The Doc stuff can be ignored, that's a Python2 based toolchain checked out by the Doc 'make' file. As I said, lib2to3 tests contain python2 code. The other tests files are supposed to be bad syntax. The PC build toolchain is also still Python2 (same comment applies to the msi tool, which is part of that toolchain). I imagine the Mac buildscript is too, but Ned can comment on that. The gdb script is also Python2 (that's what GDB links against). So, I'm closing this issue. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed Added file: http://bugs.python.org/file25127/scan.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 03:51:54 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 01:51:54 +0000 Subject: [issue14493] use gvfs-open/xdg-open in Lib/webbrowser.py In-Reply-To: <1333541840.96.0.231691916093.issue14493@psf.upfronthosting.co.za> Message-ID: <1333590714.06.0.463155185462.issue14493@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 03:54:18 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 01:54:18 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1333590858.05.0.435615552551.issue14428@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 03:59:21 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 01:59:21 +0000 Subject: [issue13238] Add shell command helpers to subprocess module In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za> Message-ID: <1333591161.58.0.919357160956.issue13238@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 04:15:20 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 05 Apr 2012 02:15:20 +0000 Subject: [issue14491] fixcid.py is using <> instead of != In-Reply-To: <1333540706.17.0.957403109352.issue14491@psf.upfronthosting.co.za> Message-ID: <1333592120.08.0.7266632147.issue14491@psf.upfronthosting.co.za> ?ric Araujo added the comment: Great change David. Thanks for the help Popa! ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 04:19:08 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 05 Apr 2012 02:19:08 +0000 Subject: [issue14490] abitype.py wrong raise format In-Reply-To: <1333539922.74.0.14982794149.issue14490@psf.upfronthosting.co.za> Message-ID: <1333592348.68.0.870610422896.issue14490@psf.upfronthosting.co.za> ?ric Araujo added the comment: Serhiy is talking about the same syntax issue, but in other files, such as Tools/msi. The regex given sprouts a lot of false positives from comments or docstrings; for the msi one, I presume it is not a bug (it?s probably run with Python 2), otherwise Martin would have noticed it when making releases. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 04:58:47 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 05 Apr 2012 02:58:47 +0000 Subject: [issue14222] Use time.steady() to implement timeout In-Reply-To: <1331149120.51.0.79082225225.issue14222@psf.upfronthosting.co.za> Message-ID: <1333594727.51.0.278896798758.issue14222@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Why do you think monotonic time is needed for the Queue module? If time.time() goes backwards for some reason, the only consequence is that the timeouts take longer to cross the timeout boundard. On the other hand, it monotonic is used, then time won't go backwards but it won't go forwards either, so the consequence is the same. AFAICT, this patch doesn't fix any bug and doesn't make the module better in any observable way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 05:02:34 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Apr 2012 03:02:34 +0000 Subject: [issue14362] No mention of collections.ChainMap in What's New for 3.3 In-Reply-To: <1332069504.3.0.514334264343.issue14362@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset deadd0823ab3 by ?ric Araujo in branch 'default': A few tweaks to whatsnew/3.3 (fixes #14362) http://hg.python.org/cpython/rev/deadd0823ab3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 05:03:37 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 05 Apr 2012 03:03:37 +0000 Subject: [issue14362] No mention of collections.ChainMap in What's New for 3.3 In-Reply-To: <1332069504.3.0.514334264343.issue14362@psf.upfronthosting.co.za> Message-ID: <1333595017.23.0.282643637487.issue14362@psf.upfronthosting.co.za> ?ric Araujo added the comment: Done. ---------- assignee: docs at python -> eric.araujo resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 05:06:31 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 05 Apr 2012 03:06:31 +0000 Subject: [issue14362] No mention of collections.ChainMap in What's New for 3.3 In-Reply-To: <1332069504.3.0.514334264343.issue14362@psf.upfronthosting.co.za> Message-ID: <1333595191.22.0.148205599569.issue14362@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 05:28:21 2012 From: report at bugs.python.org (Matt Joiner) Date: Thu, 05 Apr 2012 03:28:21 +0000 Subject: [issue9634] Add timeout parameter to Queue.join() In-Reply-To: <1282153581.83.0.092560551276.issue9634@psf.upfronthosting.co.za> Message-ID: <1333596501.42.0.46787092542.issue9634@psf.upfronthosting.co.za> Changes by Matt Joiner : ---------- nosy: +anacrolix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 05:29:40 2012 From: report at bugs.python.org (Matt Joiner) Date: Thu, 05 Apr 2012 03:29:40 +0000 Subject: [issue1360] Queue.get() can't be interrupted with Ctrl-C unless timed out In-Reply-To: <1193702790.06.0.592600873674.issue1360@psf.upfronthosting.co.za> Message-ID: <1333596580.28.0.847052028287.issue1360@psf.upfronthosting.co.za> Matt Joiner added the comment: Isn't this fixed in Python>=3.2? ---------- nosy: +anacrolix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 07:27:51 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Apr 2012 05:27:51 +0000 Subject: [issue14497] Invalid syntax Python files in Python sources tree In-Reply-To: <1333571436.48.0.541559960271.issue14497@psf.upfronthosting.co.za> Message-ID: <1333603671.45.0.332646806572.issue14497@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Indeed, somehow I have in the source tree were many Python2 files. After `rm -r *` and `hg revert -a ` number of invalid files decreased to a reasonable limit. Sorry for the false alarm. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 07:51:43 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Apr 2012 05:51:43 +0000 Subject: [issue14490] abitype.py wrong raise format In-Reply-To: <1333539922.74.0.14982794149.issue14490@psf.upfronthosting.co.za> Message-ID: <1333605103.22.0.463412267332.issue14490@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Because of some error in my source tree was a lot of Python2 files, which gave a false result (see issue 14497). After cleaning, old-style raise was only in Mac/BuildScript/build-installer.py and Tools/msi/. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 08:45:55 2012 From: report at bugs.python.org (=?utf-8?b?0JzQsNC60YHQuNC8INCm0YvQv9C60LjQvQ==?=) Date: Thu, 05 Apr 2012 06:45:55 +0000 Subject: [issue14501] Error initialising BaseManager class with 'authkey' argument of string type. Message-ID: <1333608355.05.0.964001699487.issue14501@psf.upfronthosting.co.za> New submission from ?????? ?????? : The following code: class TestServer(BaseManager):pass Server_1=TestServer(address=("127.0.0.1",55555),authkey="passkey") produces following error in python 3.2 : "TypeError: string argument without an encoding" The cause is in BaseManager constructor implementation (Python32\Lib\multiprocessing\managers.py): self._authkey = AuthenticationString(authkey) The "AuthenticationString" class is a substitute of "bytes" class, and "bytes" class requires second encoding argument, if first argument is a string. I've solved this problem, changing the code in "Python32\Lib\multiprocessing\managers.py" to following: if isinstance(authkey,str): self._authkey = AuthenticationString(authkey,'utf-8') else: self._authkey = AuthenticationString(authkey) This works for me. Please consider to fix this issue in release. ---------- components: Extension Modules messages: 157539 nosy: Drauger priority: normal severity: normal status: open title: Error initialising BaseManager class with 'authkey' argument of string type. type: crash versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 08:55:11 2012 From: report at bugs.python.org (Georg Brandl) Date: Thu, 05 Apr 2012 06:55:11 +0000 Subject: [issue14492] pdeps.py has_key In-Reply-To: <1333541422.42.0.575169190211.issue14492@psf.upfronthosting.co.za> Message-ID: <1333608911.59.0.704682329671.issue14492@psf.upfronthosting.co.za> Georg Brandl added the comment: Should be "x not in y" BTW to be idiomatic, not "not x in y". ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 08:58:27 2012 From: report at bugs.python.org (Georg Brandl) Date: Thu, 05 Apr 2012 06:58:27 +0000 Subject: [issue14497] Invalid syntax Python files in Python sources tree In-Reply-To: <1333571436.48.0.541559960271.issue14497@psf.upfronthosting.co.za> Message-ID: <1333609107.93.0.584472942773.issue14497@psf.upfronthosting.co.za> Georg Brandl added the comment: Yes, Sphinx is still 2.x, although we could switch to a Python 3 version since now all necessary dependencies are ported. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 09:04:17 2012 From: report at bugs.python.org (Georg Brandl) Date: Thu, 05 Apr 2012 07:04:17 +0000 Subject: [issue14489] repr() function link on the built-in function documentation is incorrect In-Reply-To: <1333520679.63.0.90940412535.issue14489@psf.upfronthosting.co.za> Message-ID: <1333609457.72.0.0819022684504.issue14489@psf.upfronthosting.co.za> Georg Brandl added the comment: Shows how it's a bad thing to have a builtin function and a module of the same name :) ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 09:04:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Apr 2012 07:04:33 +0000 Subject: [issue14489] repr() function link on the built-in function documentation is incorrect In-Reply-To: <1333520679.63.0.90940412535.issue14489@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 4416efeb0163 by Georg Brandl in branch '2.7': Closes #14489: correct link target. http://hg.python.org/cpython/rev/4416efeb0163 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 09:06:56 2012 From: report at bugs.python.org (Georg Brandl) Date: Thu, 05 Apr 2012 07:06:56 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock Message-ID: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za> New submission from Georg Brandl : >From docs at python.org: """ I recently ran into a situation where I could not be certain that a lock was currently in the acquired state. I checked the documentation to determine what would happen if I attempted to release a lock that was already released, and saw an ominous warning of "Do not call this method when the lock is unlocked." Needing to know what would happen, I cautiously tested it out. I half expected my computer to explode as I released a lock for the second time, but was pleased to see it raise a 'thread.error' exception which could be caught and handled. I generally expect the documentation to tell me what will happen if I do something invalid. In this case the documentation should indicate that a thread.error will be raised if you release an unlocked lock. """ I agree: if we know that a ThreadError will always be raised in this instance, we should document it as such. ---------- assignee: docs at python components: Documentation messages: 157544 nosy: docs at python, georg.brandl, pitrou priority: normal severity: normal status: open title: Document better what happens on releasing an unacquired lock versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 09:09:02 2012 From: report at bugs.python.org (Georg Brandl) Date: Thu, 05 Apr 2012 07:09:02 +0000 Subject: [issue14486] Add some versionchanged notes in threading docs In-Reply-To: <1333501522.24.0.791616845298.issue14486@psf.upfronthosting.co.za> Message-ID: <1333609742.27.0.304326115946.issue14486@psf.upfronthosting.co.za> Georg Brandl added the comment: +1. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 09:23:42 2012 From: report at bugs.python.org (Popa Claudiu) Date: Thu, 05 Apr 2012 07:23:42 +0000 Subject: [issue14492] pdeps.py has_key In-Reply-To: <1333541422.42.0.575169190211.issue14492@psf.upfronthosting.co.za> Message-ID: <1333610622.93.0.925549836261.issue14492@psf.upfronthosting.co.za> Popa Claudiu added the comment: Hello. Here is the new patch. There was a few more problems: 1. in process, fp wasn't closed 2. in process, m_import.match(line) >= 0 could fail if the regular expression didn't matched on that line I've included the tests, too. ---------- Added file: http://bugs.python.org/file25128/pdeps2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 09:37:37 2012 From: report at bugs.python.org (Sandro Tosi) Date: Thu, 05 Apr 2012 07:37:37 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za> Message-ID: Sandro Tosi added the comment: On Thu, Apr 5, 2012 at 09:06, Georg Brandl wrote: > I agree: if we know that a ThreadError will always be raised in this instance, we should document it as such. I've already prepared a small patch for that (every supported release has a different exception raised..) I'll be fixing it this evening at home. ---------- nosy: +sandro.tosi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 09:48:22 2012 From: report at bugs.python.org (Georg Brandl) Date: Thu, 05 Apr 2012 07:48:22 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za> Message-ID: <1333612102.94.0.495397684059.issue14502@psf.upfronthosting.co.za> Georg Brandl added the comment: What different exceptions are they? Note that thread.error == _thread.error == threading.ThreadError. The docs should always use the last one (ThreadError). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 09:53:16 2012 From: report at bugs.python.org (Georg Brandl) Date: Thu, 05 Apr 2012 07:53:16 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za> Message-ID: <1333612396.86.0.912273046396.issue14502@psf.upfronthosting.co.za> Georg Brandl added the comment: Ah, and I missed that apparently on 3.3, _thread.Error is aliased to RuntimeError. In that case you should use RuntimeError of course :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 09:59:47 2012 From: report at bugs.python.org (Rik Poggi) Date: Thu, 05 Apr 2012 07:59:47 +0000 Subject: [issue11060] distutils2 sdist does not complain about version that is not PEP 386 compliant In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za> Message-ID: <1333612787.56.0.47647714595.issue11060@psf.upfronthosting.co.za> Rik Poggi added the comment: Hi, I'd like to contribute to this bug if it's possible. I would've directly started, but it seems the situation has moved/changed a bit, so I'm not sure where the tests are needed. There's a try/except, like the one mentioned above, in pypi/dist.py. Was that a consequence of this bug? Are tests needed for that conversion? The sdist command seems to be not complaining about any kind of irrational/invalid version. Should this be fixed? Should sdist check for a valid version number and do something like what ?ric Araujo mentioned in the last comment? ---------- nosy: +rik.poggi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 10:04:13 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Thu, 05 Apr 2012 08:04:13 +0000 Subject: [issue14503] docs:Code not highlighted Message-ID: <1333613053.66.0.675522025893.issue14503@psf.upfronthosting.co.za> New submission from Ramchandra Apte : In http://docs.python.org/dev/whatsnew/3.3.html#pep-380-syntax-for-delegating-to-a-subgenerator , two code samples ---------- assignee: docs at python components: Documentation messages: 157551 nosy: docs at python, ramchandra.apte priority: normal severity: normal status: open title: docs:Code not highlighted _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 10:04:50 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Thu, 05 Apr 2012 08:04:50 +0000 Subject: [issue14503] docs:Code not highlighted In-Reply-To: <1333613053.66.0.675522025893.issue14503@psf.upfronthosting.co.za> Message-ID: <1333613090.39.0.582183476565.issue14503@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Whoops - In http://docs.python.org/dev/whatsnew/3.3.html#pep-380-syntax-for-delegating-to-a-subgenerator , two code samples are not highlighted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 10:13:01 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Thu, 05 Apr 2012 08:13:01 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1333613581.34.0.39137323272.issue14478@psf.upfronthosting.co.za> Ramchandra Apte added the comment: I recommend that __hash__ should use functools.lru_cache for caching. ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 10:18:02 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 05 Apr 2012 08:18:02 +0000 Subject: [issue14321] Do not run pgen during the build if files are up to date In-Reply-To: <1331831244.15.0.8026915878.issue14321@psf.upfronthosting.co.za> Message-ID: <1333613882.51.0.419394172892.issue14321@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 10:34:12 2012 From: report at bugs.python.org (Amnon Harel) Date: Thu, 05 Apr 2012 08:34:12 +0000 Subject: [issue14504] Suggestion to improve argparse's help messages for "store_const" Message-ID: <1333614852.3.0.346870129538.issue14504@psf.upfronthosting.co.za> New submission from Amnon Harel : argparse's help messages for variables that use "store_const" can probably be improved: - propagate the default to all the options - mark the default option as such explicitly - group the keywords that have the same destination together (?) - place the default option first (?) For example, wouldn't the attached .py be better served with a help message that looks like: ... optional arguments: -h, --help show this help message and exit -w, --wrench use a wrench (default) -H, --hammer use a hammer (default: wrench) -s, --screwdriver use a screwdriver (default: wrench) -T, --tnt just blow the whole thing up (default: wrench) --foo FOO foo bar (default: None) ? ---------- components: Library (Lib) files: demo.py messages: 157554 nosy: Amnon.Harel priority: normal severity: normal status: open title: Suggestion to improve argparse's help messages for "store_const" type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file25129/demo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 11:01:23 2012 From: report at bugs.python.org (Matthias Klose) Date: Thu, 05 Apr 2012 09:01:23 +0000 Subject: [issue14505] PyFile_FromString leaks file descriptors in python 2.7 Message-ID: <1333616483.39.0.0432953809764.issue14505@psf.upfronthosting.co.za> New submission from Matthias Klose : [forwarded from http://bugs.debian.org/664529] seen with 2.7.3 rc2 File descriptors opened by PyFile_FromString don't get closed when the reference count is decreased. Here's my test program, pythony.c: #include int main() { int i = 0; PyObject *obj; Py_Initialize(); while (i++ < 5) { obj = PyFile_FromString("hello.py", "r"); assert(obj); Py_DECREF(obj); } Py_Finalize(); } hello.py is 'print("hello world")'. I'm compiling it with both Python 2.6 and 2.7. $ gcc pythony.c -lpython2.6 -L/usr/lib/python2.6/config -I/usr/include/python2.6/ -o pythony-2.6 $ gcc pythony.c -lpython2.7 -L/usr/lib/python2.7/config -I/usr/include/python2.7/ -o pythony-2.7 $ strace ./pythony-2.6 2>&1 | tail -n 20 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb1d097b0) = -1 EINVAL (Invalid argument) ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb1d097b0) = -1 EINVAL (Invalid argument) open("hello.py", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0 close(3) = 0 open("hello.py", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0 close(3) = 0 open("hello.py", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0 close(3) = 0 open("hello.py", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0 close(3) = 0 open("hello.py", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0 close(3) = 0 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f1e1a0224f0}, {0x7f1e1a49a160, [], SA_RESTORER, 0x7f1e1a0224f0}, 8) = 0 exit_group(0) = ? $ strace ./pythony-2.7 2>&1 | tail -n 20 fstat(4, {st_mode=S_IFREG|0644, st_size=1950, ...}) = 0 read(4, "", 4096) = 0 close(4) = 0 munmap(0x7fa41f10f000, 4096) = 0 close(3) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ffff7bd33f0) = -1 EINVAL (Invalid argument) ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ffff7bd33f0) = -1 EINVAL (Invalid argument) open("hello.py", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0 open("hello.py", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0 open("hello.py", O_RDONLY) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0 open("hello.py", O_RDONLY) = 6 fstat(6, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0 open("hello.py", O_RDONLY) = 7 fstat(7, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7fa4206e24f0}, {0x7fa420b8dd50, [], SA_RESTORER, 0x7fa4206e24f0}, 8) = 0 exit_group(0) = ? The Python 2.7 version never calls close, not even at Py_Finalize(). On #d-d, jwilk suspected that this change might be the cause: http://hg.python.org/cpython/rev/0f5b64630fda/#l4.46 ---------- components: Interpreter Core messages: 157555 nosy: doko priority: high severity: normal status: open title: PyFile_FromString leaks file descriptors in python 2.7 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 11:01:54 2012 From: report at bugs.python.org (Matthias Klose) Date: Thu, 05 Apr 2012 09:01:54 +0000 Subject: [issue14505] PyFile_FromString leaks file descriptors in python 2.7 In-Reply-To: <1333616483.39.0.0432953809764.issue14505@psf.upfronthosting.co.za> Message-ID: <1333616514.23.0.234746322218.issue14505@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 11:41:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Apr 2012 09:41:50 +0000 Subject: [issue3033] tkFont added displayof where necessary In-Reply-To: <1212515294.71.0.756028895858.issue3033@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 774c2afa6665 by Andrew Svetlov in branch 'default': Issue #3033: Add displayof parameter to tkinter font. http://hg.python.org/cpython/rev/774c2afa6665 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 11:43:28 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 05 Apr 2012 09:43:28 +0000 Subject: [issue3033] tkFont added displayof where necessary In-Reply-To: <1212515294.71.0.756028895858.issue3033@psf.upfronthosting.co.za> Message-ID: <1333619008.08.0.728353789157.issue3033@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Closing as fixed ---------- assignee: -> asvetlov resolution: -> fixed stage: patch review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 11:46:39 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 05 Apr 2012 09:46:39 +0000 Subject: [issue3033] tkFont added displayof where necessary In-Reply-To: <1212515294.71.0.756028895858.issue3033@psf.upfronthosting.co.za> Message-ID: <1333619199.83.0.683432241769.issue3033@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Thanks to Guilherme Polo. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 11:54:58 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 05 Apr 2012 09:54:58 +0000 Subject: [issue6225] Fixing several minor bugs in Tkinter.Canvas and one in Misc._configure In-Reply-To: <1244325396.24.0.788727463424.issue6225@psf.upfronthosting.co.za> Message-ID: <1333619698.75.0.51276885833.issue6225@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 11:56:51 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 05 Apr 2012 09:56:51 +0000 Subject: [issue6167] Tkinter.Scrollbar: the activate method needs to return a value, and set should take only two args In-Reply-To: <1243887092.8.0.492821608561.issue6167@psf.upfronthosting.co.za> Message-ID: <1333619811.14.0.37991403071.issue6167@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 12:30:13 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Apr 2012 10:30:13 +0000 Subject: [issue14505] PyFile_FromString leaks file descriptors in python 2.7 In-Reply-To: <1333616483.39.0.0432953809764.issue14505@psf.upfronthosting.co.za> Message-ID: <1333621813.52.0.0442623539335.issue14505@psf.upfronthosting.co.za> STINNER Victor added the comment: > File descriptors opened by PyFile_FromString don't get closed > when the reference count is decreased. Correct, PyFile_FromString() doesn't close the file descriptor, even if you call its close() method. You have to call manually fclose(file->f_fp). Or you can use PyFile_FromFile: fp = fopen(name, mode); if (fp == NULL) ... obj = PyFile_FromFile(fp, name, mode, fclose); if (obj == NULL) { /* no need to call fclose(fp) here, it's done by PyFile_FromFile() */ ... } ... Py_DECREF(obj); Would you like to write a patch for the documentation? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 12:41:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 05 Apr 2012 10:41:50 +0000 Subject: [issue14505] PyFile_FromString leaks file descriptors in python 2.7 In-Reply-To: <1333616483.39.0.0432953809764.issue14505@psf.upfronthosting.co.za> Message-ID: <1333622510.28.0.744366363092.issue14505@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Victor, that sounds like a strange behaviour to me. PyFile_FromString is a public API and maybe it shouldn't have changed between 2.6 and 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 13:20:08 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Apr 2012 11:20:08 +0000 Subject: [issue14505] PyFile_FromString leaks file descriptors in python 2.7 In-Reply-To: <1333622510.28.0.744366363092.issue14505@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Victor, that sounds like a strange behaviour to me. We may change PyFile_FromString() to call fclose() when the file is closed explicitly (call its close() method), but it may break backward compatibility. I prefer to document the behaviour instead. > PyFile_FromString is a public API and maybe it shouldn't > have changed between 2.6 and 2.7. PyFile_FromString() didn't change in Python 2.7. I changed PyFile_FromFile() in Python 2.7 to fix the issue #7732. changeset: 72456:0f5b64630fda branch: 2.7 parent: 72450:c02e790c4535 user: Victor Stinner date: Fri Sep 23 19:37:03 2011 +0200 files: Doc/c-api/file.rst Lib/test/test_import.py Misc/NEWS Objects/fileobject.c Python/import.c description: Issue #7732: Fix a crash on importing a module if a directory has the same name than a Python module (e.g. "__init__.py"): don't close the file twice. PyFile_FromFile() does also close the file if PyString_FromString() failed. It did already close the file on fill_file_fields() error (e.g. if the file is a directory). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 13:25:02 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Apr 2012 11:25:02 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1332785811.84.0.616508221107.issue14417@psf.upfronthosting.co.za> Message-ID: <1333625102.98.0.249770296229.issue14417@psf.upfronthosting.co.za> STINNER Victor added the comment: A counter can be added to dictobject.c.patch to avoid an infinite loop. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 13:27:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 05 Apr 2012 11:27:13 +0000 Subject: [issue14505] PyFile_FromString leaks file descriptors in python 2.7 In-Reply-To: <1333616483.39.0.0432953809764.issue14505@psf.upfronthosting.co.za> Message-ID: <1333625233.44.0.488335537299.issue14505@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Victor, what exactly are you talking about? http://hg.python.org/cpython/rev/0f5b64630fda/ *does* change PyFile_FromString. And Matthias mentioned that the problem didn't occur with 2.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 13:29:24 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Apr 2012 11:29:24 +0000 Subject: [issue14222] Use time.steady() to implement timeout In-Reply-To: <1331149120.51.0.79082225225.issue14222@psf.upfronthosting.co.za> Message-ID: <1333625364.26.0.965631004509.issue14222@psf.upfronthosting.co.za> STINNER Victor added the comment: > Why do you think monotonic time is needed for the Queue module? The duration of a timeout of N seconds should be N seconds even if the system clock is updated (e.g. a daylight saving time (DST) change). This feature is checked by an unit test in the patch attached to the isuse #14428 (implementation of the PEP 418): + def test_monotonic_settime(self): + t1 = time.monotonic() + realtime = time.clock_gettime(time.CLOCK_REALTIME) + # jump backward with an offset of 1 hour + time.clock_settime(time.CLOCK_REALTIME, realtime - 3600) + t2 = time.monotonic() + time.clock_settime(time.CLOCK_REALTIME, realtime) + # monotonic must not be affected by system clock updates + self.assertGreaterEqual(t2, t1) You can imagine a similar patch for Queue timeout. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 13:29:42 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Apr 2012 11:29:42 +0000 Subject: [issue14222] Use time.steady() to implement timeout In-Reply-To: <1331149120.51.0.79082225225.issue14222@psf.upfronthosting.co.za> Message-ID: <1333625382.63.0.732086207942.issue14222@psf.upfronthosting.co.za> STINNER Victor added the comment: > You can imagine a similar patch for Queue timeout. Oops: You can imagine a similar *test* for Queue timeout. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 13:44:34 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Apr 2012 11:44:34 +0000 Subject: [issue14249] unicodeobject.c: aliasing warnings In-Reply-To: <1331417993.32.0.291164156337.issue14249@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2c514c382a2a by Victor Stinner in branch 'default': Close #14249: Use an union instead of a long to short pointer to avoid aliasing http://hg.python.org/cpython/rev/2c514c382a2a ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 13:46:02 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Apr 2012 11:46:02 +0000 Subject: [issue14249] unicodeobject.c: aliasing warnings In-Reply-To: <1331417993.32.0.291164156337.issue14249@psf.upfronthosting.co.za> Message-ID: <1333626362.64.0.885314348503.issue14249@psf.upfronthosting.co.za> STINNER Victor added the comment: Result of the benchmark before/after my commit. I prefer an unit over manually manipulate long as short or bytes, because I think that the compiler knows better how to optimize operations on integers. unpatched: $ ./python -m timeit -s 'import codecs; d = codecs.utf_16_be_decode; x = (" " * 1000).encode("utf-16be")' 'd(x)' 100000 loops, best of 3: 4.64 usec per loop $ ./python -m timeit -s 'import codecs; d = codecs.utf_16_be_decode; x = ("\u263A" * 1000).encode("utf-16be")' 'd(x)' 100000 loops, best of 3: 5.87 usec per loop patched: $ ./python -m timeit -s 'import codecs; d = codecs.utf_16_be_decode; x = (" " * 1000).encode("utf-16be")' 'd(x)' 100000 loops, best of 3: 3.53 usec per loop $ ./python -m timeit -s 'import codecs; d = codecs.utf_16_be_decode; x = ("\u263A" * 1000).encode("utf-16be")' 'd(x)' 100000 loops, best of 3: 4.85 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 13:46:34 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Apr 2012 11:46:34 +0000 Subject: [issue14227] console w/ cp65001 displays extra characters for non-ascii strings. In-Reply-To: <1331181333.28.0.535514339767.issue14227@psf.upfronthosting.co.za> Message-ID: <1333626394.13.0.617479921952.issue14227@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm quite sure that this issue is a duplicate of #1602. ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 13:47:08 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Apr 2012 11:47:08 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1333626428.0.0.761600168407.issue1602@psf.upfronthosting.co.za> STINNER Victor added the comment: The issue #14227 has been marked as a duplicate of this issue. Copy of msg155149: This is on Windows 7 SP1. Run 'chcp 65001' then Python from a console. Note the extra characters when non-ASCII characters are in the string. At a guess it appears to be using the UTF-8 byte length of the internal representation instead of the character count. Python 3.3.0a1 (default, Mar 4 2012, 17:27:59) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> print('hello') hello >>> print('p\u012bny\u012bn') p?ny?n n >>> print('\u012b'*10) ?????????? ????? ?? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 13:51:41 2012 From: report at bugs.python.org (Olaf Tomalka) Date: Thu, 05 Apr 2012 11:51:41 +0000 Subject: [issue14506] HTMLParser can't handle erronous end tags with additional tags in it Message-ID: <1333626701.6.0.661176415375.issue14506@psf.upfronthosting.co.za> New submission from Olaf Tomalka : While this is wrongly formated html, I've spotted such an example on real website on the web, and all browsers handle the bad tag gracefully, while the python html parser throws an exception with "bad end tag", I think additional info in end tag should be ignored, no exception thrown and rest of the page parsed. I'm including minimal example. ---------- components: Library (Lib) files: minimal.py messages: 157570 nosy: ritave priority: normal severity: normal status: open title: HTMLParser can't handle erronous end tags with additional tags in it type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file25130/minimal.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 13:55:28 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 05 Apr 2012 11:55:28 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1333626928.49.0.909415069769.issue9141@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Here is a completely new patch. This approach uses the already existing tp_is_gc enquiry slot to signal garbage collection. The patch modifies the generator object to use this new mechanism. The patch keeps the old PyGen_NeedsFinalizing() API, but this can now go away, unless people think it might be used in extension modules (why do we always expose all those internal apis from the dll? I wonder.) ---------- Added file: http://bugs.python.org/file25131/ob_is_gc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 13:55:40 2012 From: report at bugs.python.org (marko kreen) Date: Thu, 05 Apr 2012 11:55:40 +0000 Subject: [issue14452] SysLogHandler sends invalid messages when using unicode In-Reply-To: <1333105941.84.0.159307303218.issue14452@psf.upfronthosting.co.za> Message-ID: <1333626940.36.0.176923827088.issue14452@psf.upfronthosting.co.za> marko kreen added the comment: The 'msg' in SysLogHandler does not correspond to MSG in RFC. Nor to %(message)s in log record. RFC: ------------------------ SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG] HEADER = PRI VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID PRI = "<" PRIVAL ">" [...] MSG = MSG-ANY / MSG-UTF8 MSG-ANY = *OCTET ; not starting with BOM MSG-UTF8 = BOM UTF-8-STRING BOM = %xEF.BB.BF -------------------------------- logging: The SysLogHandler does not provide any fields after PRI. Which is OK, those can be added via format string. We are using following formatter to get RFC-like structure to message: [formatter_syslog] format=%(hostname)s %(service_name)s %(job_name)s %(message)s That's not fully compliant, but that's beside the point. The problem is that SysLogHandler puts BOM before hostname not before %(message)s. In Python 2.6 it put it even before PRI, which was even more annoying. I see 2 solutions to this: 1) Stop putting BOM at all, its not necessary. 2) Put the BOM into %(message)s somehow, thus working with whatever format is given. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 14:02:41 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Apr 2012 12:02:41 +0000 Subject: [issue14386] Expose dict_proxy internal type as types.MappingProxyType In-Reply-To: <1332381004.13.0.167648412562.issue14386@psf.upfronthosting.co.za> Message-ID: <1333627361.35.0.971936534408.issue14386@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Expose dict_proxy internal type as types.MappingViewType -> Expose dict_proxy internal type as types.MappingProxyType _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 14:09:23 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 05 Apr 2012 12:09:23 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1333627763.47.0.0955101460995.issue9141@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 14:09:42 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Apr 2012 12:09:42 +0000 Subject: [issue14385] Support other types than dict for __builtins__ In-Reply-To: <1332380135.46.0.264363154256.issue14385@psf.upfronthosting.co.za> Message-ID: <1333627782.45.0.741262125731.issue14385@psf.upfronthosting.co.za> STINNER Victor added the comment: New version: - if __build_class__ is missing, raise a NameError instead of surprising ImportError - add tests - if PyObject_GetItem on __builtins__ or globals fail, only raise NameError if the exception is a KeyError Before my patch, a new dict was created for builtins if __builtins__ exists in global but is not a dict. With my patch, the __builtins__ is kept and the type is checked at runtime. If __builtins__ is not a mapping, an exception is raised on lookup in ceval.c. We may check __builtins__ type in PyFrame_New() using: PyDict_Check(builtins) || (PyMapping_Check(mapping) && !PyList_Check(mapping) && !PyTuple_Check(mapping)) (PyDict_Check(builtins) is checked first for performance) ---------- Added file: http://bugs.python.org/file25132/builtins-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 14:13:23 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Apr 2012 12:13:23 +0000 Subject: [issue14505] PyFile_FromString leaks file descriptors in python 2.7 In-Reply-To: <1333616483.39.0.0432953809764.issue14505@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 8258e5fa4a19 by Antoine Pitrou in branch '2.7': Issue #14505: Fix file descriptor leak when deallocating file objects created with PyFile_FromString(). http://hg.python.org/cpython/rev/8258e5fa4a19 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 14:16:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 05 Apr 2012 12:16:27 +0000 Subject: [issue14505] PyFile_FromString leaks file descriptors in python 2.7 In-Reply-To: <1333616483.39.0.0432953809764.issue14505@psf.upfronthosting.co.za> Message-ID: <1333628187.05.0.827724881746.issue14505@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Matthias, this should be fixed now. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 14:28:18 2012 From: report at bugs.python.org (Olaf Tomalka) Date: Thu, 05 Apr 2012 12:28:18 +0000 Subject: [issue14506] HTMLParser can't handle erronous end tags with additional info in them In-Reply-To: <1333626701.6.0.661176415375.issue14506@psf.upfronthosting.co.za> Message-ID: <1333628898.3.0.52845142971.issue14506@psf.upfronthosting.co.za> Changes by Olaf Tomalka : ---------- title: HTMLParser can't handle erronous end tags with additional tags in it -> HTMLParser can't handle erronous end tags with additional info in them _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 14:28:38 2012 From: report at bugs.python.org (Per Myren) Date: Thu, 05 Apr 2012 12:28:38 +0000 Subject: [issue14507] Segfault with starmap and izip combo Message-ID: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> New submission from Per Myren : The following code crashes with a segfault on Python 2.7.2: from operator import add from itertools import izip, starmap a = b = [1] for i in xrange(100000): a = starmap(add, izip(a, b)) list(a) It also crashes with Python 3.2.2: from operator import add from itertools import starmap a = b = [1] for i in range(100000): a = starmap(add, zip(a, b)) list(a) ---------- components: Library (Lib) messages: 157576 nosy: progrper priority: normal severity: normal status: open title: Segfault with starmap and izip combo type: crash versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 14:52:36 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 12:52:36 +0000 Subject: [issue14501] Error initialising BaseManager class with 'authkey' argument of string type. In-Reply-To: <1333608355.05.0.964001699487.issue14501@psf.upfronthosting.co.za> Message-ID: <1333630356.6.0.854351708155.issue14501@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the report. I'm not familiar with multiprocessing, so I'll have to leave it to someone else to judge the fix. We use 'crash' to indicate a segfault in the Python interpreter, so I'm changing the type to 'behavior' (that is, a normal bug). ---------- nosy: +asksol, r.david.murray type: crash -> behavior versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 14:53:39 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 05 Apr 2012 12:53:39 +0000 Subject: [issue14507] Segfault with starmap and izip combo In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1333630419.5.0.357927577048.issue14507@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Apparently it's a stack overflow between zip_next and starmap_next. ---------- nosy: +pitrou, rhettinger versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 14:59:14 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 12:59:14 +0000 Subject: [issue14503] docs:Code not highlighted In-Reply-To: <1333613053.66.0.675522025893.issue14503@psf.upfronthosting.co.za> Message-ID: <1333630754.51.0.410019437544.issue14503@psf.upfronthosting.co.za> R. David Murray added the comment: I'm not seeing any unhighlighted examples in that section. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 15:00:44 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 13:00:44 +0000 Subject: [issue14504] Suggestion to improve argparse's help messages for "store_const" In-Reply-To: <1333614852.3.0.346870129538.issue14504@psf.upfronthosting.co.za> Message-ID: <1333630844.32.0.414516771102.issue14504@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +bethard versions: +Python 3.3 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 15:01:08 2012 From: report at bugs.python.org (Popa Claudiu) Date: Thu, 05 Apr 2012 13:01:08 +0000 Subject: [issue14508] gprof2html is broken Message-ID: <1333630868.14.0.473747405241.issue14508@psf.upfronthosting.co.za> New submission from Popa Claudiu : Tools/gprof2html.py uses "file" to open a file. Also, the opened file passed to add_escapes was never closed. There's a test included in the patch. ---------- components: Demos and Tools files: gprof.patch keywords: patch messages: 157580 nosy: Popa.Claudiu priority: normal severity: normal status: open title: gprof2html is broken type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25133/gprof.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 15:01:22 2012 From: report at bugs.python.org (Rik Poggi) Date: Thu, 05 Apr 2012 13:01:22 +0000 Subject: [issue11060] distutils2 sdist does not complain about version that is not PEP 386 compliant In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za> Message-ID: <1333630882.65.0.161755328552.issue11060@psf.upfronthosting.co.za> Rik Poggi added the comment: Strictly related or not to this bug, a bit more test coverage shouldn't hurt. So while waiting for a reply I started writing a couple of tests for pypi/dist.py, hope they look good. ---------- Added file: http://bugs.python.org/file25134/test_pypi_dist.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 15:02:05 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 13:02:05 +0000 Subject: [issue14506] HTMLParser can't handle erronous end tags with additional info in them In-Reply-To: <1333626701.6.0.661176415375.issue14506@psf.upfronthosting.co.za> Message-ID: <1333630925.03.0.31263982886.issue14506@psf.upfronthosting.co.za> R. David Murray added the comment: Which version of python did you test with? There have been several improvements html parsing recently. ---------- nosy: +ezio.melotti, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 15:04:59 2012 From: report at bugs.python.org (Olaf Tomalka) Date: Thu, 05 Apr 2012 13:04:59 +0000 Subject: [issue14506] HTMLParser can't handle erronous end tags with additional info in them In-Reply-To: <1333626701.6.0.661176415375.issue14506@psf.upfronthosting.co.za> Message-ID: <1333631099.7.0.44750704788.issue14506@psf.upfronthosting.co.za> Olaf Tomalka added the comment: Python 3.2.2, which is latest on arch linux ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 15:07:32 2012 From: report at bugs.python.org (Berker Peksag) Date: Thu, 05 Apr 2012 13:07:32 +0000 Subject: [issue14503] docs:Code not highlighted In-Reply-To: <1333613053.66.0.675522025893.issue14503@psf.upfronthosting.co.za> Message-ID: <1333631252.48.0.765851885489.issue14503@psf.upfronthosting.co.za> Berker Peksag added the comment: I can reproduce. See screenshot.png. ---------- nosy: +berker.peksag Added file: http://bugs.python.org/file25135/screenshot.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 15:08:33 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 13:08:33 +0000 Subject: [issue14506] HTMLParser can't handle erronous end tags with additional info in them In-Reply-To: <1333626701.6.0.661176415375.issue14506@psf.upfronthosting.co.za> Message-ID: <1333631313.25.0.759415808486.issue14506@psf.upfronthosting.co.za> R. David Murray added the comment: I just tested your script on 3.2.3a2+, and it raises an error. Ezio made the other parsing changes, I'll leave it to him to evaluate what if anything should be done here. ---------- versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 15:42:51 2012 From: report at bugs.python.org (Thomas Wouters) Date: Thu, 05 Apr 2012 13:42:51 +0000 Subject: [issue14509] Build failures in non-pydebug builds without NDEBUG. Message-ID: <1333633371.25.0.0777678806587.issue14509@psf.upfronthosting.co.za> New submission from Thomas Wouters : The hash randomization change conflates 'pydebug' builds (which define the 'Py_DEBUG' preprocessor symbol) and asserts (which use 'NDEBUG' instead.) While Py_DEBUG automatically unsets NDEBUG, the inverse is not true (and should not be true.) In random.c (and Include/object.h), _Py_HashSecret_Initialized is defined as static or global depending on the value of Py_DEBUG. But in (at least) Objects/stringobject.c and Objects/unicodeobject.c, unguarded asserts are used that check the value of _Py_HashSecret_Initialized. This causes builds that define neither NDEBUG nor Py_DEBUG to fail. Either the guard used around the declaration and definition should be '#ifndef NDEBUG' instead of '#ifdef Py_DEBUG', or there should be a Py_DEBUG guard around the two assert statements. (I would submit a patch but my development environment died during a nasty power outage yesterday.) ---------- components: Interpreter Core messages: 157586 nosy: benjamin.peterson, twouters priority: release blocker severity: normal status: open title: Build failures in non-pydebug builds without NDEBUG. type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 15:47:42 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 13:47:42 +0000 Subject: [issue14503] docs:Code not highlighted In-Reply-To: <1333613053.66.0.675522025893.issue14503@psf.upfronthosting.co.za> Message-ID: <1333633662.72.0.740281252309.issue14503@psf.upfronthosting.co.za> R. David Murray added the comment: Berker: you can reproduce the bug, or the fact that they are highlighted? The png looks like they are highlighted, so I assume the latter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 15:47:47 2012 From: report at bugs.python.org (YunJian) Date: Thu, 05 Apr 2012 13:47:47 +0000 Subject: [issue14510] Regular Expression "+" perform wrong repeat Message-ID: <1333633667.39.0.742877689343.issue14510@psf.upfronthosting.co.za> New submission from YunJian : Regular expression perform wrong result, I use regular expression r'(\$.)+' try to match "$B$b" or something like that, but the script only give back "$b", r'(\$.){1,}', r'(\$.){2}' performed the same, you can take the file I attached for reference and run it, I try to solve it myself but failed, now I must use other ways to realize my aim, so appreciate for you help, thank you! ---------- components: Regular Expressions files: CheckInconsistency.py messages: 157588 nosy: ezio.melotti, mrabarnett, tld5yj priority: normal severity: normal status: open title: Regular Expression "+" perform wrong repeat type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file25136/CheckInconsistency.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 15:56:59 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 05 Apr 2012 13:56:59 +0000 Subject: [issue14503] docs:Code not highlighted In-Reply-To: <1333613053.66.0.675522025893.issue14503@psf.upfronthosting.co.za> Message-ID: <1333634219.67.0.951617093793.issue14503@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > they are highlighted No. Keywords normally appear in bold font, and with another color. This is not the case in these blocks. Probably because the language detection does not work with the new "yield from" construct. Sphinx should always use the latest Python... ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 15:58:39 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Apr 2012 13:58:39 +0000 Subject: [issue14496] Wrong name in idlelib/tabbedpages.py In-Reply-To: <1333560780.31.0.2464741525.issue14496@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f2dfe0ca6c21 by Andrew Svetlov in branch '3.2': Issue #14496: Fix wrong name in idlelib/tabbedpages.py. http://hg.python.org/cpython/rev/f2dfe0ca6c21 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 16:05:14 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 05 Apr 2012 14:05:14 +0000 Subject: [issue14496] Wrong name in idlelib/tabbedpages.py In-Reply-To: <1333560780.31.0.2464741525.issue14496@psf.upfronthosting.co.za> Message-ID: <1333634714.69.0.472206200092.issue14496@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Fixed. Thanks. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 16:09:32 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 05 Apr 2012 14:09:32 +0000 Subject: [issue1542677] IDLE shell gives different len() of unicode strings compared to Python shell Message-ID: <1333634972.81.0.444957232873.issue1542677@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Closing as won't fix. ---------- assignee: kbk -> asvetlov nosy: +asvetlov resolution: -> wont fix stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 16:11:25 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 14:11:25 +0000 Subject: [issue14503] docs:Code not highlighted In-Reply-To: <1333613053.66.0.675522025893.issue14503@psf.upfronthosting.co.za> Message-ID: <1333635085.55.0.825657269337.issue14503@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, you mean they are not *syntax* highlighted. Now I understand. Sorry for missing that. My understanding is that Sphinx does not use Python directly to parse the code and highlight it, it uses pygments, which uses regexes. So this basically amounts to a feature request for pygments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 16:23:19 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 05 Apr 2012 14:23:19 +0000 Subject: [issue1047540] Turtle.py hangs Idle Message-ID: <1333635799.03.0.771551590575.issue1047540@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Closing as not reproducible for 3.3. The bug is too minor to worry about 2.7 and 3.2 even if it present (all works for me by the way). Please reopen if you will get described issue. ---------- assignee: -> asvetlov nosy: +asvetlov resolution: -> out of date stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 16:32:18 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 05 Apr 2012 14:32:18 +0000 Subject: [issue14503] docs:Code not highlighted In-Reply-To: <1333613053.66.0.675522025893.issue14503@psf.upfronthosting.co.za> Message-ID: <1333636338.81.0.0113462934221.issue14503@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Not exactly. Sphinx first tries to see if the block is a Python script, and to do so it uses the Python compiler: https://bitbucket.org/birkenfeld/sphinx/src/164f59b2d946/sphinx/highlighting.py#cl-117 In case of SyntaxError, it treats the whole block as plain text and does not try to use pygmentq at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 16:44:59 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 14:44:59 +0000 Subject: [issue14503] docs:Code not highlighted In-Reply-To: <1333613053.66.0.675522025893.issue14503@psf.upfronthosting.co.za> Message-ID: <1333637099.28.0.172929663931.issue14503@psf.upfronthosting.co.za> R. David Murray added the comment: Huh. Well, in another issue Georg said it was now possible to upgrade the doc build toolchain to Python3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 16:53:52 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 05 Apr 2012 14:53:52 +0000 Subject: [issue14452] SysLogHandler sends invalid messages when using unicode In-Reply-To: <1333105941.84.0.159307303218.issue14452@psf.upfronthosting.co.za> Message-ID: <1333637632.01.0.87042437554.issue14452@psf.upfronthosting.co.za> Vinay Sajip added the comment: Ok, I see what the problem is. I could go for option 1 - leave the BOM out, encode the string as UTF-8 but send it as just a bunch of bytes, i.e. the MSG-ANY variant of the spec. However, this could break any existing code that doesn't use structured data before the message, as you are doing, and relies on the MSG-UTF8 variant. So while agreeing with you that the situation isn't ideal, I don't see how I can change things while preserving backward compatibility, other than: Introduce a class-level _insert_BOM attribute, defaulting to True but which can be set to False on a per-instance level. The BOM would only be inserted if this were True, so the current behaviour is preserved, but you could set the attribute to False and leave the BOM out. However, isn't ideal either, as it requires you to be sensitive to the exact version of Python in use - not easy if you're developing a library rather than an application. I will consider a different approach in 3.3, e.g. provide one or more overridable methods to construct the message sent across the socket. Thoughts? If these methods won't suffice, you can always resort to subclassing the handler and overriding the emit method (not that that's ideal, either). ---------- resolution: invalid -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 17:08:31 2012 From: report at bugs.python.org (marko kreen) Date: Thu, 05 Apr 2012 15:08:31 +0000 Subject: [issue14452] SysLogHandler sends invalid messages when using unicode In-Reply-To: <1333105941.84.0.159307303218.issue14452@psf.upfronthosting.co.za> Message-ID: <1333638511.13.0.467085438629.issue14452@psf.upfronthosting.co.za> marko kreen added the comment: Note additional brokenness in BOM addition: * It does add BOM even when msg is ascii, just because it was in unicode() string. * It does not add BOM to UTF8 string if it is already encoded to str(). So highly doubt anybody actually relies on it. And keeping such addition just increases chance that anybody starts to rely on it, so it would be good to just drop it. For 3.3, I think it would be best to move syslog packet formatting out from emit(), because emit() already contains noticeable amount of unrelated code, so full override it is annoying. I suggested changing BOM addition so that it only adds it to %(message)s, but such change could cause backwards incompatibility. So it does not look like good idea. But dropping BOM even in old Python *does* look like good idea, as anybody using SysLoghandler needs to deal with BOM-less UTF8 anyway, so dropping it will not create backwards incompatibility. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 17:33:55 2012 From: report at bugs.python.org (Zachary Ware) Date: Thu, 05 Apr 2012 15:33:55 +0000 Subject: [issue14511] _static/opensearch.xml for Python 3.2 docs directs searches to 3.3 docs Message-ID: <1333640035.04.0.466278675781.issue14511@psf.upfronthosting.co.za> New submission from Zachary Ware : Adding the search plugin for the 3.2 docs to Firefox and then searching from it returns results from the 3.3 dev docs, despite everything saying it should be for searching "Python v3.2.2 documentation". If my understanding of how it all works is correct, the attached patch should fix the issue. It simply removes 'dev/' from the html_use_opensearch assignment in Doc\conf.py in the 3.2 branch. Thanks, Zach ---------- assignee: docs at python components: Documentation files: 3.2 conf.py opensearch.diff keywords: patch messages: 157599 nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, zach.ware priority: normal severity: normal status: open title: _static/opensearch.xml for Python 3.2 docs directs searches to 3.3 docs type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file25137/3.2 conf.py opensearch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 18:08:26 2012 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 05 Apr 2012 16:08:26 +0000 Subject: [issue14510] Regular Expression "+" perform wrong repeat In-Reply-To: <1333633667.39.0.742877689343.issue14510@psf.upfronthosting.co.za> Message-ID: <1333642106.13.0.523608559084.issue14510@psf.upfronthosting.co.za> Matthew Barnett added the comment: If a capture group is repeated, as in r'(\$.)+', only its last match is returned. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 18:11:53 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 05 Apr 2012 16:11:53 +0000 Subject: [issue14506] HTMLParser can't handle erronous end tags with additional info in them In-Reply-To: <1333626701.6.0.661176415375.issue14506@psf.upfronthosting.co.za> Message-ID: <1333642313.02.0.509056675646.issue14506@psf.upfronthosting.co.za> Ezio Melotti added the comment: This is already fixed, but only in non-strict mode (and 3.2.3 iirc). You should always use HTMLParser(strict=False). The non-strict mode will probably become the default and strict=True will be deprecated. Thanks anyway for the report, and please report any failure that you might find with strict=False. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 18:29:51 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 05 Apr 2012 16:29:51 +0000 Subject: [issue11060] distutils2 sdist does not complain about version that is not PEP 386 compliant In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za> Message-ID: <1333643391.48.0.997841290202.issue11060@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the tests! I should have some time this week-end to review them and explain clearly what this bug is about and where tests should go. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 18:33:18 2012 From: report at bugs.python.org (James Hutchison) Date: Thu, 05 Apr 2012 16:33:18 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1333643598.75.0.708280665281.issue14478@psf.upfronthosting.co.za> James Hutchison added the comment: I presume you mean in 3.2? Have you looked at the source code for that decorator? It's fundamentally a try/except but with a lot more unnecessary bloat than is needed for caching a single int result from a function with no arguments. Its actually a lot slower. If this is likely going to see use in 3.3 then it would probably just be a long int since 3.3 uses C. 0 would indicate uncalculated. Hash function would have to be set up to never return 0. Also every function would need to be tested to make sure there isn't any "in-place" modification of the Decimal object that could alter the hash value. I like how the cached hash in 3.3 is faster than int for hashing. Shouldn't an int just return itself? Why would it be slower? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 18:50:07 2012 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 05 Apr 2012 16:50:07 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1333625102.98.0.249770296229.issue14417@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > A counter can be added to dictobject.c.patch to avoid an infinite loop. But why bother? There was no counter originally -- it would continue until it ran out of stack. Since this can only be triggered if there is Python code in the __eq__, that means that it is still interruptable with ^C. Does this mean I should just check it in? But I asked, and never got an answer, whether the original stress test had been converted into a unittest. I'd like that to happen before I check this in. Also there are probably docs I've missed. Somebody please help! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 18:59:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 05 Apr 2012 16:59:26 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: Message-ID: <1333644848.3326.8.camel@localhost.localdomain> Antoine Pitrou added the comment: > Does this mean I should just check it in? But I asked, and never got > an answer, whether the original stress test had been converted into a > unittest. I'd like that to happen before I check this in. Also there > are probably docs I've missed. Somebody please help! I think your approach is fine. As far as I can tell, the original crasher hasn't been converted into an unit test, since Victor's test in 934aaf2191d0 doesn't seem prone to triggering an infinite loop. As far as doc changes go, you should probably remove the what's new entry from a428f85de29c, and the doc addition from 0255bafbccf2. Besides, does the test suite pass with your patch? It looks like Victor's test, which checks that RuntimeError is raised, should now fail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 19:07:05 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 05 Apr 2012 17:07:05 +0000 Subject: [issue14512] Pydocs module docs server not working on Windows. Message-ID: <1333645625.74.0.578211515784.issue14512@psf.upfronthosting.co.za> New submission from Terry J. Reedy : 3.2.3rc2 and 3.3.0a2, freshly downloaded and installed, Win7, 64 bit Start Menue/Pythonxx/Module Docs Brings up tkinter pydoc box. [open browser] brings up *empty* localhost:7464 window. Search 'tkinter' and double-click tkinter entry or select and [go to selected] opens empty localhost:7464/tkinter.html window. This worked sometime last year on earlier 3.2, maybe on xp box. I thought there might be an issue already, but I searched for 'pydoc' and 'modole docs' and found nothing. ---------- assignee: docs at python components: Documentation, Installation, Library (Lib) messages: 157606 nosy: docs at python, georg.brandl, loewis, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Pydocs module docs server not working on Windows. type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 19:25:06 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Apr 2012 17:25:06 +0000 Subject: [issue14505] PyFile_FromString leaks file descriptors in python 2.7 In-Reply-To: <1333625233.44.0.488335537299.issue14505@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Victor, what exactly are you talking about? http://hg.python.org/cpython/rev/0f5b64630fda/ *does* change PyFile_FromString. Oh. I don't know (remember) why I did this change!? I suppose that I changed it to test something and then forget to remove the temporary hack :-/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 20:23:38 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 05 Apr 2012 18:23:38 +0000 Subject: [issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za> Message-ID: <1333650218.2.0.189670086316.issue7839@psf.upfronthosting.co.za> Andrew Svetlov added the comment: What's about test which pass bytes to Popen? Should it be deprecated and should Popen accept only unicode strings only ? I mean `str` type? As I know the trend of py3k to get rid of bytes in filesystem names. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 20:55:21 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Apr 2012 18:55:21 +0000 Subject: [issue8515] idle "Run Module" (F5) does not set __file__ variable In-Reply-To: <1272071890.53.0.295001627395.issue8515@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2c276d0553ff by Andrew Svetlov in branch 'default': Issue #8515: Set __file__ when run file in IDLE. http://hg.python.org/cpython/rev/2c276d0553ff ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 21:00:41 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 05 Apr 2012 19:00:41 +0000 Subject: [issue8515] idle "Run Module" (F5) does not set __file__ variable In-Reply-To: <1272071890.53.0.295001627395.issue8515@psf.upfronthosting.co.za> Message-ID: <1333652441.95.0.328134232035.issue8515@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Thanks to all. Bruce Frederiksen, you are mentioned in Misc/ACK Tal Einat, if you want to make a patch which will use `execfile` instead of current approach ? you are welcome. Please file new issue. ---------- assignee: -> asvetlov resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 21:04:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 05 Apr 2012 19:04:11 +0000 Subject: [issue14509] Build failures in non-pydebug builds without NDEBUG. In-Reply-To: <1333633371.25.0.0777678806587.issue14509@psf.upfronthosting.co.za> Message-ID: <1333652651.53.0.589758239397.issue14509@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 21:34:52 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 05 Apr 2012 19:34:52 +0000 Subject: [issue14513] IDLE icon switched and switches on Windows taskbar Message-ID: <1333654492.57.0.20461784389.issue14513@psf.upfronthosting.co.za> New submission from Terry J. Reedy : IDLE has an icon that is, appropriately, a white page with text overlaid with the Python logo on lower right. (Module docs uses the same icon.) For a long time, this has been used everywhere for IDLE -- start menu, desktop, taskbar. In the latest 3.2.3rc2 and 3.3.0a2 releases, the Windows 7 taskbar icon for IDLE is the red Tk icon. If IDLE is pinned to the taskbar, the icon changes to the command-prompt + logo python-pythonw icon. This seems to be new in these releases and is confusing and annoying. Otherwise, the IDLE icon is as it was. ---------- components: Installation, Windows messages: 157611 nosy: georg.brandl, loewis, terry.reedy priority: normal severity: normal status: open title: IDLE icon switched and switches on Windows taskbar versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 21:46:23 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Apr 2012 19:46:23 +0000 Subject: [issue14249] unicodeobject.c: aliasing warnings In-Reply-To: <1331417993.32.0.291164156337.issue14249@psf.upfronthosting.co.za> Message-ID: <1333655183.56.0.678322448275.issue14249@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What compiler are you using? With gcc 4.4 on 32-bit Linux netbook I get: unpatched union shift utf-16le " "*10000 129 126 109 utf-16le "\u263A"*10000 208 203 160 utf-16be " "*10000 153 147 114 utf-16be "\u263A"*10000 226 227 167 The difference is that for shift the compiler stores block in register, and for the union the compiler stores block in memory, so that it can get address. May be more recent compilers learned to do this more effectively? Besides, shifts are more pronounced for CPython code, searching shows very few uses of union in the source code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 22:02:40 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 05 Apr 2012 20:02:40 +0000 Subject: [issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za> Message-ID: <1333656160.49.0.351976617907.issue7839@psf.upfronthosting.co.za> R. David Murray added the comment: No, you need to be able to pass bytes to Popen, just like you do to the os.exec[xx] functions. When the OS doesn't fully support unicode, that is sometimes the only option. As for filenames; again, as long as the underlying systems use bytes filenames we need to support it. Currently we encode them when received using surrogateescape and decode them back to bytes when used. I am not sure what os.exec[xx] does with strings containing non-ascii. Presumably it uses some default encoding or other, which seems to be utf-8 on my system. (It doesn't seem to be explicitly documented where those functions are discussed in the os module.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 22:03:56 2012 From: report at bugs.python.org (Stefan Krah) Date: Thu, 05 Apr 2012 20:03:56 +0000 Subject: [issue14249] unicodeobject.c: aliasing warnings In-Reply-To: <1333655183.56.0.678322448275.issue14249@psf.upfronthosting.co.za> Message-ID: <20120405200355.GA19303@sleipnir.bytereef.org> Stefan Krah added the comment: On 64-bit Linux with gcc-4.4 I get: Unpatched: $ ./python -m timeit -s 'import codecs; d = codecs.utf_16_be_decode; x = (" " * 1000).encode("utf-16be")' 'd(x)' 100000 loops, best of 3: 4.1 usec per loop $ ./python -m timeit -s 'import codecs; d = codecs.utf_16_be_decode; x = ("\u263A" * 1000).encode("utf-16be")' 'd(x)' 100000 loops, best of 3: 5.87 usec per loop 2c514c382a2a: $ ./python -m timeit -s 'import codecs; d = codecs.utf_16_be_decode; x = (" " * 1000).encode("utf-16be")' 'd(x)' 100000 loops, best of 3: 3.68 usec per loop $ ./python -m timeit -s 'import codecs; d = codecs.utf_16_be_decode; x = ("\u263A" * 1000).encode("utf-16be")' 'd(x)' 100000 loops, best of 3: 4.72 usec per loop utf16_decoder_shift_3.patch: $ ./python -m timeit -s 'import codecs; d = codecs.utf_16_be_decode; x = (" " * 1000).encode("utf-16be")' 'd(x)' 100000 loops, best of 3: 2.23 usec per loop $ ./python -m timeit -s 'import codecs; d = codecs.utf_16_be_decode; x = ("\u263A" * 1000).encode("utf-16be")' 'd(x)' 100000 loops, best of 3: 3.11 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 22:17:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 05 Apr 2012 20:17:29 +0000 Subject: [issue14249] unicodeobject.c: aliasing warnings In-Reply-To: <1331417993.32.0.291164156337.issue14249@psf.upfronthosting.co.za> Message-ID: <1333657049.84.0.521643715582.issue14249@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Linux, 64-bit, Intel Core i5 2500: -> unpatched: $ ./python -m timeit -s 'import codecs; d = codecs.utf_16_be_decode; x = (" " * 1000).encode("utf-16be")' 'd(x)' 100000 loops, best of 3: 2.99 usec per loop -> Victor's commit: $ ./python -m timeit -s 'import codecs; d = codecs.utf_16_be_decode; x = (" " * 1000).encode("utf-16be")' 'd(x)' 100000 loops, best of 3: 2.83 usec per loop -> utf16_decoder_shift_3.patch: $ ./python -m timeit -s 'import codecs; d = codecs.utf_16_be_decode; x = (" " * 1000).encode("utf-16be")' 'd(x)' 1000000 loops, best of 3: 1.88 usec per loop It seems that the wrong patch was committed. ---------- assignee: -> haypo resolution: fixed -> stage: committed/rejected -> commit review status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 22:17:49 2012 From: report at bugs.python.org (Jim Jewett) Date: Thu, 05 Apr 2012 20:17:49 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1332785811.84.0.616508221107.issue14417@psf.upfronthosting.co.za> Message-ID: <1333657069.47.0.77304833554.issue14417@psf.upfronthosting.co.za> Jim Jewett added the comment: >> A counter can be added to dictobject.c.patch to avoid >> an infinite loop. > But why bother? Without a termination condition, how is this different from just reverting the original change? Is it just the slightly improvement in efficiency? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 22:20:23 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 05 Apr 2012 20:20:23 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1333657069.47.0.77304833554.issue14417@psf.upfronthosting.co.za> Message-ID: <1333656905.3326.9.camel@localhost.localdomain> Antoine Pitrou added the comment: > Without a termination condition, how is this different from just > reverting the original change? The difference is that it's a (presumably interruptible) infinite loop, not a stack overflow. There's no crash and therefore no security issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 22:23:56 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 05 Apr 2012 20:23:56 +0000 Subject: [issue14386] Expose dict_proxy internal type as types.MappingProxyType In-Reply-To: <1332381004.13.0.167648412562.issue14386@psf.upfronthosting.co.za> Message-ID: <1333657436.28.0.934036108842.issue14386@psf.upfronthosting.co.za> Raymond Hettinger added the comment: [Victor] '''Oh, collections.abc contains also the mappingview type exposed with the name "dict_proxy": dict_proxy = type(type.__dict__) It was exposed as _abcoll.dict_proxy in Python 3.2. It is not documented. Should we keep it for backward compatibility, or can it be removed? _abcoll was a private module and I didn't find dict_proxy in Python 3.2 doc. ''' You can ignore those. As you saw, these are undocumented and not listed in __all__. If we ever expose these, it will likely be through the types module (or less likely through the collections.abc module which is public in 3.3). Probably, they won't get exposed at all because they are awkward to access directly and because they have implementation specific details (i.e. other implementations have their choice of how to implement various iterators and whatnot). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 22:35:36 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Apr 2012 20:35:36 +0000 Subject: [issue14386] Expose dict_proxy internal type as types.MappingProxyType In-Reply-To: <1332381004.13.0.167648412562.issue14386@psf.upfronthosting.co.za> Message-ID: <1333658136.76.0.602044912237.issue14386@psf.upfronthosting.co.za> STINNER Victor added the comment: > You can ignore those. You mean that I can remove it? It's a little bit surprising to find a concrete class in collections.abc. So I think that it's better to expose dict_proxy in types than in collections.abc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 22:50:14 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 05 Apr 2012 20:50:14 +0000 Subject: [issue7057] tkinter doc: more 3.x updates In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za> Message-ID: <1333659014.83.0.762454990091.issue7057@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- assignee: gpolo -> asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 22:54:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Apr 2012 20:54:48 +0000 Subject: [issue14249] unicodeobject.c: aliasing warnings In-Reply-To: <1331417993.32.0.291164156337.issue14249@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 489f252b1f8b by Victor Stinner in branch 'default': Close #14249: Use bit shifts instead of an union, it's more efficient. http://hg.python.org/cpython/rev/489f252b1f8b ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 22:57:00 2012 From: report at bugs.python.org (Jim Jewett) Date: Thu, 05 Apr 2012 20:57:00 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1333659420.64.0.561343212689.issue9141@psf.upfronthosting.co.za> Jim Jewett added the comment: I think the second patch is a fairly straightforward enhancement to the existing situation. It still feels a bit like an awkward half-measure, though. (1) If a class does have a finalizer, instances should still be able to say "Go ahead and collect me, I don't happen to be in the problematic state." (In other words, there should be a return value that means not to bother checking for the existence of a tp_del / __del__ method.) (2) It should be explicit whether or not this is: (2a) just an inquiry ("If you were in a cycle, could I collect you?), (2b) a statement plus inquiry ("You are in a cycle. Can I collect you?"), or (2c) a request ("You are in a cycle, and I would like to collect you. Clean up if you can, then tell me whether you are still uncollectable.") (3) It may be worth adding an additional slot for safe idempotent finalizers. (Earlier suggestions called this __close__, but I suppose __finalize__ might be more general.) Once a garbage cycle is detected, go ahead and call that slot's method before giving up and sticking the whole thing in garbage. If python classes could also fill this slot, it would look a lot like (2c). ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 23:00:31 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Apr 2012 21:00:31 +0000 Subject: [issue14249] unicodeobject.c: aliasing warnings In-Reply-To: <1331417993.32.0.291164156337.issue14249@psf.upfronthosting.co.za> Message-ID: <1333659631.69.0.600369800185.issue14249@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, benchmarks have spoken, amen. I applied Serhiy Storchaka's patch (version 3). I just replaced expressions in calls to Py_MAX by variables: Py_MAX is a macro and it may have to compute each expression twice. I didn't check if it's more or less efficient. Thanks Serhiy for your contribution! I added your name to Misc/ACKS. We may change Py_MIN/Py_MAX to something more efficient using typeof(): #define max(a,b) \ ({ typeof (a) _a = (a); \ typeof (b) _b = (b); \ _a > _b ? _a : _b; }) I don't know which C compilers support it, but gcc does, at least. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 23:01:59 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 05 Apr 2012 21:01:59 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset efeca6ff2751 by Sandro Tosi in branch '2.7': Issue #14502: release() and unlocked lock generates a ThreadError http://hg.python.org/cpython/rev/efeca6ff2751 New changeset acea9d95a6d8 by Sandro Tosi in branch '3.2': Issue #14502: release() and unlocked lock generates a ThreadError http://hg.python.org/cpython/rev/acea9d95a6d8 New changeset c10a0f93544e by Sandro Tosi in branch 'default': Issue #14502: merge with 3.2 http://hg.python.org/cpython/rev/c10a0f93544e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 23:05:47 2012 From: report at bugs.python.org (Sandro Tosi) Date: Thu, 05 Apr 2012 21:05:47 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za> Message-ID: <1333659947.1.0.648707042324.issue14502@psf.upfronthosting.co.za> Changes by Sandro Tosi : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 23:24:26 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 05 Apr 2012 21:24:26 +0000 Subject: [issue14249] unicodeobject.c: aliasing warnings In-Reply-To: <1333659631.69.0.600369800185.issue14249@psf.upfronthosting.co.za> Message-ID: <1333661201.19688.41.camel@raxxla> Serhiy Storchaka added the comment: > I just replaced expressions in calls to Py_MAX by variables: Py_MAX is a macro and it may have to compute each expression twice. gcc computes those values only once. It even caches them for use in PyUnicode_WRITE. But other compilers may not be so smart. Instead of Py_MAX(a,b) here you can use a|b. In theory this should be more efficient, but I couldn't see the difference even with microscope. However, all this does not matter, soon I will submit complex patch, which speeds up the utf-16 decoder in 2-5 times. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 23:35:14 2012 From: report at bugs.python.org (Jim Jewett) Date: Thu, 05 Apr 2012 21:35:14 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za> Message-ID: <1333661714.57.0.492844768267.issue14502@psf.upfronthosting.co.za> Jim Jewett added the comment: At least put the information inside some disclaimers about "normally"; even the stdlib has some fake locks that let you release a lock someone else holds. (I think I found them in in workarounds for threading not being available, such as the dummy_* modules, but still, it is possible.) ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 23:38:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 05 Apr 2012 21:38:18 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333661714.57.0.492844768267.issue14502@psf.upfronthosting.co.za> Message-ID: <1333661578.3326.12.camel@localhost.localdomain> Antoine Pitrou added the comment: > At least put the information inside some disclaimers about "normally"; > even the stdlib has some fake locks that let you release a lock > someone else holds. Not sure what you're talking about. The doc patch is about unacquired locks, not locks that someone else (another thread) holds. Indeed the standard Lock object (but not the RLock) does allow releasing from another thread. It's a feature (which makes it serve as a binary semaphore). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 23:45:45 2012 From: report at bugs.python.org (Nicholas Cole) Date: Thu, 05 Apr 2012 21:45:45 +0000 Subject: [issue12567] curses implementation of Unicode is wrong in Python 3 In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za> Message-ID: <1333662345.31.0.0670232250632.issue12567@psf.upfronthosting.co.za> Nicholas Cole added the comment: Testing the Python3.3a2 build on OS X - the exception AttributeError: '_curses.curses window' object has no attribute 'get_wch' is still being raised. I don't have a Linux build I can easily test with. Is this a particular problem with the OS X build? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 5 23:48:23 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Apr 2012 21:48:23 +0000 Subject: [issue12567] curses implementation of Unicode is wrong in Python 3 In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za> Message-ID: <1333662503.73.0.651907100945.issue12567@psf.upfronthosting.co.za> STINNER Victor added the comment: > AttributeError: '_curses.curses window' object has no attribute 'get_wch' > is still being raised. "still"? Did it work before my last changes? Unicode functions of the (n)curses library are only available if the Python curses module is linked to libncursesw. Is libncursesw available? Is libreadline linked to libncurses or libncursesw? If libreadline is linked to libncurses, the Python curses module is also linked to libncurses. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 00:20:48 2012 From: report at bugs.python.org (Santoso Wijaya) Date: Thu, 05 Apr 2012 22:20:48 +0000 Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za> Message-ID: <1333664448.5.0.0331871375737.issue14465@psf.upfronthosting.co.za> Changes by Santoso Wijaya : ---------- nosy: +santa4nt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 00:22:16 2012 From: report at bugs.python.org (Santoso Wijaya) Date: Thu, 05 Apr 2012 22:22:16 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333664536.7.0.841356963991.issue14310@psf.upfronthosting.co.za> Changes by Santoso Wijaya : ---------- nosy: +santa4nt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 00:39:10 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 05 Apr 2012 22:39:10 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1332785811.84.0.616508221107.issue14417@psf.upfronthosting.co.za> Message-ID: <1333665550.2.0.765699324396.issue14417@psf.upfronthosting.co.za> STINNER Victor added the comment: > The difference is that it's a (presumably interruptible) infinite loop, > not a stack overflow. There's no crash and therefore no security issue. Ok, it looks fair. The patch looks good, but as written by Antoine: tests may need to be fixed. Is anyone motivated to "convert" removed crashers to unit tests? Not me. Crashers were only written to crash Python. New tests should be written instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 03:10:27 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 06 Apr 2012 01:10:27 +0000 Subject: [issue14386] Expose dict_proxy internal type as types.MappingProxyType In-Reply-To: <1332381004.13.0.167648412562.issue14386@psf.upfronthosting.co.za> Message-ID: <1333674627.08.0.340532095443.issue14386@psf.upfronthosting.co.za> Raymond Hettinger added the comment: [Victor] > You mean that I can remove it? No, it needs to stay there. Those concrete types aren't exposed to users but they are used inside to collections.abcs to register the types so that isinstance() will work as expected. Summary: The collections.abc module is fine as-is. Go ahead and add dictproxy to the types module. Expose it there and document it there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 03:25:43 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Apr 2012 01:25:43 +0000 Subject: [issue14508] gprof2html is broken In-Reply-To: <1333630868.14.0.473747405241.issue14508@psf.upfronthosting.co.za> Message-ID: <1333675543.42.0.0206404091828.issue14508@psf.upfronthosting.co.za> R. David Murray added the comment: I'm getting 'malformed patch at line 30' when I try to apply your patch. Also, while it's not wrong, I don't think there's much point in catching the NameError and doing a fail. The second Exception clause is definitely wrong, though, we don't want other errors to pass silently. So I think the test should just do the call to gprof.main, with a comment mentioning this bug and saying that the call used to raise a NameError. (If it does fail for some other reason, then the test will need to get a little more complicated so that it doesn't.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 03:41:05 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 06 Apr 2012 01:41:05 +0000 Subject: [issue14510] Regular Expression "+" perform wrong repeat In-Reply-To: <1333633667.39.0.742877689343.issue14510@psf.upfronthosting.co.za> Message-ID: <1333676465.43.0.537272251922.issue14510@psf.upfronthosting.co.za> Ezio Melotti added the comment: >>> re.findall(r'((?:\$.)+)', 'This $b$B is also a variable, but it\'s not $B$b') ['$b$B', '$B$b'] ---------- assignee: -> ezio.melotti resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 03:56:44 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Apr 2012 01:56:44 +0000 Subject: [issue14513] IDLE icon switched and switches on Windows taskbar In-Reply-To: <1333654492.57.0.20461784389.issue14513@psf.upfronthosting.co.za> Message-ID: <1333677404.82.0.616726863092.issue14513@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I tried again and 3.2.3rc2 is working. The IDLE icon appears and right clicking gives its title as IDLE (Python GUI). 3.3.0a2 is worse than I reported. The reason the icon changes to the pythonw icon is because that is what gets pinned, not IDLE. Right clicking the Tk icon actually says pythonw. A bare pythonw process is, of course, useless. ---------- versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 04:00:29 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Apr 2012 02:00:29 +0000 Subject: [issue14514] Equivalent to tempfile.NamedTemporaryFile that deletes file at context exit Message-ID: <1333677629.14.0.589008132421.issue14514@psf.upfronthosting.co.za> New submission from R. David Murray : A common pattern (especially in writing tests) is to create a named temporary file, operate on it with tools that take the filename, and then delete the file. This pattern would be facilitated by a version of NamedTemporaryFile that deleted the named file at the end of the context, but allowed the file to continue to exist when closed. This latter requirement arises because the file cannot be opened a second time on Windows, and so needs to be closed before other operations that open it can be performed in order for the code to work cross platform. It's tempting just to change delete=True to mean delete on exit (not close) if and only if NamedTemporaryFile is being used as a context manager, but there might be backward compatibility issues with that. It might be acceptable as a feature change, though, since the likelyhood of someone closing such a tempfile inside the context and then depending on it *not* existing between then and the end of the context seems low. If that it deemed unacceptable, this could be implemented as a new flag on NamedTemporaryFile, or by changing the delete flag to take additional values (True/False == current behavior, but add delete='onclose', delete='onexit', delete='no', and document True/False as deprecated.) ---------- components: Library (Lib) messages: 157634 nosy: r.david.murray priority: normal severity: normal status: open title: Equivalent to tempfile.NamedTemporaryFile that deletes file at context exit type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 04:03:59 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 06 Apr 2012 02:03:59 +0000 Subject: [issue14507] Segfault with starmap and izip combo In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1333677839.46.0.413276523832.issue14507@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 04:07:48 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Apr 2012 02:07:48 +0000 Subject: [issue14515] tempfile.TemporaryDirectory documented as returning object but returns name Message-ID: <1333678068.19.0.790451967958.issue14515@psf.upfronthosting.co.za> New submission from R. David Murray : The title pretty much says it all. I believe the behavior is correct (more useful than returning an object that is only useful for obtaining the name) even though it is unusual for context managers. In any case there is plenty of code using the existing behavior, so I think this is a doc bug. ---------- assignee: docs at python components: Documentation messages: 157635 nosy: docs at python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: tempfile.TemporaryDirectory documented as returning object but returns name type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 04:28:27 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 06 Apr 2012 02:28:27 +0000 Subject: [issue12567] curses implementation of Unicode is wrong in Python 3 In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za> Message-ID: <1333679307.79.0.92330777599.issue12567@psf.upfronthosting.co.za> Ned Deily added the comment: Nicholas, please open a new issue documenting which Python 3.3 you are using, from which python.org installer or the ./configure parameters if you built it yourself (and whether you supplied a version of GNU readline or used the Apple default of BSD libedit) and an example of how to reproduce the error. Please don't add to closed issues. Note also there is a known open issue with the 32-bit-only OS X installer for 3.3 where the _curses module does not build (Issue14225) with an older version of GNU readline. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 04:46:25 2012 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 06 Apr 2012 02:46:25 +0000 Subject: [issue14514] Equivalent to tempfile.NamedTemporaryFile that deletes file at context exit In-Reply-To: <1333677629.14.0.589008132421.issue14514@psf.upfronthosting.co.za> Message-ID: <1333680385.24.0.538092097843.issue14514@psf.upfronthosting.co.za> Eric V. Smith added the comment: See also issue 14243. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 04:52:13 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Apr 2012 02:52:13 +0000 Subject: [issue14514] Equivalent to tempfile.NamedTemporaryFile that deletes file at context exit In-Reply-To: <1333677629.14.0.589008132421.issue14514@psf.upfronthosting.co.za> Message-ID: <1333680733.73.0.570489324276.issue14514@psf.upfronthosting.co.za> R. David Murray added the comment: Grr. I did a search first, and even used google because I know search is currently broken, and I did not find that issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 04:55:40 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Apr 2012 02:55:40 +0000 Subject: [issue14243] NamedTemporaryFile unusable under Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1333680940.47.0.764847262874.issue14243@psf.upfronthosting.co.za> R. David Murray added the comment: See issue 14514 for an alternate proposal to solve this. I did search before I opened that issue, but search is currently somewhat broken and I did not find this issue. I'm not marking it as a dup because my proposal is really a new feature. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 05:01:29 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 06 Apr 2012 03:01:29 +0000 Subject: [issue14492] pdeps.py has_key In-Reply-To: <1333541422.42.0.575169190211.issue14492@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e9b8115c5b25 by R David Murray in branch '3.2': #14492: fix some bugs in Tools/scripts/pdeps.py. http://hg.python.org/cpython/rev/e9b8115c5b25 New changeset 26a7cc129b3d by R David Murray in branch 'default': Merge #14492: fix some bugs in Tools/scripts/pdeps.py. http://hg.python.org/cpython/rev/26a7cc129b3d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 05:05:17 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Apr 2012 03:05:17 +0000 Subject: [issue14492] pdeps.py has_key In-Reply-To: <1333541422.42.0.575169190211.issue14492@psf.upfronthosting.co.za> Message-ID: <1333681517.89.0.00868924895638.issue14492@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Popa. I made some style changes to the tests, but otherwise used your patch. One small note: your might want to see about setting your editor to show whitespace at the ends of lines, or use the 'make patchcheck' command to check for whitespace. Our commit hooks reject files that have lines with trailing whitespace, since it tends to clutter up diffs. ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 06:52:40 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Fri, 06 Apr 2012 04:52:40 +0000 Subject: [issue7057] tkinter doc: more 3.x updates In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za> Message-ID: <1333687960.73.0.477855761907.issue7057@psf.upfronthosting.co.za> Ramchandra Apte added the comment: "Tkinter uses the Xlib library to draw graphics on the screen" should be "Tkinter uses the Xlib library on Linux to draw graphics on the screen" ---------- nosy: +ramchandra.apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 06:59:34 2012 From: report at bugs.python.org (Jim Jewett) Date: Fri, 06 Apr 2012 04:59:34 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333661578.3326.12.camel@localhost.localdomain> Message-ID: Jim Jewett added the comment: On Thu, Apr 5, 2012 at 5:38 PM, Antoine Pitrou wrote: > Antoine Pitrou added the comment: > Not sure what you're talking about. The doc patch is about unacquired > locks, not locks that someone else (another thread) holds. Isn't one common reason for not being able to acquire a lock that someone else was already holding it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 07:31:24 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 06 Apr 2012 05:31:24 +0000 Subject: [issue7057] tkinter doc: more 3.x updates In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za> Message-ID: <1333690284.75.0.137966416626.issue7057@psf.upfronthosting.co.za> Ned Deily added the comment: The use of Xlib is not limited to Linux; most Unix-y platforms supported by Python have Xlib-based Tk versions available. But it is correct that there are Tk implementations that do not use X11 as their window server, for example, the native Tk implementations on Windows and Mac OS X. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 07:38:26 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 06 Apr 2012 05:38:26 +0000 Subject: [issue14258] Better explain re.LOCALE and re.UNICODE for \S and \W In-Reply-To: <1331522526.82.0.873716298557.issue14258@psf.upfronthosting.co.za> Message-ID: <1333690706.6.0.543250248239.issue14258@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Well, I would like to correct this further and add clarification based on the current implementation (_sre.c) The definition of LOCALE Space is this - #define SRE_LOC_IS_SPACE(ch) (!((ch) & ~255) ? isspace((ch)) : 0) And the definition of NON_SPACE category is a negation of space. That's it. Now, given that definition, we see for the character values higher than 255, the check is not made at all. Is it simple ascii isspace is considered when the LOCALE flag is set. And in effect, re.LOCALE flag has not extra effect on matching of space or non-white space character. After realizing this, I propose the following changes attached in the patch as a documentation fix. ---------- keywords: +patch resolution: fixed -> status: closed -> open Added file: http://bugs.python.org/file25138/issue14258.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 08:21:26 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 06 Apr 2012 06:21:26 +0000 Subject: [issue14508] gprof2html is broken In-Reply-To: <1333630868.14.0.473747405241.issue14508@psf.upfronthosting.co.za> Message-ID: <1333693286.81.0.931715589769.issue14508@psf.upfronthosting.co.za> ?ric Araujo added the comment: Should also use with statements IMO. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 08:24:10 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 06 Apr 2012 06:24:10 +0000 Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za> Message-ID: <1333693450.85.0.0451802723733.issue14465@psf.upfronthosting.co.za> ?ric Araujo added the comment: You may be able to code it entirely in the Python part of the module (adding a new parameter to Element.write and tostring). ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 08:26:20 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 06 Apr 2012 06:26:20 +0000 Subject: [issue14488] Can't install Python2.7.2 In-Reply-To: <1333510015.21.0.60972826548.issue14488@psf.upfronthosting.co.za> Message-ID: <1333693580.7.0.981628205165.issue14488@psf.upfronthosting.co.za> ?ric Araujo added the comment: Can you try with 2.7.3? ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 09:58:03 2012 From: report at bugs.python.org (Mark Shannon) Date: Fri, 06 Apr 2012 07:58:03 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1333699083.97.0.0185704862547.issue13903@psf.upfronthosting.co.za> Mark Shannon added the comment: How about changing the method-cache size in a separate patch? On my machine, reducing the method-cache size from 2**10 to 2**9 results in a very small improvement in performance (with the original dict). That way we don't get a performance regression with the new dict and the patch is better focussed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 09:59:40 2012 From: report at bugs.python.org (py.user) Date: Fri, 06 Apr 2012 07:59:40 +0000 Subject: [issue8555] tkinter doesn't see _tkinter In-Reply-To: <1272419255.64.0.530413038247.issue8555@psf.upfronthosting.co.za> Message-ID: <1333699180.11.0.26285564091.issue8555@psf.upfronthosting.co.za> py.user added the comment: testing new e-mail ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 10:10:46 2012 From: report at bugs.python.org (Popa Claudiu) Date: Fri, 06 Apr 2012 08:10:46 +0000 Subject: [issue14508] gprof2html is broken In-Reply-To: <1333630868.14.0.473747405241.issue14508@psf.upfronthosting.co.za> Message-ID: <1333699846.86.0.79803477528.issue14508@psf.upfronthosting.co.za> Popa Claudiu added the comment: Hello. I've attached the new version of the patch. I used with statement in add_escapes and the test was rewritten according to David's suggestion. ---------- Added file: http://bugs.python.org/file25139/gprof.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 10:16:32 2012 From: report at bugs.python.org (py.user) Date: Fri, 06 Apr 2012 08:16:32 +0000 Subject: =?utf-8?q?=5Bissue14236=5D_re=3A_Docstring_for_=5Cs_and_=5CS_doesn?= =?utf-8?q?=E2=80=99t_mention_Unicode?= In-Reply-To: <1331273217.26.0.527770128505.issue14236@psf.upfronthosting.co.za> Message-ID: <1333700192.11.0.180469221552.issue14236@psf.upfronthosting.co.za> Changes by py.user : ---------- title: re: Docstring for \s and \S don?t mention Unicode -> re: Docstring for \s and \S doesn?t mention Unicode _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 11:15:49 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 06 Apr 2012 09:15:49 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 068a614e9d97 by Sandro Tosi in branch 'default': Issue #14502: it's RuntimeError on 3.3 http://hg.python.org/cpython/rev/068a614e9d97 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 11:52:18 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 06 Apr 2012 09:52:18 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za> Message-ID: <1333705938.64.0.743606507616.issue14082@psf.upfronthosting.co.za> Hynek Schlawack added the comment: This ticket has a small catch: There are several namespaces. According to http://en.wikipedia.org/wiki/Xattr#Linux : - user: can be set by anyone - trusted: root only - security: root only - system: even root can?t do that, at least not in my vm I?m writing a shutil.copyxattr() first which could simple get another argument for the namespaces that should be copied. However what to do inside copy2()? I?m tending to either: 1. copy only user.* 2. ignore errors in any namespace != user Personally, I find the second approach rather non-deterministic. So I?d suggest: - copyxattr has an extra argument called namespaces with default being ['user'], so that in theory someone who wants to do something more sophisticated can do it. - copy2 copies only user.* though because that?s what you usually want. Please let me know what you think about it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 11:57:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 06 Apr 2012 09:57:33 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: Message-ID: <1333705934.3395.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > On Thu, Apr 5, 2012 at 5:38 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > > Not sure what you're talking about. The doc patch is about unacquired > > locks, not locks that someone else (another thread) holds. > > Isn't one common reason for not being able to acquire a lock that > someone else was already holding it? We're talking about *releasing* an (un)acquired lock, not acquiring it again... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 12:22:10 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 06 Apr 2012 10:22:10 +0000 Subject: [issue14516] test_tools assumes BUILDDIR=SRCDIR Message-ID: <1333707730.38.0.628831175594.issue14516@psf.upfronthosting.co.za> New submission from Ronald Oussoren : When I run "make tests" I get (amongst others) the following test failure: ====================================================================== FAIL: test_noargs (test.test_tools.ReindentTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/ronald/Projects/python/rw/default/Lib/test/test_tools.py", line 30, in test_noargs assert_python_ok(self.script) File "/Users/ronald/Projects/python/rw/default/Lib/test/script_helper.py", line 53, in assert_python_ok return _assert_python(True, *args, **env_vars) File "/Users/ronald/Projects/python/rw/default/Lib/test/script_helper.py", line 45, in _assert_python "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore'))) AssertionError: Process return code is 2, stderr follows: /Users/ronald/Projects/python/rw/default/build/python.exe: can't open file '/Users/ronald/Projects/python/rw/default/build/Tools/scripts/reindent.py': [Errno 2] No such file or directory This is because the script is actually "/Users/ronald/Projects/python/rw/default/Tools/scripts/reindent.py". The attached patch fixes the issue. (assigned to eric because he introduced these tests, unless there are objections I'll commit during the weekend) ---------- assignee: eric.araujo components: Tests files: test_tools.patch keywords: easy, needs review, patch messages: 157655 nosy: eric.araujo, ronaldoussoren priority: normal severity: normal stage: needs patch status: open title: test_tools assumes BUILDDIR=SRCDIR type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file25140/test_tools.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 12:33:49 2012 From: report at bugs.python.org (Rik Poggi) Date: Fri, 06 Apr 2012 10:33:49 +0000 Subject: [issue11060] distutils2 sdist does not complain about version that is not PEP 386 compliant In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za> Message-ID: <1333708429.39.0.047053999447.issue11060@psf.upfronthosting.co.za> Rik Poggi added the comment: Thanks, I'll wait! In the meanwhile I couldn't help to dig a little deeper and found that the Metadata class is currently logging a warning. Should the commands raise something when there's a warning in strict mode? I was playing with the check command about this when I stumbled in an odd looking piece of code in metadata.py with a FIXME note: "# FIXME this rejects UNKNOWN, is that right?" (see attached file). I'm not sure how, but it seems related to a "random" (I couldn't find any pattern) log message that sometimes give: "'UNKNOWN': '0.4.5dev' is not a valid version (field 'Version')" and others: "'Name': '0.4.5dev' is not a valid version (field 'Version')" (I had this with consecutive execution from a simple test that I wrote in test_command_check, with metadata['name'] == 'Name'). I hoped to not have wasted your time, but I thought that it could may be related to this bug since it seems that the version gets rightfully (but strangefully) warned as not valid from this "middle-layer" check point. ---------- Added file: http://bugs.python.org/file25141/metadata_set_extract.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 12:47:13 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 06 Apr 2012 10:47:13 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1333709233.08.0.762569530104.issue9141@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: New patch with explicit mutually exclusive flags and better comments. ---------- Added file: http://bugs.python.org/file25142/ob_is_gc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 12:53:44 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 06 Apr 2012 10:53:44 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1333709624.98.0.81096324183.issue9141@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Thanks for your comments Jim. They made me realize that the patch was incomplete. What is needed are two mutually exclusive flags that override the presence of the tp_del slot. This addresses your 1) point and is the case for Generators. I don't think 2 is important. Does the context of the call matter? It is merely a question of whether a finalizer will or will not do something trivial. Finalizers implemented in python can never run from garbage collection. the potential to do harm is simply too great. Which is why these extensions are purely the domain of specialized C extensions. Hence I don't think adding another slot, or allowing self-declared idempotent python finalizers to run during cleanup is a good idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 13:24:57 2012 From: report at bugs.python.org (Christophe Benoit) Date: Fri, 06 Apr 2012 11:24:57 +0000 Subject: [issue14517] Recompilation of sources with Distutils Message-ID: <1333711497.18.0.995661570344.issue14517@psf.upfronthosting.co.za> New submission from Christophe Benoit : When using distutils to build a C-extension, I have noticed that my C-sources were recompiled as soon as one source file has been touched; from python 2.6. This was not the case with previous python versions. ---------- assignee: eric.araujo components: Distutils messages: 157659 nosy: cbenoit, eric.araujo, tarek priority: normal severity: normal status: open title: Recompilation of sources with Distutils type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 13:46:30 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 06 Apr 2012 11:46:30 +0000 Subject: [issue10576] Add a progress callback to gcmodule In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za> Message-ID: <1333712790.38.0.321775859702.issue10576@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: You are right, I was thinking more of pyobject attributes. I'll fix this then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 13:46:40 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 06 Apr 2012 11:46:40 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333712800.08.0.310829799707.issue14310@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- Removed message: http://bugs.python.org/msg157189 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 13:50:35 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 06 Apr 2012 11:50:35 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333713035.7.0.647347425044.issue14310@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Not much happening on python-dev. Perhaps this is not so controversial. http://www.mail-archive.com/python-dev at python.org/msg66206.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 13:59:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 06 Apr 2012 11:59:05 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333713545.16.0.250178850928.issue14310@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I have one question: you're simply doing a binary copy of the WSAPROTOCOL_INFO structure. Does it mean sharing wouldn't work between e.g. different MSVC builds of Python (if the structure is different), or between a 32-bit and a 64-bit Python? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 14:08:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 06 Apr 2012 12:08:27 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333714107.88.0.445541158984.issue14310@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Comments about the patch: - versionadded should be 3.3, not 3.4 - MultiprocessingFunc would deserve a meaningful, PEP8 name; it should also probably be a classmethod on TestSocketSharing - please use PEP8 for comments (a space after the "#") - it would be nice to have a test for the ValueError when passing a bytes object of the wrong size - also, there should be a test that the "family", "type" and "proto" attributes are correctly set on the fromshare() result (perhaps "timeout" too) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 15:38:38 2012 From: report at bugs.python.org (YunJian) Date: Fri, 06 Apr 2012 13:38:38 +0000 Subject: [issue14510] Regular Expression "+" perform wrong repeat In-Reply-To: <1333642106.13.0.523608559084.issue14510@psf.upfronthosting.co.za> Message-ID: <1333719513.85782.YahooMailNeo@web15301.mail.cnb.yahoo.com> YunJian added the comment: Well, maybe I had never understood this though I use RE oftenly, this is the first time I met this and in my mind capture should not perform like this, thank you very much! ________________________________ ???? Matthew Barnett ???? tld5yj at yahoo.com.cn ????? 2012?4?6?, ???, ?? 12:08 ??: [issue14510] Regular Expression "+" perform wrong repeat Matthew Barnett added the comment: If a capture group is repeated, as in r'(\$.)+', only its last match is returned. ---------- _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 15:46:21 2012 From: report at bugs.python.org (YunJian) Date: Fri, 06 Apr 2012 13:46:21 +0000 Subject: [issue14510] Regular Expression "+" perform wrong repeat In-Reply-To: <1333676465.43.0.537272251922.issue14510@psf.upfronthosting.co.za> Message-ID: <1333719976.94854.YahooMailNeo@web15303.mail.cnb.yahoo.com> YunJian added the comment: If that was caused by capture, I think I should learn and use it from start because it gave a result I didn't want but in the way I want, thank you very much, I will be more careful next time, thank you! ________________________________ ???? Ezio Melotti ???? tld5yj at yahoo.com.cn ????? 2012?4?6?, ???, ?? 9:41 ??: [issue14510] Regular Expression "+" perform wrong repeat Ezio Melotti added the comment: ['$b$B', '$B$b'] ---------- assignee:? -> ezio.melotti resolution:? -> invalid stage:? -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 16:15:23 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 06 Apr 2012 14:15:23 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333721723.19.0.0656868101797.issue14310@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: The binary copy: This is a winsock2 feature. There is no difference in layout between 32 bits and 64 bits. I also don't think there is a difference between SDK versions. However, strangely, there is a difference between unicode and non-unicode builds. But since we are using this in python3, which always uses the same unicode setting, this shouldn't be an issue. I'll take your other comments into account and produce a new patch. Similar to socket.dup(), the socket shared is assumed to be in "blockin" mode (this his how its timeout is initialized). We can test for that too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 17:02:10 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 06 Apr 2012 15:02:10 +0000 Subject: [issue14516] test_tools assumes BUILDDIR=SRCDIR In-Reply-To: <1333707730.38.0.628831175594.issue14516@psf.upfronthosting.co.za> Message-ID: <1333724530.7.0.916594282482.issue14516@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for catching this. The definition of projectbase and srcdir is not clear to me, I always have to use trial and error to find the right one in my tests. The patch must be applied to all three branches; let me know if I should do it. ---------- versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 18:30:17 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 06 Apr 2012 16:30:17 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za> Message-ID: <1333729817.54.0.986181609425.issue14455@psf.upfronthosting.co.za> ?ric Araujo added the comment: Keep it simple: if a few functions work, there is no need at all to add classes. Before doing more work though I suggest you wait for the feedback of the Mac maintainers. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 18:44:17 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 06 Apr 2012 16:44:17 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za> Message-ID: <1333730657.7.0.902097712736.issue14455@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I (as one of the Mac maintainers) like the new functionality, but would like to see some changes: 1) as others have noted it is odd that binary and json plists can be read but not written 2) there need to be tests, and I'd add two or even three set of tests: a. tests that read pre-generated files in the various formats (tests that we're compatible with the format generated by Apple) b. tests that use Apple tools to generated plists in various formats, and check that the library can read them (these tests would be skipped on platforms other than OSX) c. if there are read and write functions: check that the writer generates files that can be read back in. 3) there is a new public function for reading binary plist files, I'd keep that private and add a "format" argument to readPlist when there is a need for forcing the usage of a specific format (and to mirror the (currently hypothetical) format argument for writePlist). Don't worry about rearchitecturing plistlib, it might need work in that regard but that need not be part of this issue and makes it harder to review the changes. I'm also far from convinced that a redesign of the code is needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 18:51:08 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 06 Apr 2012 16:51:08 +0000 Subject: [issue10197] subprocess.getoutput fails on win32 In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za> Message-ID: <1333731068.37.0.486526511108.issue10197@psf.upfronthosting.co.za> ?ric Araujo added the comment: I think that adding safer wrappers and deprecating things are valuable but different bugs. In the short term, we could apply the proposed small patch to just fix the issue at hand. Can one of the Windows experts weigh in? The patch does this: if mswindows: pipe = os.popen('( ' + cmd + ' ) 2>&1', 'r') else: pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') It was tested manually; a test should be simple to write. ---------- keywords: +needs review nosy: +tim.golden stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 18:54:40 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 06 Apr 2012 16:54:40 +0000 Subject: [issue14412] Sqlite Integer Fields In-Reply-To: <1332759601.85.0.320524122366.issue14412@psf.upfronthosting.co.za> Message-ID: <1333731280.04.0.192148699996.issue14412@psf.upfronthosting.co.za> Benjamin Peterson added the comment: What steps can we take to further debug/address this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 19:09:00 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 06 Apr 2012 17:09:00 +0000 Subject: [issue14477] Rietveld test issue In-Reply-To: <1333382689.52.0.891466185612.issue14477@psf.upfronthosting.co.za> Message-ID: <1333732140.74.0.744596490014.issue14477@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 19:10:46 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 06 Apr 2012 17:10:46 +0000 Subject: [issue14469] Python 3 documentation links In-Reply-To: <1333298580.51.0.119482106967.issue14469@psf.upfronthosting.co.za> Message-ID: <1333732246.73.0.706864725215.issue14469@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo versions: -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 19:13:28 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 06 Apr 2012 17:13:28 +0000 Subject: [issue14500] test_importlib fails in refleak mode In-Reply-To: <1333577594.41.0.849099540387.issue14500@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 1c3bd0cc3eca by Brett Cannon in branch 'default': Issue #14500: Fix importlib.test.import_.test_packages to clean up http://hg.python.org/cpython/rev/1c3bd0cc3eca ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 19:13:50 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 06 Apr 2012 17:13:50 +0000 Subject: [issue14500] test_importlib fails in refleak mode In-Reply-To: <1333577594.41.0.849099540387.issue14500@psf.upfronthosting.co.za> Message-ID: <1333732430.31.0.971397800296.issue14500@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 19:14:13 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 06 Apr 2012 17:14:13 +0000 Subject: [issue6225] Fixing several minor bugs in Tkinter.Canvas and one in Misc._configure In-Reply-To: <1244325396.24.0.788727463424.issue6225@psf.upfronthosting.co.za> Message-ID: <1333732453.66.0.588160394183.issue6225@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- versions: +Python 3.3 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 19:48:17 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Apr 2012 17:48:17 +0000 Subject: [issue14341] sporadic (?) test_urllib2 failures In-Reply-To: <1331943969.2.0.17966534502.issue14341@psf.upfronthosting.co.za> Message-ID: <1333734497.84.0.988206739483.issue14341@psf.upfronthosting.co.za> R. David Murray added the comment: If one changes the stacklevel in the DeprecationWarnings in the library to '2' instead of '1' (I believe it should be '2'), then an interesting array of deprecation warnings are issued...including from cookiejar code. Most of them are in the urllib2 tests, though, and obviously they aren't being correctly protected. I'm not sure what is causing the deprecation test to sometimes succeed and sometimes fail, though. Running python -m unittest.test_urllib2 consistently fails for me without the 1->2 change, and consistently passes (but with more warnings) with it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 20:37:25 2012 From: report at bugs.python.org (Daniel Swanson) Date: Fri, 06 Apr 2012 18:37:25 +0000 Subject: [issue13749] socketserver can't stop In-Reply-To: <1326136769.56.0.386749729049.issue13749@psf.upfronthosting.co.za> Message-ID: <1333737445.67.0.92930472631.issue13749@psf.upfronthosting.co.za> Daniel Swanson added the comment: what about this? def __init__(...): ... self.stop = False while True: (do stuff) if self.stop: break def quit(or whatever it's called): self.stop = True That would work without the backwards copatability issue right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 20:48:27 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 06 Apr 2012 18:48:27 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1333738107.87.0.550020933542.issue2377@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, -v/PYTHONVERBOSE is as done as it is going to be by me. Next up is (attempting) Windows registry stuff. After that I will push to default with test_trace and test_pydoc skipped so others can help me with those. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 20:50:26 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 06 Apr 2012 18:50:26 +0000 Subject: [issue14341] sporadic (?) test_urllib2 failures In-Reply-To: <1331943969.2.0.17966534502.issue14341@psf.upfronthosting.co.za> Message-ID: <1333738226.48.0.275105105911.issue14341@psf.upfronthosting.co.za> Stefan Krah added the comment: Running test_http_cookiejar and test_urllib2 in succession always fails here. The same thing occurs when running test_urllib2 twice: $ ./python -m test test_http_cookiejar test_urllib2 [1/2] test_http_cookiejar [2/2] test_urllib2 test test_urllib2 failed -- Traceback (most recent call last): File "/home/stefan/pydev/cpython/Lib/test/test_urllib2.py", line 628, in test_method_deprecations req.get_host() File "/home/stefan/pydev/cpython/Lib/contextlib.py", line 54, in __exit__ next(self.gen) File "/home/stefan/pydev/cpython/Lib/test/support.py", line 766, in _filterwarnings missing[0]) AssertionError: filter ('', DeprecationWarning) did not catch any warning 1 test OK. 1 test failed: test_urllib2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 21:01:56 2012 From: report at bugs.python.org (Daniel Swanson) Date: Fri, 06 Apr 2012 19:01:56 +0000 Subject: [issue13749] socketserver can't stop In-Reply-To: <1326136769.56.0.386749729049.issue13749@psf.upfronthosting.co.za> Message-ID: <1333738916.69.0.021115641143.issue13749@psf.upfronthosting.co.za> Daniel Swanson added the comment: Or even better: def __init__(...): ... self.stop = False while not self.stop: (do stuff) def quit(or whatever it's called): self.stop = True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 21:37:14 2012 From: report at bugs.python.org (Jim Jewett) Date: Fri, 06 Apr 2012 19:37:14 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333705934.3395.0.camel@localhost.localdomain> Message-ID: Jim Jewett added the comment: On Fri, Apr 6, 2012 at 5:57 AM, Antoine Pitrou wrote: > Antoine Pitrou added the comment: >> > Not sure what you're talking about. The doc patch is about unacquired >> > locks, not locks that someone else (another thread) holds. >> Isn't one common reason for not being able to acquire a lock that >> someone else was already holding it? > We're talking about *releasing* an (un)acquired lock, not acquiring it > again... Right, but I thought the original motivation was concern over a race condition in the lock acquisition. lock.acquire() try: # What if something happens here, during try setup? Leak? foo() finally: lock.release() vs try: lock.acquire() foo() finally: lock.release() # But what if the acquire failed? -jJ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 21:42:27 2012 From: report at bugs.python.org (Daniel Holth) Date: Fri, 06 Apr 2012 19:42:27 +0000 Subject: [issue14518] Add bcrypt $2a$ to crypt.py Message-ID: <1333741347.69.0.597224923936.issue14518@psf.upfronthosting.co.za> New submission from Daniel Holth : The prefix for bcrypt '$2a$' is supported on many systems and could be added to crypt.py Could the documentation mention the available rounds parameter for most of these newer hashes? And that Unicode strings are automatically converted to utf-8 before being passed into the OS crypt() function, or is that just assumed to be common knowledge? ---------- messages: 157679 nosy: dholth priority: normal severity: normal status: open title: Add bcrypt $2a$ to crypt.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 21:42:57 2012 From: report at bugs.python.org (Daniel Holth) Date: Fri, 06 Apr 2012 19:42:57 +0000 Subject: [issue14518] Add bcrypt $2a$ to crypt.py In-Reply-To: <1333741347.69.0.597224923936.issue14518@psf.upfronthosting.co.za> Message-ID: <1333741377.55.0.573898572373.issue14518@psf.upfronthosting.co.za> Changes by Daniel Holth : ---------- components: +Library (Lib) versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 21:43:47 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 06 Apr 2012 19:43:47 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za> Message-ID: <1333741427.67.0.875101874385.issue14502@psf.upfronthosting.co.za> R. David Murray added the comment: It doesn't matter *how* you get to the situation where you are releasing a lock that hasn't been acquired, the point is to document what actually happens when you do the release. And just yesterday I needed to know this, since I have a lock that may or may not be currently held when I release it, and now I know I can just catch RuntimeError in that case. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 21:51:51 2012 From: report at bugs.python.org (Jim Jewett) Date: Fri, 06 Apr 2012 19:51:51 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1333741911.38.0.76066357888.issue9141@psf.upfronthosting.co.za> Jim Jewett added the comment: > I don't think 2 is important. Does the context of the call matter? > It is merely a question of whether a finalizer will or will not do > something trivial. It would affect how I would write such functions. If I knew that it wouldn't be called until the object was already garbage, then I be inclined to move parts of tp_del there, and break the cycle. > Finalizers implemented in python can never run from garbage > collection. the potential to do harm is simply too great. __del__ methods do run, even if an object was collected by the cycle detector. And they can't do any harm that couldn't also be done by a C finalizer. The only change from today's situation with __del__ is that once an object is known to be cyclic garbage, it would get a chance to break the cycles itself (or, admittedly, to rescue itself) before the cycle-breaker began making arbitrary decisions or gave up and stuffed it in the uncollectable list. Even in your case, instead of setting a timer to clean out garbage, you could have the garbage itself notify your cleaner that it needed attention. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 22:03:20 2012 From: report at bugs.python.org (Daniel Stutzbach) Date: Fri, 06 Apr 2012 20:03:20 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1333741911.38.0.76066357888.issue9141@psf.upfronthosting.co.za> Message-ID: Daniel Stutzbach added the comment: On Fri, Apr 6, 2012 at 12:51 PM, Jim Jewett wrote: > __del__ methods do run, even if an object was collected by the cycle > detector. And they can't do any harm that couldn't also be done by a C > finalizer. > No, if an object with a __del__ method is part of a cycle, it is not collected. The objects get appended to gc.garbage instead. See: http://docs.python.org/py3k/library/gc.html#gc.garbage ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 22:05:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 06 Apr 2012 20:05:25 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1333738107.87.0.550020933542.issue2377@psf.upfronthosting.co.za> Message-ID: <1333742404.3367.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > OK, -v/PYTHONVERBOSE is as done as it is going to be by me. Next up is > (attempting) Windows registry stuff. After that I will push to default > with test_trace and test_pydoc skipped so others can help me with > those. Skipped? How so? I think it would be better if you tried to debug them. I don't think we have anyone active knowledgeable on either trace or pydoc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 22:14:41 2012 From: report at bugs.python.org (Jim Jewett) Date: Fri, 06 Apr 2012 20:14:41 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1333743281.1.0.12833431308.issue14478@psf.upfronthosting.co.za> Jim Jewett added the comment: @Jimbofbx: You are correct that a value has to be reserved to indicate that the hash hasn't been (or can't be) computed, but python uses -1 instead of zero. An integer can't return itself because a hash is an unboxed integer; that said, there is a fast path for small enough integers. You can see the actual code at http://hg.python.org/cpython/file/388016438a50/Objects/longobject.c#l2581 Since it is too late for 3.2, I suggest closing this and opening a separate 3.3 issue if the existing improvements are not sufficient. ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 22:24:42 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 06 Apr 2012 20:24:42 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1333743882.45.0.896174340471.issue9141@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Right Daniel, but currently an exception is made for Generator objects. The generator can tell that the finalizer won't do anything and then allow collection regardless. It knows the finalizer and that in its state it will at most do some Py_DECREF operations. This patch aims to generalize this exception mechanism, and also its opposite, so that we don?t need to rely on the presence of the finalizer slot to decide. We can then remove a silly function from the public (but undocumented) API. Of course, you can only allow collectino of an object with a finalizer if you know for sure that it will not do anything but Py_DECREF. This is possible for generators because they are not an inheritable class. But we could never do this in general for a python class. Even running .py code from the GC collector cycle would crash everything instantly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 22:28:48 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 06 Apr 2012 20:28:48 +0000 Subject: [issue14511] _static/opensearch.xml for Python 3.2 docs directs searches to 3.3 docs In-Reply-To: <1333640035.04.0.466278675781.issue14511@psf.upfronthosting.co.za> Message-ID: <1333744128.33.0.96221345364.issue14511@psf.upfronthosting.co.za> ?ric Araujo added the comment: Will fix, thanks for the report. ---------- assignee: docs at python -> eric.araujo versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 22:34:29 2012 From: report at bugs.python.org (d9pouces) Date: Fri, 06 Apr 2012 20:34:29 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za> Message-ID: <1333744469.07.0.194299819194.issue14455@psf.upfronthosting.co.za> d9pouces added the comment: I'm working on a class, BinaryPlistParser, which allow to both read and write binary files. I've also added a parameter fmt to writePlist and readPlist, to specify the format ('json', 'xml1' or 'binary1', using XML by default). These constants are used by Apple for its plutil program. I'm now working on integrating these three formats to the test_plistlib.py. However, the json is less expressive than the other two, since it cannot handle dates. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 22:35:11 2012 From: report at bugs.python.org (Daniel Stutzbach) Date: Fri, 06 Apr 2012 20:35:11 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1333744511.75.0.67434985564.issue9141@psf.upfronthosting.co.za> Daniel Stutzbach added the comment: Are __del__ and tp_del getting conflated in this conversation? I don't see a __del__ method on generator objects: filfre:$ python3.1 Python 3.1.2 (r312:79147, Dec 9 2011, 20:47:34) [GCC 4.4.3] on linux2 >>> (i for i in range(5)).__del__ Traceback (most recent call last): File "", line 1, in AttributeError: 'generator' object has no attribute '__del__' but I may be missing something. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 22:52:51 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 06 Apr 2012 20:52:51 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1333745571.73.0.76160063749.issue9141@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: typeobject.c: TPSLOT("__del__", tp_del, slot_tp_del, NULL, ""), I'm not super-familiar with how typeobjects and slots work, but I imagine that if a type is defined with a __del__ member, then the tp_del slot is automatically filled out. The converse need not be true. At any rate, the non-zero-ness of tp_del is what gcmodule.c uses to find out if an object has a finaliser. There is a code rudiment present in gcmodule.c, that hints at an earlier time when '__del__' was looked up but that string is not actually used. That can be removed to, eiter as part of this patch or separately since it should be quite uncontroversial. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 22:58:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 06 Apr 2012 20:58:03 +0000 Subject: [issue14518] Add bcrypt $2a$ to crypt.py In-Reply-To: <1333741347.69.0.597224923936.issue14518@psf.upfronthosting.co.za> Message-ID: <1333745883.34.0.671449818413.issue14518@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This requires someone to propose a patch. If you are interested, you can read the Developer's Guide - http://docs.python.org/devguide/ - for more information on how to contribute. ---------- nosy: +jafo, pitrou stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 22:58:53 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 06 Apr 2012 20:58:53 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1333745933.89.0.630083266052.issue14468@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 23:32:17 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Apr 2012 21:32:17 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1333747937.96.0.638295527547.issue14468@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree, for reasons stated. Having to skip over the wrong instructions made getting started a bit harder for me. I also think TortoiseHG should get more than just a mention. The initial re-creation of the recent DAG for each branch when starting up Workbench takes some time, but having the graph makes it immediately obvious whether the repository is in a proper state -- two heads for default and 2.7, three for 3.2 -- both before starting work after pulling from py.org and again when ready to push changes back. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 23:36:25 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 06 Apr 2012 21:36:25 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333748185.7.0.176951622602.issue14310@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Here is a new patch, with more tests. Note that the process worker function can't be a member function because of how multiprocessing works on Windows. ---------- Added file: http://bugs.python.org/file25143/duplicate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 23:37:34 2012 From: report at bugs.python.org (Jim Jewett) Date: Fri, 06 Apr 2012 21:37:34 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za> Message-ID: <1333748254.68.0.124351557565.issue14502@psf.upfronthosting.co.za> Jim Jewett added the comment: > I have a lock that may or may not be currently held when I release it, > and now I know I can just catch RuntimeError in that case. Only if you're willing to make assumptions about the threading model and the source of locks. And I fear the current change overpromises. For example, the LockType from _dummy_thread raises an error not based on RuntimeError, and has comments suggesting it might stop raising entirely. I believe I have seen other Lock-emulation code which also does not raise an error, though the closest I can come to finding it right now is logging_releaseLock() when the import of either _thread or threading failed. Starting with http://hg.python.org/cpython/file/acea9d95a6d8/Doc/library/threading.rst I would prefer to change to following two sentences: If an attempt is made to release an unlocked lock, a :exc:`RuntimeError` will be raised. ... When invoked on an unlocked lock, a :exc:`ThreadError` is raised. in any of the following ways: (a) Change "will be"/"is" --> "may be", so it isn't promised: If an attempt is made to release an unlocked lock, a :exc:`RuntimeError` may be raised. ... When invoked on an unlocked lock, a :exc:`ThreadError` may be raised. (b) Clarify that it is implementation-specific If an attempt is made to release an unlocked _thread.lock, a :exc:`RuntimeError` will be raised. ... When invoked on an unlocked _thread.lock, a :exc:`ThreadError` is raised. (and add to the caveats) Locks provided by other modules may have slightly different behavior, particularly when an an operation fails. For example, unlocking without first acquiring may raise a different error, or may not raise at all. (c) Clarify that alternatives are buggy (and fix those in the stdlib) If an attempt is made to release an unlocked lock, a :exc:`RuntimeError` will be raised. ... When invoked on an unlocked lock, a :exc:`ThreadError` is be raised. (and add to the caveats) Historically, many Locks have followed a slightly different contract, particularly when an an operation fails. For example, unlocking without first acquiring might raise a different error, or might not even raise at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 23:39:41 2012 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 06 Apr 2012 21:39:41 +0000 Subject: [issue14452] SysLogHandler sends invalid messages when using unicode In-Reply-To: <1333105941.84.0.159307303218.issue14452@psf.upfronthosting.co.za> Message-ID: <1333748381.27.0.608009610648.issue14452@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- assignee: -> vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 23:41:46 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Apr 2012 21:41:46 +0000 Subject: [issue14488] Can't install Python2.7.2 In-Reply-To: <1333510015.21.0.60972826548.issue14488@psf.upfronthosting.co.za> Message-ID: <1333748506.31.0.146591542404.issue14488@psf.upfronthosting.co.za> Terry J. Reedy added the comment: What version of Windows? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 23:42:21 2012 From: report at bugs.python.org (Jerzy Kozera) Date: Fri, 06 Apr 2012 21:42:21 +0000 Subject: [issue7978] SocketServer doesn't handle syscall interruption In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za> Message-ID: <1333748541.82.0.698156714823.issue7978@psf.upfronthosting.co.za> Jerzy Kozera added the comment: I've updated the patch according to suggestions from Gregory P. Smith. Thanks to a change from #12555 (PEP 3151) now just checking for OSError is enough. (I've decided to use mocked select() instead of calling alarm() to avoid depending on timing.) ---------- nosy: +Jerzy.Kozera Added file: http://bugs.python.org/file25144/socketserver_eintr_20120406.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 23:45:49 2012 From: report at bugs.python.org (Roumen Petrov) Date: Fri, 06 Apr 2012 21:45:49 +0000 Subject: [issue14516] test_tools assumes BUILDDIR=SRCDIR In-Reply-To: <1333707730.38.0.628831175594.issue14516@psf.upfronthosting.co.za> Message-ID: <1333748749.93.0.186206409376.issue14516@psf.upfronthosting.co.za> Roumen Petrov added the comment: another one is in Lib/packaging/tests/support.py - should be from same commit ---------- nosy: +rpetrov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 23:47:50 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Apr 2012 21:47:50 +0000 Subject: [issue14503] docs: 2 code examples not Pygmented (syntax color coded) In-Reply-To: <1333613053.66.0.675522025893.issue14503@psf.upfronthosting.co.za> Message-ID: <1333748870.65.0.821771886037.issue14503@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> needs patch title: docs:Code not highlighted -> docs: 2 code examples not Pygmented (syntax color coded) type: -> behavior versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 23:48:14 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 06 Apr 2012 21:48:14 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1333748185.7.0.176951622602.issue14310@psf.upfronthosting.co.za> Message-ID: <1333748572.3367.3.camel@localhost.localdomain> Antoine Pitrou added the comment: > Here is a new patch, with more tests. > Note that the process worker function can't be a member function > because of how multiprocessing works on Windows. Some comments: - I said classmethod, not member function; this is how test_multiprocessing works, so it should be possible... - why did you change the gethostbyname() tests? - before using AF_INET6, you might have to test that IPv6 is available on the test machine (I think there are variables / functions for that in test_socket) - in compareSockets: + if org.proto != 0: + self.assertEqual(sock.proto, other.proto) `sock` doesn't seem to exist at all... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 23:49:52 2012 From: report at bugs.python.org (Janice) Date: Fri, 06 Apr 2012 21:49:52 +0000 Subject: [issue14488] Can't install Python2.7.2 In-Reply-To: <1333510015.21.0.60972826548.issue14488@psf.upfronthosting.co.za> Message-ID: <1333748992.9.0.651196561678.issue14488@psf.upfronthosting.co.za> Janice added the comment: Thank you for comments, but I already fixed the problem :3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 6 23:50:09 2012 From: report at bugs.python.org (Janice) Date: Fri, 06 Apr 2012 21:50:09 +0000 Subject: [issue14488] Can't install Python2.7.2 In-Reply-To: <1333510015.21.0.60972826548.issue14488@psf.upfronthosting.co.za> Message-ID: <1333749009.73.0.551266240796.issue14488@psf.upfronthosting.co.za> Changes by Janice : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 00:00:30 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Apr 2012 22:00:30 +0000 Subject: [issue14507] Segfault with starmap and izip combo In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1333749630.26.0.473124184091.issue14507@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Win7, 64 bit, IDLE shell and editor, 3.2.3c2, 24 gb machine, added print(): I got no response for about 10 secs until a process restart happens, which I believe means that the background pythonw process stopped. If I hit ^C before that, I get the Windows segfault equivalent, a process stopped window. Then a restart, without the normal red 'keyboard interrupt' message. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 00:03:51 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 06 Apr 2012 22:03:51 +0000 Subject: [issue14507] Segfault with starmap and izip combo In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1333749831.02.0.789339253538.issue14507@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 3.3.0a2, command prompt window: 'python has stopped working' in about 2 secs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 00:18:22 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 06 Apr 2012 22:18:22 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333750702.24.0.886816204855.issue14310@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: by "memberfunction" I mean a member of the class. I tried staticmethod and it didn't work: I tried a staticmethod and it didn't work: ====================================================================== ERROR: testShare (test.test_socket.TestSocketSharing) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\pydev\cpython\lib\test\test_socket.py", line 4723, in testShare p.start() File "D:\pydev\cpython\lib\multiprocessing\process.py", line 136, in start self._popen = Popen(self) File "D:\pydev\cpython\lib\multiprocessing\forking.py", line 269, in __init__ dump(process_obj, to_child, HIGHEST_PROTOCOL) File "D:\pydev\cpython\lib\multiprocessing\forking.py", line 190, in dump ForkingPickler(file, protocol).dump(obj) _pickle.PicklingError: Can't pickle : attribute lookup builtins.function failed (Picking this kind of stuff should work of course but that's another story) But changing it to staticmethod strangely fixes it. Interesting. the gethostbynametests were an encoding mistake. Would not have been checked in but it was nice of you to notice. These are windows only tests for python 3.3. There is no need to test for IPV6. Here is yet another patch. ---------- Added file: http://bugs.python.org/file25145/duplicate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 00:19:21 2012 From: report at bugs.python.org (James Hutchison) Date: Fri, 06 Apr 2012 22:19:21 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1333750761.87.0.60812760193.issue4892@psf.upfronthosting.co.za> James Hutchison added the comment: This is an issue for me (Python 3.2). I have a custom pool that sends arguments for a function call over a pipe. I cannot send another pipe as an argument. Tim's workaround also does not work for me (win xp 32bit and 64bit) >From what I can tell, you can only send a connection as a direct argument to a function call. This limits what I can do because I cannot introduce new pipes to a worker process after it is instantiated. Using this code: def main(): from multiprocessing import Pipe, reduction i, o = Pipe() print(i); reduced = reduction.reduce_connection(i) print(reduced); newi = reduced[0](*reduced[1]) print(newi); newi.send("hi") o.recv() if __name__ == "__main__": main(); This is my output: (, (('\\\\.\\pipe\\pyc-3156-1-q5wwnr', 1756, False), True, True)) Traceback (most recent call last): File "H:\mti\secure\Flash\Reliability\Perl_Rel\Ambyx\James\bugs\test.py", line 47, in main(); File "H:\mti\secure\Flash\Reliability\Perl_Rel\Ambyx\James\bugs\test.py", line 43, in main newi.send("hi") IOError: [Errno 10038] An operation was attempted on something that is not a socket As you can see, the handle changes ---------- nosy: +Jimbofbx _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 00:20:49 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 06 Apr 2012 22:20:49 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1333750702.24.0.886816204855.issue14310@psf.upfronthosting.co.za> Message-ID: <1333750529.3367.6.camel@localhost.localdomain> Antoine Pitrou added the comment: [...] > But changing it to staticmethod strangely fixes it. Interesting. Sorry? > Here is yet another patch. Your patch is broken, it has lots of duplicate stuff... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 00:29:04 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 06 Apr 2012 22:29:04 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333751344.33.0.448854622608.issue14310@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : Removed file: http://bugs.python.org/file25145/duplicate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 00:29:10 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 06 Apr 2012 22:29:10 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333751350.26.0.315814245044.issue14310@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : Removed file: http://bugs.python.org/file25143/duplicate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 00:31:52 2012 From: report at bugs.python.org (James Hutchison) Date: Fri, 06 Apr 2012 22:31:52 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1333751512.1.0.934099166717.issue4892@psf.upfronthosting.co.za> James Hutchison added the comment: err, is it possible to edit out those file paths? I didn't intend them to be in the message. I'd appreciate it if someone with the privileges to do so could remove them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 00:32:57 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 06 Apr 2012 22:32:57 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333751577.24.0.604457091857.issue14310@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: >> But changing it to staticmethod strangely fixes it. Interesting. >Sorry? Don't be, probably not your fault. Today we have learned that we can spawn multipropcessing targets with classmethods, but not staticmethods. >Your patch is broken, it has lots of duplicate stuff... Yes, I'm sorry, it was a merging error. I'm still getting to grips with Hg. I removed the last two and added a new one. Hope you like it. ---------- Added file: http://bugs.python.org/file25146/duplicate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 00:40:14 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 06 Apr 2012 22:40:14 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1333751577.24.0.604457091857.issue14310@psf.upfronthosting.co.za> Message-ID: <1333751693.3367.7.camel@localhost.localdomain> Antoine Pitrou added the comment: > Yes, I'm sorry, it was a merging error. I'm still getting to grips > with Hg. I removed the last two and added a new one. Hope you like > it. It's still broken. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 00:45:31 2012 From: report at bugs.python.org (Jim Jewett) Date: Fri, 06 Apr 2012 22:45:31 +0000 Subject: [issue6167] Tkinter.Scrollbar: the activate method needs to return a value, and set should take only two args In-Reply-To: <1243887092.8.0.492821608561.issue6167@psf.upfronthosting.co.za> Message-ID: <1333752331.34.0.503158251741.issue6167@psf.upfronthosting.co.za> Jim Jewett added the comment: (1) Why did you change the name of the parameter from index to element? If the underlying engine also accepts indices (e.g., self.activate(4) ) then the name should stay. If it really is only meaningful to use the name of an element -- maybe it should still stay for backwards compatibility. Or at least accept the old name too for a release. Either way, please provide a test case showing that it works under the new name; there may also be doc fixes. (I'm not sure there is documentation for this widget, though, and providing some in the first place is good, but perhaps a different task.) FWIW, http://docs.python.org/dev/library/tkinter.html#the-index-parameter suggests that the name should stay index, and can be far more than an element; migrating some of that to the docstring might be helpful. (2) It looks like the set command took *args to give some freedom. There may be extensions that take a third argument. It may well be valid to call it without any arguments, or with only one. So the signature may turn into set(first=0, last=1, *args) or some such. Whatever the answer about what arguments are really needed, there should be test cases to demonstrate this before the API is changed. ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 00:51:15 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 06 Apr 2012 22:51:15 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333752675.69.0.723386905848.issue14310@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Could you possibly be any more specific? It works for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 00:55:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 06 Apr 2012 22:55:13 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333752913.32.0.707670739372.issue14310@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Could you possibly be any more specific? It works for me. Just read it by yourself. There are still duplicate portions there: http://bugs.python.org/file25146/duplicate.patch In general, it's nicer to others to review your changes before uploading them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 01:04:27 2012 From: report at bugs.python.org (Rik Poggi) Date: Fri, 06 Apr 2012 23:04:27 +0000 Subject: [issue11060] distutils2 sdist does not complain about version that is not PEP 386 compliant In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za> Message-ID: <1333753467.43.0.939950634475.issue11060@psf.upfronthosting.co.za> Rik Poggi added the comment: My assumption that the "random" log message was related to this bug seems to be completely wrong. It seems, instead, related to a starstar call of create_dist in the support module that will loose the order (of an OrderedDict obviously). The behaviour is still strange because in order to reproduce it I had to re-run the test different. (test_star_star is the "random" failing one) Attaching the diff. ---------- Added file: http://bugs.python.org/file25147/test_support.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 02:19:56 2012 From: report at bugs.python.org (py.user) Date: Sat, 07 Apr 2012 00:19:56 +0000 Subject: [issue14519] In re's examples the example with scanf() contains wrong analog for %x, %X specifiers Message-ID: <1333757996.58.0.360922081437.issue14519@psf.upfronthosting.co.za> New submission from py.user : http://docs.python.org/py3k/library/re.html#simulating-scanf 0[xX][\dA-Fa-f]+ -> (0[xX])?[\dA-Fa-f]+ ---------- assignee: docs at python components: Documentation, Regular Expressions messages: 157711 nosy: docs at python, ezio.melotti, mrabarnett, py.user priority: normal severity: normal status: open title: In re's examples the example with scanf() contains wrong analog for %x, %X specifiers versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 03:12:20 2012 From: report at bugs.python.org (Daniel Swanson) Date: Sat, 07 Apr 2012 01:12:20 +0000 Subject: [issue13749] socketserver can't stop In-Reply-To: <1326136769.56.0.386749729049.issue13749@psf.upfronthosting.co.za> Message-ID: <1333761140.24.0.124240407735.issue13749@psf.upfronthosting.co.za> Daniel Swanson added the comment: I tryed to fix the problem, here is my attemt. ---------- Added file: http://bugs.python.org/file25148/tryfixsocketserver.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 03:18:15 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 07 Apr 2012 01:18:15 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333761495.62.0.324541497439.issue14310@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : Removed file: http://bugs.python.org/file25146/duplicate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 03:24:43 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 07 Apr 2012 01:24:43 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333761883.37.0.215283292719.issue14310@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Well, I think I have all of the merge errors out now. You?ll forgive me if I didn't notice them all at first, but this is why we review code and you would have helped me by giving me specifics, since after a time, the eyes tend to glaze over. Any other comments? ---------- Added file: http://bugs.python.org/file25149/duplicate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 04:24:39 2012 From: report at bugs.python.org (Jim Jewett) Date: Sat, 07 Apr 2012 02:24:39 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: Message-ID: Jim Jewett added the comment: On Fri, Apr 6, 2012 at 4:03 PM, Daniel Stutzbach added the comment: >> __del__ methods do run, even if an object was collected by the cycle >> detector. ?And they can't do any harm that couldn't also be done by a C >> finalizer. > No, if an object with a __del__ method is part of a cycle, it is not > collected. ?The objects get appended to gc.garbage instead. > See: ?http://docs.python.org/py3k/library/gc.html#gc.garbage They can still be collected if there is only one object with a __del__ method in the cycle. (Whether the code actually does that, it appears not to at the moment, and I won't swear by by own memory of 2.3 era code.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 04:32:17 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 07 Apr 2012 02:32:17 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za> Message-ID: <1333765937.29.0.197499608927.issue14502@psf.upfronthosting.co.za> R. David Murray added the comment: I, on the other hand, would prefer if it were made part of the API contract that an error is raised, and to fix any stdlib implementations *of that API* that don't conform to that. (That is, locks from other modules may well not follow that API, and their documentation should cover their API.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 04:45:32 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 07 Apr 2012 02:45:32 +0000 Subject: [issue14518] Add bcrypt $2a$ to crypt.py In-Reply-To: <1333741347.69.0.597224923936.issue14518@psf.upfronthosting.co.za> Message-ID: <1333766732.02.0.241398913616.issue14518@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 04:53:30 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 07 Apr 2012 02:53:30 +0000 Subject: [issue14519] In re's examples the example with scanf() contains wrong analog for %x, %X specifiers In-Reply-To: <1333757996.58.0.360922081437.issue14519@psf.upfronthosting.co.za> Message-ID: <1333767210.2.0.654825041536.issue14519@psf.upfronthosting.co.za> R. David Murray added the comment: The documentation appears to be correct to me. Can you demonstrate your suggestion with some examples? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 05:17:38 2012 From: report at bugs.python.org (py.user) Date: Sat, 07 Apr 2012 03:17:38 +0000 Subject: [issue14519] In re's examples the example with scanf() contains wrong analog for %x, %X specifiers In-Reply-To: <1333757996.58.0.360922081437.issue14519@psf.upfronthosting.co.za> Message-ID: <1333768658.65.0.282231880942.issue14519@psf.upfronthosting.co.za> py.user added the comment: the prefix "0x" is not necessary for the %x specifier in C if the pattern will see "ABC", it will not match with it, but it should match ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 05:19:41 2012 From: report at bugs.python.org (py.user) Date: Sat, 07 Apr 2012 03:19:41 +0000 Subject: [issue14519] In re's examples the example with scanf() contains wrong analog for %x, %X specifiers In-Reply-To: <1333757996.58.0.360922081437.issue14519@psf.upfronthosting.co.za> Message-ID: <1333768781.49.0.129115613351.issue14519@psf.upfronthosting.co.za> py.user added the comment: #include int main(void) { unsigned n; scanf("%x", &n); printf("%u\n", n); return 0; } [guest at localhost c]$ .ansi t.c -o t [guest at localhost c]$ ./t 0xa 10 [guest at localhost c]$ ./t a 10 [guest at localhost c]$ [guest at localhost c]$ alias .ansi alias .ansi='gcc -ansi -pedantic -Wall' [guest at localhost c]$ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 05:47:23 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 07 Apr 2012 03:47:23 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1333770443.72.0.0992122355059.issue14478@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 06:14:28 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sat, 07 Apr 2012 04:14:28 +0000 Subject: [issue13708] Document ctypes.wintypes In-Reply-To: <1325644438.51.0.00118311970114.issue13708@psf.upfronthosting.co.za> Message-ID: <1333772068.01.0.31073978478.issue13708@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 10:50:22 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 07 Apr 2012 08:50:22 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1333788622.69.0.482774941982.issue9141@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm still unclear about the rationale for this change. krisvale says in the patch and in msg109099 that this is to determine whether an object can be collected "at this time". Is the intended usage that the result value may change over the lifetime of the object? If so, I'm -1 on the patch. If an object cannot be collected "at this time", it means that it is added to gc.garbage, which in turn means that it will never be collected (unless somebody explicitly clears gc.garbage). Supporting the case of objects that can be collected despite living in a cycle is fine to me, but those objects must not change their mind. Supporting the case of objects that are not collectable now, but may be collectable later, may have its use case (which one?), but this is not addressed by the patch (AFAICT). To support it, processing of the entire cycle must be postponed (to the next collection? to the next generation?). I'm -0 on recycling the is_gc slot. Having a GC header and having a non-trivial tp_del are two unrelated issues. If this is done, I think it would be best to rename the slot to tp_gc_flags or something. There is also the slight risk of some type in the wild returning non-1 currently, which then would get misinterpreted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 12:19:55 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 10:19:55 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1333793995.9.0.0277489989882.issue14478@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I recommend that __hash__ should use functools.lru_cache for caching. Why would you do such a thing? A hash value is a single 64-bit slot, no need to add the memory consumption of a whole dictionary and the runtime cost of a LRU eviction policy when you can simply cache the hash in the object itself (like we already do for strings)... ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 12:20:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 10:20:02 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1333794002.88.0.232201622273.issue14478@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> needs patch versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 12:22:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 10:22:06 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333794126.88.0.106053836479.issue14310@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Any other comments? No, the patch looks ok now. Please watch the buildbots after you commit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 12:30:24 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 07 Apr 2012 10:30:24 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1333794624.75.0.565245447224.issue9141@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Jim: The edge case of collecting an object that is alone in a cycle is something that isn't handled. I'm also not sure that it is worth doing or even safe or possible. but that is beside the point and not the topic of this patch. Martin: This patch is formalizing a known fact about cpython objects, albeit an uncommon one: Some objects with finalizers can be safely collected if they are in a certain state. The canonical example is the PyGeneratorObject. gccollect.c has special code for this type and there is a special evil API exposed to deal with the case. _This patch is not changing any behaviour._ Generator objects that are in a special state of existance cannot be collected. Rather, they are (and always have been) put in gc.garbage along with the rest of their cycle chain. In other cases, the finalizer causes no side effects and simply clearing them is ok. I couldn't tell you what those generator execution states are, but the fact is that they exist. A similar problem exists in Stackless python with tasklets. We solved it in this generic way there rather than add more exceptional code to gcmodule.c and this patch is the result of that work. In Stackless, the inverse is true: An object without an explicit finalizer can still be unsafe to collect, because the tp_dealloc can do evil things, but doesn't always, depending on object state. So, objects who change their mind about whether they can be collected or not are a fact of life in python. Yes, even cPython. This patch aims to formalize that fact and give it an interface, rather than to have special code for generator objects in gcmodule.c and an inscrutable API exposed (PyGen_NeedsFinalizing()) About reusing the slot: Slots are a precious commodity in python. This particular slot is undocumented and used only for one known thing: To distinguish PyTypeObjects from PyHeapTypeObjects. In fact, creating a slot and not using special case code (like they did for PyGeneratorObjects) was forward thinking, and I'm trying to build on that. Renaming the slot is a fine idea. A brief search on google code (and google at large) showed no one using this slot. It is one of those undocumented strange slots that one just initializes to 0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 12:34:00 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 07 Apr 2012 10:34:00 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1333794840.34.0.605765142315.issue9141@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Btw. tangentially related to this discussion, issue 10576 aims to make the situation with uncollectable objects a little more bearable. An application can listen for garbage collection, visit gc.garbage and deal with its problematic types in its own way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 12:40:28 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 10:40:28 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1333795228.36.0.0842877752385.issue4892@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > err, is it possible to edit out those file paths? I don't know how to do that. If you want I can remove the message altogether. But I don't see anything confidential or exploitable in your message. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 12:40:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 10:40:42 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1333795242.9.0.536084624131.issue4892@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- assignee: jnoller -> nosy: +sbt versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 12:45:24 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 10:45:24 +0000 Subject: [issue7978] SocketServer doesn't handle syscall interruption In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za> Message-ID: <1333795524.93.0.0558218770247.issue7978@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Jerzy's latest patch looks ok to me. This is a slight behaviour change so I'm not sure it should go in 3.2/2.7. ---------- stage: -> patch review versions: +Python 3.3 -Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 12:55:39 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 10:55:39 +0000 Subject: [issue14520] Buggy Decimal.__sizeof__ Message-ID: <1333796139.51.0.465726080972.issue14520@psf.upfronthosting.co.za> New submission from Antoine Pitrou : I'm not sure __sizeof__ is implemented correctly: >>> from decimal import Decimal >>> import sys >>> d = Decimal(123456789123456798123456789123456798123456789123456798) >>> d Decimal('123456789123456798123456789123456798123456789123456798') >>> sys.getsizeof(d) 24 ... looks too small. ---------- assignee: skrah messages: 157726 nosy: pitrou, skrah priority: normal severity: normal status: open title: Buggy Decimal.__sizeof__ type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 13:08:08 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 07 Apr 2012 11:08:08 +0000 Subject: [issue14425] Improve handling of 'timeout' parameter default in urllib.urlopen In-Reply-To: <1332860558.06.0.334522792296.issue14425@psf.upfronthosting.co.za> Message-ID: <1333796888.4.0.284633068473.issue14425@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Hi David, I am sorry, I did not notice your second comment in this bug and later when you closed this, noticed the bug report. Yes, the default=None but actually pointing to a sentinel value is an odd duck and I believe the explanation in docs were updated a couple of times to inform user of that behavior, but still the signature gives a feeling that it could be improved. I am at loss as well in terms of giving an "easy solution" to fix the docs. Thanks, Senthil ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 13:24:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 07 Apr 2012 11:24:50 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 51b4bddd0e92 by Kristj?n Valur J?nsson in branch 'default': Issue #14310: inter-process socket duplication for windows http://hg.python.org/cpython/rev/51b4bddd0e92 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 13:25:37 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 07 Apr 2012 11:25:37 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333797937.42.0.019062741878.issue14310@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 13:29:11 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 07 Apr 2012 11:29:11 +0000 Subject: [issue14520] Buggy Decimal.__sizeof__ In-Reply-To: <1333796139.51.0.465726080972.issue14520@psf.upfronthosting.co.za> Message-ID: <20120407112910.GA540@sleipnir.bytereef.org> Stefan Krah added the comment: It isn't implemented at all. The Python version also always returns 96, irrespective of the coefficient length. Well, arguably the coefficient is a separate object in the Python version: 96 >>> sys.getsizeof(d._int) 212 For the C version I'll do the same as in longobject.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 13:32:04 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 07 Apr 2012 11:32:04 +0000 Subject: [issue14520] Buggy Decimal.__sizeof__ In-Reply-To: <1333796139.51.0.465726080972.issue14520@psf.upfronthosting.co.za> Message-ID: <1333798324.78.0.846651936118.issue14520@psf.upfronthosting.co.za> Stefan Krah added the comment: In full: >>> d = Decimal(100000000000000000000000000000000000000000000000000000000000000000000) >>> sys.getsizeof(d) 96 >>> sys.getsizeof(d._int) 212 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 14:28:59 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 12:28:59 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333793995.9.0.0277489989882.issue14478@psf.upfronthosting.co.za> Message-ID: <1333801879.21808.9.camel@raxxla> Serhiy Storchaka added the comment: > > I recommend that __hash__ should use functools.lru_cache for caching. > Why would you do such a thing? A hash value is a single 64-bit slot, no need to add the memory consumption of a whole dictionary and the runtime cost of a LRU eviction policy when you can simply cache the hash in the object itself (like we already do for strings)... It was a joke (I think). Taking into account the fact that LRU cache uses a hashtable and need to calculate the hash of arguments (i.e., the Decimal self) to get the cached value of hash. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 14:35:14 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 12:35:14 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333801879.21808.9.camel@raxxla> Message-ID: <1333801792.3814.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > > > I recommend that __hash__ should use functools.lru_cache for caching. > > Why would you do such a thing? A hash value is a single 64-bit slot, no need to add the memory consumption of a whole dictionary and the runtime cost of a LRU eviction policy when you can simply cache the hash in the object itself (like we already do for strings)... > > It was a joke (I think). Taking into account the fact that LRU cache > uses a hashtable and need to calculate the hash of arguments (i.e., the > Decimal self) to get the cached value of hash. Damn. Shame on me for not understanding Raymond's humour :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 15:00:09 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 07 Apr 2012 13:00:09 +0000 Subject: [issue10576] Add a progress callback to gcmodule In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za> Message-ID: <1333803609.82.0.595191178481.issue10576@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Here is an updated patch, taking Jim's and Antoine's comments into account. Jim, I?d like to comment that I think the reason __del__ objects are uncollectable is more subtle than there being no defined order of calling the __del__ functions. More significantly, no python code may be executed during an implicit garbage collection. Now, it is possible that one could clean up cycles containing only one __del__ method during _expcicit_ collections (calling gc.collect()) but it hardly seems worth the effort. ---------- Added file: http://bugs.python.org/file25150/gccallback.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 15:48:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 13:48:35 +0000 Subject: [issue10576] Add a progress callback to gcmodule In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za> Message-ID: <1333806515.68.0.830844159396.issue10576@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Uploaded another review. I also notice you didn't really address my point, since self.visit is still initialized too early. IMO it should be initialized after the first gc.collect() at the beginning of each test (not in setUp()). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 17:45:42 2012 From: report at bugs.python.org (Brian Curtin) Date: Sat, 07 Apr 2012 15:45:42 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1333813542.87.0.0193130162152.issue3561@psf.upfronthosting.co.za> Brian Curtin added the comment: Attached is issue3561.diff which adds a path option, off by default, as a feature to be installed. I've tested installation and un-installation with the feature both installed and not installed and it seems to work fine for me. http://briancurtin.com/python-dev/python-3.3.15437.msi is an installer built with this patch. http://briancurtin.com/python-dev/CustomizePage.png is simply a screenshot of the page where you choose to enable this feature. ---------- keywords: +needs review stage: -> patch review Added file: http://bugs.python.org/file25151/issue3561.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 17:52:06 2012 From: report at bugs.python.org (sbt) Date: Sat, 07 Apr 2012 15:52:06 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1333813926.35.0.775745164983.issue4892@psf.upfronthosting.co.za> sbt added the comment: Jimbofbx wrote: > def main(): > from multiprocessing import Pipe, reduction > i, o = Pipe() > print(i); > reduced = reduction.reduce_connection(i) > print(reduced); > newi = reduced[0](*reduced[1]) > print(newi); > newi.send("hi") > o.recv() On Windows with a PipeConnection object you should use rebuild_pipe_connection() instead of rebuild_connection(). With that change, on Python 3.3 I get (, (('\\\\.\\pipe\\pyc-6000-1-30lq4p', 356, False), True, True)) Having said all that I agree multiprocessing.reduction should be fixed. Maybe an enable_pickling_support() function could be added to register the necessary things with copyreg. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 18:06:32 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 16:06:32 +0000 Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2 In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za> Message-ID: <1333814792.95.0.133962054143.issue13621@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 18:11:56 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 16:11:56 +0000 Subject: [issue13031] small speed-up for tarfile.py when unzipping tarballs In-Reply-To: <1316753335.88.0.48389267066.issue13031@psf.upfronthosting.co.za> Message-ID: <1333815116.31.0.35981253646.issue13031@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 18:14:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 16:14:11 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1333815251.72.0.650848212906.issue4892@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Having said all that I agree multiprocessing.reduction should be > fixed. Maybe an enable_pickling_support() function could be added to > register the necessary things with copyreg. Why not simply use ForkingPickler? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 19:17:03 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 17:17:03 +0000 Subject: [issue10408] Denser dicts and linear probing In-Reply-To: <1289659692.61.0.467153013048.issue10408@psf.upfronthosting.co.za> Message-ID: <1333819023.84.0.955030248305.issue10408@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 19:22:33 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 07 Apr 2012 17:22:33 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1333819353.9.0.0247018129241.issue14478@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +patch Added file: http://bugs.python.org/file25152/decimal_hash.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 19:23:06 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 07 Apr 2012 17:23:06 +0000 Subject: [issue14511] _static/opensearch.xml for Python 3.2 docs directs searches to 3.3 docs In-Reply-To: <1333640035.04.0.466278675781.issue14511@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 7f123dec2731 by Georg Brandl in branch '3.2': Closes #14511: fix wrong opensearch link for 3.2 docs. http://hg.python.org/cpython/rev/7f123dec2731 New changeset 57a8a8f5e0bc by Georg Brandl in branch 'default': Closes #14511: merge with 3.2 http://hg.python.org/cpython/rev/57a8a8f5e0bc ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 19:25:48 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 17:25:48 +0000 Subject: [issue13126] find() slower than rfind() In-Reply-To: <1318016796.03.0.16031959225.issue13126@psf.upfronthosting.co.za> Message-ID: <1333819548.85.0.358514307961.issue13126@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 19:26:05 2012 From: report at bugs.python.org (sbt) Date: Sat, 07 Apr 2012 17:26:05 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1333819565.61.0.292996682609.issue4892@psf.upfronthosting.co.za> sbt added the comment: ForkingPickler is only used when creating a child process. The multiprocessing.reduction module is only really intended for sending stuff to *pre-existing* processes. As things stand, after importing multiprocessing.reduction you can do something like buf = io.BytesIO() pickler = ForkingPickler(buf) pickler.dump(conn) data = buf.getvalue() writer.send_bytes(data) But that is rather less simple and obvious than just doing writer.send(conn) which was possible in pyprocessing. Originally just importing the module magically registered the reduce functions with copyreg. Since this was undesirable, the reduction functions were instead registered with ForkingPickler. But this fix rather missed the point of the module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 19:28:07 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 17:28:07 +0000 Subject: [issue12805] Optimizations for bytes.join() et. al In-Reply-To: <1313973836.25.0.316459845083.issue12805@psf.upfronthosting.co.za> Message-ID: <1333819687.56.0.0305302582885.issue12805@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 19:28:47 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 17:28:47 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1333819565.61.0.292996682609.issue4892@psf.upfronthosting.co.za> Message-ID: <1333819404.3814.3.camel@localhost.localdomain> Antoine Pitrou added the comment: > ForkingPickler is only used when creating a child process. The > multiprocessing.reduction module is only really intended for sending > stuff to *pre-existing* processes. But ForkingPickler could be used in multiprocessing.connection, couldn't it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 19:29:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 17:29:35 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333819353.94.0.884837240902.issue14478@psf.upfronthosting.co.za> Message-ID: <1333819452.3814.4.camel@localhost.localdomain> Antoine Pitrou added the comment: Le samedi 07 avril 2012 ? 17:22 +0000, Raymond Hettinger a ?crit : > ---------- > keywords: +patch > Added file: http://bugs.python.org/file25152/decimal_hash.diff I think patching the C version of Decimal would be more useful :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 19:43:09 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 07 Apr 2012 17:43:09 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1333742404.3367.0.camel@localhost.localdomain> Message-ID: Brett Cannon added the comment: On Fri, Apr 6, 2012 at 16:05, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > > OK, -v/PYTHONVERBOSE is as done as it is going to be by me. Next up is > > (attempting) Windows registry stuff. After that I will push to default > > with test_trace and test_pydoc skipped so others can help me with > > those. > > Skipped? How so? By raising unittest.SkipTest. I already know how to fix pydoc, but I need to get module names attached to ImportError and I don't want to bother with that until importlib is in (else it will be weird having it added into default but not in Python/import.c). As for trace, I have not looked at it, but I know what the failure is caused by and it's a question of how best to deal with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 19:46:11 2012 From: report at bugs.python.org (James Hutchison) Date: Sat, 07 Apr 2012 17:46:11 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1333820771.32.0.440230086829.issue4892@psf.upfronthosting.co.za> James Hutchison added the comment: @pitrou You can just delete my original post. I'll repost an edited version here for reference original post with paths removed: This is an issue for me (Python 3.2). I have a custom pool that sends arguments for a function call over a pipe. I cannot send another pipe as an argument. Tim's workaround also does not work for me (win xp 32bit and 64bit) >From what I can tell, you can only send a connection as a direct argument to a function call. This limits what I can do because I cannot introduce new pipes to a worker process after it is instantiated. Using this code: def main(): from multiprocessing import Pipe, reduction i, o = Pipe() print(i); reduced = reduction.reduce_connection(i) print(reduced); newi = reduced[0](*reduced[1]) print(newi); newi.send("hi") o.recv() if __name__ == "__main__": main(); This is my output: (, (('\\\\.\\pipe\\pyc-3156-1-q5wwnr', 1756, False), True, True)) >>> newi.send("hi") IOError: [Errno 10038] An operation was attempted on something that is not a socket As you can see, the handle changes ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 19:52:53 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 17:52:53 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1333821173.57.0.618594613405.issue4892@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- Removed message: http://bugs.python.org/msg157702 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 19:56:04 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 17:56:04 +0000 Subject: [issue12986] Using getrandbits() in uuid.uuid4() is faster and more readable In-Reply-To: <1316104217.68.0.381815581788.issue12986@psf.upfronthosting.co.za> Message-ID: <1333821364.16.0.0903568286301.issue12986@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > uuids = set() > for u in [uuid.uuid4() for i in range(1000)]: > uuids.add(u) uuids = {uuid.uuid4() for i in range(1000)} However, I'm not sure of the legitimacy of replacement suitable for cryptographic use `os.urandom` on fast pseudo-random `random.getrandbits`. Especially for applications that need to generate a lot of uuids. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 19:57:55 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 17:57:55 +0000 Subject: [issue11981] dupe self.fp.tell() in zipfile.ZipFile.writestr In-Reply-To: <1304354217.95.0.422937158098.issue11981@psf.upfronthosting.co.za> Message-ID: <1333821475.34.0.759127320971.issue11981@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 19:59:01 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 17:59:01 +0000 Subject: [issue10376] ZipFile unzip is unbuffered In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za> Message-ID: <1333821541.97.0.641307669935.issue10376@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 20:21:34 2012 From: report at bugs.python.org (sbt) Date: Sat, 07 Apr 2012 18:21:34 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1333822894.02.0.934048999921.issue4892@psf.upfronthosting.co.za> sbt added the comment: > But ForkingPickler could be used in multiprocessing.connection, > couldn't it? I suppose so. Note that the way a connection handle is transferred between existing processes is unnecessarily inefficient on Windows. A background server thread (one per process) has to be started and the receiving process must connect back to the sending process to receive its duplicate handle. There is a simpler way to do this on Windows. The sending process duplicates the handle, and the receiving process duplicates that second handle using DuplicateHandle() and the DUPLICATE_CLOSE_SOURCE flag. That way no server thread is necessary on Windows. I got this to work recently for pickling references to file handles for mmaps on. (A server thread would still be necessary on Unix.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 20:43:06 2012 From: report at bugs.python.org (mattip) Date: Sat, 07 Apr 2012 18:43:06 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. Message-ID: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> New submission from mattip : Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import math >>> math.copysign(1., float('inf')) 1.0 >>> math.copysign(1., float('-inf')) -1.0 >>> math.copysign(1., float('nan')) -1.0 >>> math.copysign(1., float('-nan')) 1.0 >>> ---------- components: None messages: 157746 nosy: mattip priority: normal severity: normal status: open title: math.copysign(1., float('nan')) returns -1. type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 20:53:46 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 18:53:46 +0000 Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za> Message-ID: <1333824826.8.0.928743002432.issue6972@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 20:58:59 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 18:58:59 +0000 Subject: [issue2824] zipfile to handle duplicate files in archive In-Reply-To: <1210537070.35.0.0613996133193.issue2824@psf.upfronthosting.co.za> Message-ID: <1333825139.38.0.218410714334.issue2824@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 21:02:43 2012 From: report at bugs.python.org (sbt) Date: Sat, 07 Apr 2012 19:02:43 +0000 Subject: [issue14522] Avoid using DuplicateHandle() on sockets in multiprocessing.connection Message-ID: <1333825363.09.0.353081584992.issue14522@psf.upfronthosting.co.za> New submission from sbt : In multiprocessing.connection on Windows, socket handles are indirectly duplicated using DuplicateHandle() instead the WSADuplicateSocket(). According to Microsoft's documentation this is not supported. This is easily avoided by using socket.detach() instead of duplicating the handle. ---------- files: mp_socket_dup.patch keywords: patch messages: 157747 nosy: sbt priority: normal severity: normal status: open title: Avoid using DuplicateHandle() on sockets in multiprocessing.connection Added file: http://bugs.python.org/file25153/mp_socket_dup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 21:06:25 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 07 Apr 2012 19:06:25 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1333825585.21.0.453642658955.issue14521@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is a near duplicate of issue7281. Most likely, copysign is behaving correctly, and it's already the float conversion that errs. For struct.pack('d', float('nan')), I get '\x00\x00\x00\x00\x00\x00\xf8\xff'; for -nan, I get '\x00\x00\x00\x00\x00\x00\xf8\x7f'; ISTM that this has the sign bits switched. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 21:08:38 2012 From: report at bugs.python.org (sbt) Date: Sat, 07 Apr 2012 19:08:38 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1333825718.27.0.206256902267.issue4892@psf.upfronthosting.co.za> sbt added the comment: > There is a simpler way to do this on Windows. The sending process > duplicates the handle, and the receiving process duplicates that second > handle using DuplicateHandle() and the DUPLICATE_CLOSE_SOURCE flag. That > way no server thread is necessary on Windows. Note that this should not be done for socket handles since DuplicateHandle() is not supposed to work for them. socket.share() and socket.fromshare() with a server thread can be used for sockets. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 21:09:28 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 07 Apr 2012 19:09:28 +0000 Subject: [issue14522] Avoid using DuplicateHandle() on sockets in multiprocessing.connection In-Reply-To: <1333825363.09.0.353081584992.issue14522@psf.upfronthosting.co.za> Message-ID: <1333825768.42.0.704173574429.issue14522@psf.upfronthosting.co.za> Martin v. L?wis added the comment: What is the bug that this fixes? Can you provide a test case? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 21:11:36 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 19:11:36 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1333825896.43.0.862739378404.issue6839@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 21:12:51 2012 From: report at bugs.python.org (sbt) Date: Sat, 07 Apr 2012 19:12:51 +0000 Subject: [issue14522] Avoid using DuplicateHandle() on sockets in multiprocessing.connection In-Reply-To: <1333825363.09.0.353081584992.issue14522@psf.upfronthosting.co.za> Message-ID: <1333825971.73.0.31093972492.issue14522@psf.upfronthosting.co.za> Changes by sbt : Removed file: http://bugs.python.org/file25153/mp_socket_dup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 21:17:15 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 19:17:15 +0000 Subject: [issue4844] ZipFile doesn't range check in _EndRecData() In-Reply-To: <1231169051.46.0.731825269948.issue4844@psf.upfronthosting.co.za> Message-ID: <1333826235.71.0.30849997925.issue4844@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 21:17:25 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 19:17:25 +0000 Subject: [issue10905] zipfile: fix arcname with leading '///' or '..' In-Reply-To: <1295006628.53.0.290414123413.issue10905@psf.upfronthosting.co.za> Message-ID: <1333826245.02.0.2523539685.issue10905@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 21:20:32 2012 From: report at bugs.python.org (sbt) Date: Sat, 07 Apr 2012 19:20:32 +0000 Subject: [issue14522] Avoid using DuplicateHandle() on sockets in multiprocessing.connection In-Reply-To: <1333825363.09.0.353081584992.issue14522@psf.upfronthosting.co.za> Message-ID: <1333826432.17.0.19819311826.issue14522@psf.upfronthosting.co.za> sbt added the comment: > What is the bug that this fixes? Can you provide a test case? The bug is using an API in a way that the documentation says is wrong/unreliable. There does not seem to be a classification for that. I have never seen a problem caused by using DuplicateHandle() so I cannot provide a test case. Note that socket.dup() used to be implemented using DuplicateHandle(), but that was changed to WSADuplicateSocket(). See Issue 9753. ---------- Added file: http://bugs.python.org/file25154/mp_socket_dup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 21:21:35 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 19:21:35 +0000 Subject: [issue10614] ZipFile: add a filename_encoding argument In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za> Message-ID: <1333826495.12.0.151877012658.issue10614@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 21:22:03 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 19:22:03 +0000 Subject: [issue10972] zipfile: add "unicode" option to the force the filename encoding to UTF-8 In-Reply-To: <1295611245.09.0.199855932712.issue10972@psf.upfronthosting.co.za> Message-ID: <1333826523.7.0.363654986915.issue10972@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 21:25:47 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 07 Apr 2012 19:25:47 +0000 Subject: [issue11980] zipfile.ZipFile.write should accept fp as argument In-Reply-To: <1304354092.27.0.477434523561.issue11980@psf.upfronthosting.co.za> Message-ID: <1333826747.66.0.259213480089.issue11980@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 21:27:04 2012 From: report at bugs.python.org (sbt) Date: Sat, 07 Apr 2012 19:27:04 +0000 Subject: [issue14522] Avoid using DuplicateHandle() on sockets in multiprocessing.connection In-Reply-To: <1333825363.09.0.353081584992.issue14522@psf.upfronthosting.co.za> Message-ID: <1333826824.87.0.977060483068.issue14522@psf.upfronthosting.co.za> sbt added the comment: Actually Issue 9753 was causing failures in test_socket.BasicTCPTest and test_socket.BasicTCPTest2 on at least one Windows XP machine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 21:35:10 2012 From: report at bugs.python.org (James Hutchison) Date: Sat, 07 Apr 2012 19:35:10 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1333827310.14.0.8522545144.issue4892@psf.upfronthosting.co.za> James Hutchison added the comment: Shouldn't reduce_pipe_connection just be an alias for reduce_connection in unix so that using reduce_pipe_connection would work for both win and unix? My understanding after looking at the code is that reduce_pipe_connection isn't defined for non-win32, although I haven't tested it to see if that's true. Of course, ideally a pipe connection would just pickle and unpickle properly out-of-the-box, which I think was the original intent. Here's a complete, working example with Python 3.2 tested on Win 7 64-bit: import sys from multiprocessing import Process,Pipe, reduction def main(): print("starting"); i, o = Pipe(False) parent, child = Pipe(); reducedchild = reduce_pipe(child); p = Process(target=helper, args=(i,)); p.start(); parent.send("hi"); o.send(reducedchild); print(parent.recv()); print("finishing"); p.join(); print("done"); def helper(inPipe): childPipe = expand_reduced_pipe(inPipe.recv()); childPipe.send("child got: " + childPipe.recv()); return; def reduce_pipe(pipe): if sys.platform == "win32": return reduction.reduce_pipe_connection(pipe); else: return reduction.reduce_connection(pipe); def expand_reduced_pipe(reduced_pipe): return reduced_pipe[0](*reduced_pipe[1]); if __name__ == "__main__": main(); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 22:02:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 20:02:20 +0000 Subject: [issue14522] Avoid using DuplicateHandle() on sockets in multiprocessing.connection In-Reply-To: <1333825363.09.0.353081584992.issue14522@psf.upfronthosting.co.za> Message-ID: <1333828940.74.0.250501734083.issue14522@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Is there a reason the patch changes close() to win32.CloseHandle()? ---------- components: +Library (Lib) nosy: +pitrou stage: -> patch review type: -> behavior versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 22:06:38 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 20:06:38 +0000 Subject: [issue12986] Using getrandbits() in uuid.uuid4() is faster and more readable In-Reply-To: <1316104217.68.0.381815581788.issue12986@psf.upfronthosting.co.za> Message-ID: <1333829198.88.0.940789027985.issue12986@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > However, I'm not sure of the legitimacy of replacement suitable for > cryptographic use `os.urandom` on fast pseudo-random > `random.getrandbits`. Especially for applications that need to generate > a lot of uuids. Agreed. urandom() is supposed to incorporate "real" random, while getrandbits() uses a PRNG. Also, as the OP shows, it's easy to inject your own random source: >>> grb = "uuid.UUID(int=random.getrandbits(128), version=4)" if you really need the speed. ---------- nosy: +pitrou stage: -> patch review versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 22:10:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 20:10:18 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1333829418.92.0.964253521752.issue14310@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Re-opening. There is now a buildbot failure: ====================================================================== ERROR: testTypes (test.test_socket.TestSocketSharing) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_socket.py", line 4738, in testTypes source = socket.socket(f, t) File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\socket.py", line 94, in __init__ _socket.socket.__init__(self, family, type, proto, fileno) OSError: [Error 10047] An address incompatible with the requested protocol was used http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/ ---------- assignee: -> krisvale stage: -> committed/rejected status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 22:12:19 2012 From: report at bugs.python.org (sbt) Date: Sat, 07 Apr 2012 20:12:19 +0000 Subject: [issue14522] Avoid using DuplicateHandle() on sockets in multiprocessing.connection In-Reply-To: <1333825363.09.0.353081584992.issue14522@psf.upfronthosting.co.za> Message-ID: <1333829539.64.0.376751131378.issue14522@psf.upfronthosting.co.za> sbt added the comment: > Is there a reason the patch changes close() to win32.CloseHandle()? This is a Windows only code path so close() is just an alias for win32.CloseHandle(). It allow removal of the lines # Late import because of circular import from multiprocessing.forking import duplicate, close ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 22:39:53 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 07 Apr 2012 20:39:53 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 9b858096044e by Kristj?n Valur J?nsson in branch 'default': Issue #14310: Catch testing errors when trying to create unsupported socket http://hg.python.org/cpython/rev/9b858096044e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 22:44:38 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 07 Apr 2012 20:44:38 +0000 Subject: [issue14522] Avoid using DuplicateHandle() on sockets in multiprocessing.connection In-Reply-To: <1333825363.09.0.353081584992.issue14522@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f8a92fd084c2 by Antoine Pitrou in branch 'default': Issue #14522: Avoid duplicating socket handles in multiprocessing.connection. http://hg.python.org/cpython/rev/f8a92fd084c2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 22:45:00 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 20:45:00 +0000 Subject: [issue14522] Avoid using DuplicateHandle() on sockets in multiprocessing.connection In-Reply-To: <1333825363.09.0.353081584992.issue14522@psf.upfronthosting.co.za> Message-ID: <1333831500.68.0.19986672383.issue14522@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Patch committed, thank you! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 7 22:52:00 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 07 Apr 2012 20:52:00 +0000 Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za> Message-ID: <1333831920.28.0.542886668283.issue6972@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- priority: normal -> high stage: -> needs patch versions: +Python 3.3 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 00:26:34 2012 From: report at bugs.python.org (mattip) Date: Sat, 07 Apr 2012 22:26:34 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1333837594.56.0.0638199732618.issue14521@psf.upfronthosting.co.za> mattip added the comment: It appears that microsoft decided NAN will be represented by '\x00\x00\x00\x00\x00\x00\xf8\xff', which has the sign bit set. Compiling this c code with visual 9.0 gives the correct answers for the first value, and a mess for the second: #include #include #include int main( void ) { unsigned long nan[2]={0xffffffff, 0x7fffffff}; double g; double z, zn; int i; for (i=0;i<2; i++) { g = *( double* )(nan+i); printf( "g( %g ) is NaN, _isnan(g) %d\n", g, _isnan(g) ); z = _copysign(-3, g); zn = _copysign(-3, -g); printf("z=%g, zn=%g\n", z, zn); } return 0; } This corresponds with loewis 's observation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 00:36:42 2012 From: report at bugs.python.org (sbt) Date: Sat, 07 Apr 2012 22:36:42 +0000 Subject: [issue14087] multiprocessing.Condition.wait_for missing In-Reply-To: <1329922885.58.0.881756065062.issue14087@psf.upfronthosting.co.za> Message-ID: <1333838202.81.0.733775875932.issue14087@psf.upfronthosting.co.za> sbt added the comment: New patch skips tests if ctypes not available. ---------- Added file: http://bugs.python.org/file25155/cond_wait_for.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 01:01:13 2012 From: report at bugs.python.org (Thomas W. Barr) Date: Sat, 07 Apr 2012 23:01:13 +0000 Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za> Message-ID: <1333839673.72.0.848263738128.issue6972@psf.upfronthosting.co.za> Thomas W. Barr added the comment: I'll update my patch to work on the current 3.x head later tonight. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 01:15:46 2012 From: report at bugs.python.org (Arcangeltj) Date: Sat, 07 Apr 2012 23:15:46 +0000 Subject: [issue14523] IDLE's subprocess startup error Message-ID: <1333840546.69.0.270630772659.issue14523@psf.upfronthosting.co.za> New submission from Arcangeltj : "IDLE's subprocess didn't make connection. Either IDLE can't start a subprocess or personal firewall software is blocking the connection." What or why is this happening? Is there something that can fix this issue? ---------- components: IDLE messages: 157764 nosy: arcangeltj priority: normal severity: normal status: open title: IDLE's subprocess startup error type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 02:21:58 2012 From: report at bugs.python.org (mattip) Date: Sun, 08 Apr 2012 00:21:58 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1333844518.25.0.849103063666.issue14521@psf.upfronthosting.co.za> mattip added the comment: Sorry for the garbage c code, the comment however is correct: Py_NAN is created with the sign bit set (on windows), and then _copysign on windows uses the sign bit to determine the output, which results in the wrong answer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 02:48:57 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 08 Apr 2012 00:48:57 +0000 Subject: [issue14222] Use time.steady() to implement timeout In-Reply-To: <1331149120.51.0.79082225225.issue14222@psf.upfronthosting.co.za> Message-ID: <1333846137.68.0.680728433898.issue14222@psf.upfronthosting.co.za> Raymond Hettinger added the comment: [Victor] > The duration of a timeout of N seconds should be N seconds even > if the system clock is updated (e.g. a daylight saving time > (DST) change). IIRC, time.time() is not a local time and it is unaffected by a DST change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 03:06:22 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 08 Apr 2012 01:06:22 +0000 Subject: [issue14222] Use time.steady() to implement timeout In-Reply-To: <1331149120.51.0.79082225225.issue14222@psf.upfronthosting.co.za> Message-ID: <1333847182.34.0.448610563305.issue14222@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'm closing this one. The "not subject to adjustment" property is more desirable than not. The "undefined reference point" property isn't harmful in this context (the start time isn't exposed). I'll follow the python-dev thread and re-open this if it becomes clear that there are any issues for steady() being used for timeout logic. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 03:50:18 2012 From: report at bugs.python.org (Paul A.) Date: Sun, 08 Apr 2012 01:50:18 +0000 Subject: [issue14524] Python-2.7.3rc2/Modules/_ctypes/libffi/src/dlmalloc.c won't compile on ia64-hp-hpux11.31 without -DHAVE_USR_INCLUDE_MALLOC_H Message-ID: <1333849818.58.0.912863620165.issue14524@psf.upfronthosting.co.za> New submission from Paul A. : Shouldn't configure be able to arrive at that without me adding manually? Anyway, after the build finishes thing soon come crashing down; my stack trace is at the end... running build_scripts creating build/scripts-2.7 copying and adjusting /usr/local/src/Python-2.7.3rc2/Tools/scripts/pydoc -> build/scripts-2.7 copying and adjusting /usr/local/src/Python-2.7.3rc2/Tools/scripts/idle -> build/scripts-2.7 copying and adjusting /usr/local/src/Python-2.7.3rc2/Tools/scripts/2to3 -> build/scripts-2.7 copying and adjusting /usr/local/src/Python-2.7.3rc2/Lib/smtpd.py -> build/scripts-2.7 changing mode of build/scripts-2.7/pydoc from 644 to 755 changing mode of build/scripts-2.7/idle from 644 to 755 changing mode of build/scripts-2.7/2to3 from 644 to 755 changing mode of build/scripts-2.7/smtpd.py from 644 to 755 sh[3]: 1340 Abort(coredump) (gdb) bt #0 0xc0000000004395d0:0 in kill+0x30 () from /usr/lib/hpux64/libc.so.1 #1 0xc0000000002e8180:0 in raise+0x120 () from /usr/lib/hpux64/libc.so.1 #2 0xc0000000003f8c50:0 in abort+0x170 () from /usr/lib/hpux64/libc.so.1 #3 0xc000000010f0c7f0:0 in free (mem=0x60000000000053d0) at /usr/local/src/Python-2.7.3rc2/Modules/_ctypes/libffi/src/dlmalloc.c:4288 #4 0xc000000000bfcde0:0 in _UNW_free_mpool()+0xc0 () from /usr/lib/hpux64/libunwind.so.1 #5 0xc00000000004cb50:0 in EM_mark_BOS+0x50 () from /usr/lib/hpux64/dld.so ---------- components: Build messages: 157768 nosy: pda priority: normal severity: normal status: open title: Python-2.7.3rc2/Modules/_ctypes/libffi/src/dlmalloc.c won't compile on ia64-hp-hpux11.31 without -DHAVE_USR_INCLUDE_MALLOC_H versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 03:52:30 2012 From: report at bugs.python.org (Paul A.) Date: Sun, 08 Apr 2012 01:52:30 +0000 Subject: [issue14524] Python-2.7.3rc2/Modules/_ctypes/libffi/src/dlmalloc.c won't compile on ia64-hp-hpux11.31 without -DHAVE_USR_INCLUDE_MALLOC_H In-Reply-To: <1333849818.58.0.912863620165.issue14524@psf.upfronthosting.co.za> Message-ID: <1333849950.38.0.451899085176.issue14524@psf.upfronthosting.co.za> Changes by Paul A. : ---------- type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 03:54:35 2012 From: report at bugs.python.org (Paul A.) Date: Sun, 08 Apr 2012 01:54:35 +0000 Subject: [issue14525] ia64-hp-hpux11.31 won't compile Python-2.6.8rc2 without -D_TERMIOS_INCLUDED Message-ID: <1333850075.77.0.408518012212.issue14525@psf.upfronthosting.co.za> New submission from Paul A. : I can't help thinking that configure should be able to figure out the need for this -- Modules/termios.c won't compile without adding -D_TERMIOS_INCLUDED by hand. This is far from new, all 2.5+ versions I've tried to compile are like that on this platform. ---------- components: Build messages: 157769 nosy: pda priority: normal severity: normal status: open title: ia64-hp-hpux11.31 won't compile Python-2.6.8rc2 without -D_TERMIOS_INCLUDED type: enhancement versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 04:01:05 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Apr 2012 02:01:05 +0000 Subject: [issue14524] Python-2.7.3rc2/Modules/_ctypes/libffi/src/dlmalloc.c won't compile on ia64-hp-hpux11.31 without -DHAVE_USR_INCLUDE_MALLOC_H In-Reply-To: <1333849818.58.0.912863620165.issue14524@psf.upfronthosting.co.za> Message-ID: <1333850465.48.0.094480272251.issue14524@psf.upfronthosting.co.za> R. David Murray added the comment: Is this a bug report about configure, or a bug report about a crash during compilation after you've adjusted the configure parameters? It seems like you are reporting two different things here. For the configure issue, would you care to suggest a patch? I don't believe we have any core developers with access to hpux. ---------- nosy: +r.david.murray type: crash -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 04:06:36 2012 From: report at bugs.python.org (Paul A.) Date: Sun, 08 Apr 2012 02:06:36 +0000 Subject: [issue14526] Python-2.6.8rc2 test never finishes ia64-hp-hpux11.31 Message-ID: <1333850796.49.0.00984513973581.issue14526@psf.upfronthosting.co.za> New submission from Paul A. : Perhaps I'm not interpreting something happening earlier, but `make test' here only seems to run a short time but doesn't actually finish. It appears not to be using any cpu, or waiting for input, so I'm not sure what's happening. ... test_grammar test_opcodes test_dict test_builtin test_exceptions test_types test_unittest test_doctest test_doctest2 test_py3kwarn test_py3kwarn skipped -- test.test_py3kwarn must be run with the -3 flag test_MimeWriter test_SimpleHTTPServer test_StringIO test___all__ test test___all__ failed -- Traceback (most recent call last): File "/usr/local/src/Python-2.6.8rc2/Lib/test/test___all__.py", line 103, in test_all self.check_all(modname) File "/usr/local/src/Python-2.6.8rc2/Lib/test/test___all__.py", line 39, in check_all modname, e.__class__.__name__, e)) AssertionError: __all__ failure in distutils.command: ImportError: No module named _sha256 test___future__ test__locale test_abc test_abstract_numbers test_aepack test_aepack skipped -- No module named aepack test_aifc test_al test_al skipped -- No module named al test_anydbm test_applesingle test_applesingle skipped -- No module named macostools test_array test_ast test_asynchat test test_asynchat failed -- multiple errors occurred; run in verbose mode for details test_asyncore test test_asyncore failed -- multiple errors occurred; run in verbose mode for details test_atexit test_audioop test_augassign test_base64 test_bastion test_bigaddrspace test_bigmem test_binascii test_binhex test_binop test_bisect test_bool test_bsddb test_bsddb skipped -- No module named _bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- No module named _bsddb test_buffer test_bufio test_bytes test_bz2 test_bz2 skipped -- No module named bz2 test_calendar test_call test_capi ---------- components: Tests messages: 157771 nosy: pda priority: normal severity: normal status: open title: Python-2.6.8rc2 test never finishes ia64-hp-hpux11.31 type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 04:06:46 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Apr 2012 02:06:46 +0000 Subject: [issue14525] ia64-hp-hpux11.31 won't compile Python-2.6.8rc2 without -D_TERMIOS_INCLUDED In-Reply-To: <1333850075.77.0.408518012212.issue14525@psf.upfronthosting.co.za> Message-ID: <1333850806.91.0.365739410767.issue14525@psf.upfronthosting.co.za> R. David Murray added the comment: Can you suggest a patch? As I said on the other issue I don't believe any core developers have access to hpux. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 04:10:54 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Apr 2012 02:10:54 +0000 Subject: [issue14526] Python-2.6.8rc2 test never finishes ia64-hp-hpux11.31 In-Reply-To: <1333850796.49.0.00984513973581.issue14526@psf.upfronthosting.co.za> Message-ID: <1333851054.07.0.992581775179.issue14526@psf.upfronthosting.co.za> R. David Murray added the comment: To quote Martin from an older issue: "Python on HP-UX has never really worked well, but it has worked in some fashion for a long time". IA64 probably introduces a whole slew of new issues. If you can work through them and suggest patches that would be great. If you are motivated to do this, you might want to sign up for the python core-mentorship list, where you can ask questions about how things work and get advice on fixing problems. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 04:12:12 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Apr 2012 02:12:12 +0000 Subject: [issue14526] Python-2.6.8rc2 test never finishes ia64-hp-hpux11.31 In-Reply-To: <1333850796.49.0.00984513973581.issue14526@psf.upfronthosting.co.za> Message-ID: <1333851132.68.0.232106487742.issue14526@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, and python2.6 is in security-fix only mode, so any fixes would only go into go into 2.7 and later. Have you gotten as far as trying to reproduce this on 2.7? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 04:13:39 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Apr 2012 02:13:39 +0000 Subject: [issue14526] Python-2.6.8rc2 test never finishes ia64-hp-hpux11.31 In-Reply-To: <1333850796.49.0.00984513973581.issue14526@psf.upfronthosting.co.za> Message-ID: <1333851219.8.0.431659811412.issue14526@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, wait, I see you are testing the security RC. Is this a new problem, or does it also occur with the previous released version of 2.6? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 04:25:35 2012 From: report at bugs.python.org (Paul A.) Date: Sun, 08 Apr 2012 02:25:35 +0000 Subject: [issue14527] How to link with an external libffi? Message-ID: <1333851935.11.0.629390980004.issue14527@psf.upfronthosting.co.za> New submission from Paul A. : I trying to build python using an external libffi package I have installed -- is there some trick in directing --with-system-ffi to the path where it's located. I don't see clues in config.log or anywhere to help. ---------- messages: 157776 nosy: pda priority: normal severity: normal status: open title: How to link with an external libffi? type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 07:58:29 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Sun, 08 Apr 2012 05:58:29 +0000 Subject: [issue14527] How to link with an external libffi? In-Reply-To: <1333851935.11.0.629390980004.issue14527@psf.upfronthosting.co.za> Message-ID: <1333864709.81.0.95644894871.issue14527@psf.upfronthosting.co.za> Ross Lagerwall added the comment: If it is in a non-standard location, try setting the environment variables: LDFLAGS linker flags, e.g. -L if you have libraries in a nonstandard directory CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I if you have headers in a nonstandard directory ---------- nosy: +rosslagerwall _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 08:56:48 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Apr 2012 06:56:48 +0000 Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za> Message-ID: <1333868208.35.0.161512154373.issue6972@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > + # make sure the zip file isn't traversing out of the path > + if not targetpath.startswith(basepath): Check is insufficient. basepath='/etc/asd', member.filename='../asdfgh'. The issue10905 has relations with this issue. P. S. Viewing patches in this issue is not working. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 09:10:28 2012 From: report at bugs.python.org (mattip) Date: Sun, 08 Apr 2012 07:10:28 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1333869028.12.0.0177458850406.issue14521@psf.upfronthosting.co.za> mattip added the comment: I was going to add a test for this to Lib/test/test_math.py, but found this comment: # copysign(INF, NAN) may be INF or it may be NINF, since # we don't know whether the sign bit of NAN is set on any # given platform. I would try to claim this is fixable, by this patch: --- Include\pymath.h.orig Sun Apr 08 10:02:37 2012 +++ Include\pymath.h Sun Apr 08 10:02:41 2012 @@ -150,7 +150,7 @@ * doesn't support NaNs. */ #if !defined(Py_NAN) && !defined(Py_NO_NAN) -#define Py_NAN (Py_HUGE_VAL * 0.) +#define Py_NAN abs(Py_HUGE_VAL * 0.) #endif /* Py_OVERFLOWED(X) Should I rework the tests to reflect this and submit a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 09:47:51 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Apr 2012 07:47:51 +0000 Subject: [issue2193] Cookie Colon Name Bug In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za> Message-ID: <1333871271.17.0.560098361379.issue2193@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 10:31:27 2012 From: report at bugs.python.org (d9pouces) Date: Sun, 08 Apr 2012 08:31:27 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za> Message-ID: <1333873887.43.0.287550040792.issue14455@psf.upfronthosting.co.za> d9pouces added the comment: Here is the new patch, allowing read and write binary, json and xml plist files. It includes both the plistlib.py and test/test_plistlib.py patches. JSON format does not allow dates and data, so XML is used by default to write files. I use the json library to write JSON plist files, but its output is slightly different from the Apple default output: keys of dictionaries are in different order. Thus, I removed the test_appleformattingfromliteral test for JSON files. Similarly, my binary writer does not write the same binary files as the Apple library: my library writes the content of compound objects (dicts, lists and sets) before the object itself, while Apple writes the object before its content. Copying the Apple behavior results in some additional weird lines of code, for little benefit. Thus, I also removed the test_appleformattingfromliteral test for binary files. Other tests are made for all the three formats. ---------- Added file: http://bugs.python.org/file25156/plistlib_with_test.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 12:00:37 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 08 Apr 2012 10:00:37 +0000 Subject: [issue14222] Use time.steady() to implement timeout In-Reply-To: <1331149120.51.0.79082225225.issue14222@psf.upfronthosting.co.za> Message-ID: <1333879237.05.0.881511168444.issue14222@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The "not subject to adjustment" property is more desirable than not. > The "undefined reference point" property isn't harmful in this context > (the start time isn't exposed). So you're closing the issue while you're in agreement with it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 12:05:38 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 08 Apr 2012 10:05:38 +0000 Subject: [issue14528] Document whether strings implement __iter__ Message-ID: <1333879538.06.0.592518387164.issue14528@psf.upfronthosting.co.za> New submission from Chris Jerdonek : While converting code from Python 2 to Python 3, I came across the "gotcha" that strings implement __iter__ in Python 3 but not in Python 2. Looking through the documentation, I don't seem to see anything like this mentioned in the library portion of either Python 2 or 3's documentation: http://docs.python.org/library/stdtypes.html#iterator-types http://docs.python.org/py3k/library/stdtypes.html#iterator-types Or in the documentation describing differences between 2 and 3: http://docs.python.org/release/3.0.1/whatsnew/3.0.html In fact, the Python 2 and 3 sections on iterator types seem largely the same. Python 2's documentation even seems a bit misleading in this regard. At the beginning of this section, it says, "Sequences, described below in more detail, always support the iteration methods [of which __iter__() is the main one]." And str and unicode are the first two types mentioned in that next section on sequence types. Here is a blog post I came across about this issue: http://plope.com/Members/chrism/python_2_vs_python_3_str_iter I think it would be worth highlighting this issue somewhere in the Python documentation, or at least acknowledging the change (unless I'm simply looking in the wrong place, in which case maybe it should be made more visible). ---------- assignee: docs at python components: Documentation messages: 157783 nosy: cjerdonek, docs at python priority: normal severity: normal status: open title: Document whether strings implement __iter__ type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 12:16:36 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 08 Apr 2012 10:16:36 +0000 Subject: [issue14528] Document whether strings implement __iter__ In-Reply-To: <1333879538.06.0.592518387164.issue14528@psf.upfronthosting.co.za> Message-ID: <1333880196.2.0.181569517585.issue14528@psf.upfronthosting.co.za> Georg Brandl added the comment: Why is it so important if strings implement __iter__? They are iterable in both versions, since iteration falls back on __getitem__ if no __iter__ is defined. For user code it is irrelevant which of the iteration protocols is present. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 12:39:17 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 08 Apr 2012 10:39:17 +0000 Subject: [issue14528] Document whether strings implement __iter__ In-Reply-To: <1333879538.06.0.592518387164.issue14528@psf.upfronthosting.co.za> Message-ID: <1333881557.53.0.0156906866109.issue14528@psf.upfronthosting.co.za> Chris Jerdonek added the comment: It is not "so important." I just feel that the change should be acknowledged somewhere -- insofar as the existing user documentation on iterator types already discusses __iter__(). As it stands now, the Python 2 documentation is a bit misleading because it seems to suggest that strings implement __iter__(). With regard to falling back to __getitem__(), that might actually be worth mentioning in the section on iterator types. Up until today, I didn't know there was a distinction between a "sequence protocol" and an "iterator protocol," as discussed here, for example-- http://blog.axant.it/archives/306 For user code, the user might want different behavior depending on whether something behaves like a list. For that, they might be relying on something like the presence of __iter__(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 12:43:42 2012 From: report at bugs.python.org (Georg Brandl) Date: Sun, 08 Apr 2012 10:43:42 +0000 Subject: [issue14528] Document whether strings implement __iter__ In-Reply-To: <1333879538.06.0.592518387164.issue14528@psf.upfronthosting.co.za> Message-ID: <1333881822.06.0.516190442809.issue14528@psf.upfronthosting.co.za> Georg Brandl added the comment: "behaves like a list" is misleading. If you mean checking for iterable-ness, calling iter() on the object is the way to do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 13:04:02 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 08 Apr 2012 11:04:02 +0000 Subject: [issue14528] Document whether strings implement __iter__ In-Reply-To: <1333879538.06.0.592518387164.issue14528@psf.upfronthosting.co.za> Message-ID: <1333883042.23.0.670586533695.issue14528@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Okay, then that also might be worth mentioning. As it stands now, the emphasis in the section on iterator types is on __iter__() (e.g. it is the main focus of the introduction), whereas iter() is barely mentioned (only in the sections on dicts and file objects). So in addition to the suggestions above, perhaps the introduction to the section on iterator types could include a link to the iter() function with a description of its relationship to iterator types. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 13:38:06 2012 From: report at bugs.python.org (=?utf-8?q?Esben_Agerb=C3=A6k_Black?=) Date: Sun, 08 Apr 2012 11:38:06 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: <1332849673.66.0.0828799259938.issue14423@psf.upfronthosting.co.za> Message-ID: <1333885086.15.0.427586965186.issue14423@psf.upfronthosting.co.za> Changes by Esben Agerb?k Black : Added file: http://bugs.python.org/file25157/isodates.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 15:45:20 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 08 Apr 2012 13:45:20 +0000 Subject: [issue10576] Add a progress callback to gcmodule In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za> Message-ID: <1333892720.43.0.30380537224.issue10576@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: A new patch, taking Antoine's review and comments into account. ---------- Added file: http://bugs.python.org/file25158/gccallback.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 16:04:39 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 08 Apr 2012 14:04:39 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1333893879.52.0.520049498413.issue14521@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- components: +Interpreter Core -None nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 16:28:06 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Apr 2012 14:28:06 +0000 Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za> Message-ID: <1333895286.06.0.606102533874.issue6972@psf.upfronthosting.co.za> R. David Murray added the comment: To clarify what Serhiy said about the patches, the link to the patch works, but the Reitveld review button isn't working. I get 'No issue exists with that id (6972)'. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 17:14:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 08 Apr 2012 15:14:05 +0000 Subject: [issue12805] Optimizations for bytes.join() et. al In-Reply-To: <1313973836.25.0.316459845083.issue12805@psf.upfronthosting.co.za> Message-ID: <1333898045.47.0.726917765654.issue12805@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Honestly, I don't think there's much point in these optimizations. The first one ("The sequence length and separator length are both 0") is probably useless. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 18:09:09 2012 From: report at bugs.python.org (Paul A.) Date: Sun, 08 Apr 2012 16:09:09 +0000 Subject: [issue14524] Python-2.7.3rc2/Modules/_ctypes/libffi/src/dlmalloc.c won't compile on ia64-hp-hpux11.31 without -DHAVE_USR_INCLUDE_MALLOC_H In-Reply-To: <1333850465.48.0.094480272251.issue14524@psf.upfronthosting.co.za> Message-ID: <20120408160901.GA13585@iceland> Paul A. added the comment: On Sun, Apr 08, 2012 at 02:01:05AM +0000, R. David Murray wrote: > > R. David Murray added the comment: > > Is this a bug report about configure, or a bug report about a crash during compilation after you've adjusted the configure parameters? It seems like you are reporting two different things here. You're right I see that doesn't quite make sense now. The crash is obviously much more critical. I don't suppose there's a way of changing the bug's title? I'll open a new one if not. > For the configure issue, would you care to suggest a patch? I don't believe we have any core developers with access to hpux. Sure, I'd like to eventually, but knowing very little about auto-tools that likely won't be very soon. Are there docs anyone can recommend? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 18:10:28 2012 From: report at bugs.python.org (Paul A.) Date: Sun, 08 Apr 2012 16:10:28 +0000 Subject: [issue14525] ia64-hp-hpux11.31 won't compile Python-2.6.8rc2 without -D_TERMIOS_INCLUDED In-Reply-To: <1333850806.91.0.365739410767.issue14525@psf.upfronthosting.co.za> Message-ID: <20120408161024.GB13585@iceland> Paul A. added the comment: On Sun, Apr 08, 2012 at 02:06:46AM +0000, R. David Murray wrote: > > R. David Murray added the comment: > > Can you suggest a patch? As I said on the other issue I don't believe any core developers have access to hpux. Sure, once I figure out what that patch will be. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 18:14:28 2012 From: report at bugs.python.org (Paul A.) Date: Sun, 08 Apr 2012 16:14:28 +0000 Subject: [issue14526] Python-2.6.8rc2 test never finishes ia64-hp-hpux11.31 In-Reply-To: <1333851219.8.0.431659811412.issue14526@psf.upfronthosting.co.za> Message-ID: <20120408161424.GC13585@iceland> Paul A. added the comment: On Sun, Apr 08, 2012 at 02:13:39AM +0000, R. David Murray wrote: > > R. David Murray added the comment: > > Oh, wait, I see you are testing the security RC. Is this a new problem, or does it also occur with the previous released version of 2.6? Yes... I'm not on that box right now, but from what I recall 2.6.7 and 2.7.2 did the same thing. But seems as though the 2.7.3 rc has regressed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 18:16:39 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Apr 2012 16:16:39 +0000 Subject: [issue14526] Python-2.6.8rc2 test never finishes ia64-hp-hpux11.31 In-Reply-To: <1333850796.49.0.00984513973581.issue14526@psf.upfronthosting.co.za> Message-ID: <1333901799.59.0.535316814514.issue14526@psf.upfronthosting.co.za> R. David Murray added the comment: Can you clarify? In what sense has the 2.7.3 rc regressed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 18:17:32 2012 From: report at bugs.python.org (Paul A.) Date: Sun, 08 Apr 2012 16:17:32 +0000 Subject: [issue14527] How to link with an external libffi? In-Reply-To: <1333864709.81.0.95644894871.issue14527@psf.upfronthosting.co.za> Message-ID: <20120408161729.GD13585@iceland> Paul A. added the comment: On Sun, Apr 08, 2012 at 05:58:29AM +0000, Ross Lagerwall wrote: > > Ross Lagerwall added the comment: > > If it is in a non-standard location, try setting the environment variables: > > LDFLAGS linker flags, e.g. -L if you have libraries in a nonstandard directory > CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I if you have headers in a nonstandard directory I'm pretty sure I've already been doing that, but I'll verify again soon when I get the chance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 18:30:59 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 08 Apr 2012 16:30:59 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1333902659.64.0.93638779542.issue14521@psf.upfronthosting.co.za> Mark Dickinson added the comment: Hmm. I don't see this as a bug: the sign of a nan isn't really all that meaningful anyway, and this doesn't (AFAIK) contradict any documentation. On the other hand, given that most other aspects of floating-point are now reasonably portable across platforms (or at least those platforms that support IEEE 754), it may make sense to standardise this too, as a minor improvement for Python 3.3. The patch does not look correct to me: did you mean 'fabs' rather than 'abs'? Even then, the C standard says nothing (not even in annex F) about how fabs should behave when applied to a NaN. Instead, if the platform supports IEEE 754 (e.g., if the short float repr code is in use), we could hard-code a NaN bit representation. (Even though there are 2**53-2 distinct bit patterns representing NaNs, there are nevertheless a couple of obvious ones to choose: there are exactly two quiet NaNs that don't arise by silencing a signaling NaN. The one with the sign bit cleared would be an obvious choice; I think it's the negation of the one that Intel uses by default, which does indeed have its sign bit set.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 19:06:03 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 08 Apr 2012 17:06:03 +0000 Subject: [issue14522] Avoid using DuplicateHandle() on sockets in multiprocessing.connection In-Reply-To: <1333825363.09.0.353081584992.issue14522@psf.upfronthosting.co.za> Message-ID: <1333904763.69.0.717289065055.issue14522@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: multiprocessing.reduction still appears to use DuplicateHandle to copy sockets. I propose adding a pair of custom functions to _multiprocessing, that "pickles" and "unpickles" handles. It can detect socket handles as being different from e.g. pipe handles by using WSADuplicateSocket and return a bytes object, similar to what is already done in socketmodule (see issue 14310) On non-windows, this would be a no-op. _multiprocessing already linkes with winsock, whereas the subprocess is part of python core which doesn't. ---------- nosy: +kristjan.jonsson status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 19:07:43 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 08 Apr 2012 17:07:43 +0000 Subject: [issue14288] Make iterators pickleable In-Reply-To: <1331655020.29.0.612944465478.issue14288@psf.upfronthosting.co.za> Message-ID: <1333904863.54.0.665418511835.issue14288@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 19:30:56 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 08 Apr 2012 17:30:56 +0000 Subject: [issue14520] Buggy Decimal.__sizeof__ In-Reply-To: <1333796139.51.0.465726080972.issue14520@psf.upfronthosting.co.za> Message-ID: <1333906256.63.0.126919248648.issue14520@psf.upfronthosting.co.za> Martin v. L?wis added the comment: There are really two options: a) if an object is a container, and the contained is accessible to reflection (preferably through gc.get_referents), then the container shouldn't account for the size of the contained. b) if the contained is not accessible (except for sys.get_objects() in a debug build), then the container should provide the total sum. A memory debugger is supposed to find all objects (e.g. through gc.get_objects, and gc.get_referents), eliminate duplicate references, and then apply sys.getsizeof for each object. This should then not leave out any memory, and not count any memory twice. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 19:49:19 2012 From: report at bugs.python.org (Mario Vilas) Date: Sun, 08 Apr 2012 17:49:19 +0000 Subject: [issue14529] distutils's build_msi command ignores the data_files argument Message-ID: <1333907359.21.0.0116056941941.issue14529@psf.upfronthosting.co.za> New submission from Mario Vilas : When creating an MSI installer on Python 2.7 (Windows, both in 32 and 64 bits) the data_files argument of the setup function is completely ignored. This results in broken installations. ---------- assignee: eric.araujo components: Distutils messages: 157799 nosy: Mario.Vilas, eric.araujo, tarek priority: normal severity: normal status: open title: distutils's build_msi command ignores the data_files argument versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 19:50:21 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 08 Apr 2012 17:50:21 +0000 Subject: [issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za> Message-ID: <1333907421.43.0.161888485586.issue7839@psf.upfronthosting.co.za> Andrew Svetlov added the comment: If fylesystem doesn't support unicode (only Windows directly does as I know) str filename should to be converted by `sys.getfilesystemencoding()`. `os.exec` family already does it as well as other fs functions ? but they are supports bytes also. Mayby deprecation bytes for high-level Popen is good idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 19:58:20 2012 From: report at bugs.python.org (Mario Vilas) Date: Sun, 08 Apr 2012 17:58:20 +0000 Subject: [issue14530] distutils's build_wininst command fails to correctly interpret the data_files argument Message-ID: <1333907900.33.0.191070589139.issue14530@psf.upfronthosting.co.za> New submission from Mario Vilas : I tried the following: setup( data_files = [(sys.prefix_exec, os.path.join('Win32', 'BeaEngine.dll'))] # (... rest of the setup call here...) ) This works perfectly when running the "python setup.py install". But when generating an installer (not MSI but the exe file), the installer places the 'BeaEngine.dll' in a subdirectory called 'python27'. For 64 bit builds, the subdirectory is called 'Python27-x64' instead. The paths to my python installations are "C:\Python27" and "C:\Python27-x64" respectively. The target folders should have been those, not "C:\Python27-x64\Python27-x64" which is clearly wrong. So far my workaround was this: data_files = [(os.path.join(sys.prefix_exec,'..'), os.path.join('Win32', 'BeaEngine.dll'))] But of course, now my setup.py script only works for generating the installer, not for installing the module from sources. ---------- assignee: eric.araujo components: Distutils messages: 157801 nosy: Mario.Vilas, eric.araujo, tarek priority: normal severity: normal status: open title: distutils's build_wininst command fails to correctly interpret the data_files argument versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 19:59:16 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Apr 2012 17:59:16 +0000 Subject: [issue12805] Optimizations for bytes.join() et. al In-Reply-To: <1333898045.47.0.726917765654.issue12805@psf.upfronthosting.co.za> Message-ID: <1333908098.13774.49.camel@raxxla> Serhiy Storchaka added the comment: > Honestly, I don't think there's much point in these optimizations. The first one ("The sequence length and separator length are both 0") is probably useless. This optimization changes the behavior. ... def __repr__(self): return 'B(' + super().__repr__() + ')' ... >>> B() B(b'') >>> B().join([]) b'' With the patch we get B(b''). Regardless of whether optimization (which is negligible in this case), I don't know whether to consider such side effect desirable or undesirable. bytes.join need to optimize for the 0- and 1-byte delimiter, but the proposed patch leads to pessimization: Unpatched: $ ./python -m timeit -s 'seq=[bytes([i]*100000) for i in range(256)]' 'b"".join(seq)' 10 loops, best of 3: 43.3 msec per loop Patched: $ ./python -m timeit -s 'seq=[bytes([i]*100000) for i in range(256)]' 'b" ".join(seq)' 10 loops, best of 3: 70.3 msec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 20:03:30 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Apr 2012 18:03:30 +0000 Subject: [issue12805] Optimizations for bytes.join() et. al In-Reply-To: <1333908098.13774.49.camel@raxxla> Message-ID: <1333908353.13774.51.camel@raxxla> Serhiy Storchaka added the comment: > Regardless of whether optimization (which is negligible in this case), I don't know whether to consider such side effect desirable or undesirable. After some thought, I realized that this is an erroneous behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 20:37:45 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 08 Apr 2012 18:37:45 +0000 Subject: [issue12805] Optimizations for bytes.join() et. al In-Reply-To: <1313973836.25.0.316459845083.issue12805@psf.upfronthosting.co.za> Message-ID: <1333910265.25.0.343508440903.issue12805@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Side note: Windows requires that args be quoted with ", not ', to work properly, at least with these args. Main note: the patched test adds a space to the separator, but that is not enough to account for the difference. c:\Programs\Python32>python -m timeit -s "seq=[bytes([i]*1000) for i in range(256)]" "b''.join(seq)" 10000 loops, best of 3: 31.7 usec per loop c:\Programs\Python32>python -m timeit -s "seq=[bytes([i]*1000) for i in range(256)]" "b' '.join(seq)" 10000 loops, best of 3: 34.1 usec per loop The behavior change is wrong and test_bytes.py seems to need augmentation. It begins with "XXX This is a mess. [...]". class BaseBytesTest(unittest.TestCase): def test_join(self) tests b''.join([]) but as far as I can tell, not b'something'.join([]), the failing case found by Serhiy. It end with " # XXX more...". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 21:01:23 2012 From: report at bugs.python.org (Edward Yang) Date: Sun, 08 Apr 2012 19:01:23 +0000 Subject: [issue14531] Backtrace should not attempt to open file Message-ID: <1333911683.02.0.244330903259.issue14531@psf.upfronthosting.co.za> New submission from Edward Yang : When generating a backtrace from an interactive Python session (e.g. the input is from , Python attempts to actually find a file named , to somewhat hilarious consequences. See the strace'd Python session below: >>> foo open("/etc/default/apport", O_RDONLY|O_LARGEFILE) = 3 Traceback (most recent call last): File "", line 1, in open("", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.7/dist-packages/pylint-0.24.0-py2.7.egg/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.7/dist-packages/logilab_astng-0.22.0-py2.7.egg/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.7/dist-packages/logilab_common-0.56.1-py2.7.egg/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.7/dist-packages/unittest2-0.5.1-py2.7.egg/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.7/dist-packages/GitPython-0.3.2.RC1-py2.7.egg/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.7/dist-packages/gitdb-0.5.4-py2.7-linux-i686.egg/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.7/dist-packages/smmap-0.8.1-py2.7.egg/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.7/dist-packages/async-0.6.1-py2.7-linux-i686.egg/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.7/dist-packages/decorator-3.3.1-py2.7.egg/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.2-py2.7-linux-i686.egg/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.7/dist-packages/Sphinx-1.0.7-py2.7.egg/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.7/dist-packages/docutils-0.8.1-py2.7.egg/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.7/dist-packages/Jinja2-2.6-py2.7.egg/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.7/dist-packages/Pygments-1.4-py2.7.egg/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.7/dist-packages/nose-1.1.2-py2.7.egg/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/home/ezyang/Dev/6.02/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/home/ezyang/Dev/pyafs/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/home/ezyang/Dev/wizard/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/home/ezyang/Dev/twisted/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.6/site-packages/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/home/ezyang/Work/shared-python/build/lib.linux-i686-2.6/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/home/ezyang/Work/snarfs/python/coil/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/home/ezyang/Dev/py-github/src/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/plat-linux2/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/lib-tk/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/lib-old/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/lib-dynload/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/local/lib/python2.7/dist-packages/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/dist-packages/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/dist-packages/Numeric/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/dist-packages/PIL/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/dist-packages/gst-0.10/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/dist-packages/gtk-2.0/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/pymodules/python2.7/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/pymodules/python2.7/libubuntuone/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/dist-packages/ubuntu-sso-client/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/dist-packages/ubuntuone-client/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/dist-packages/ubuntuone-control-panel/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/dist-packages/ubuntuone-couch/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/dist-packages/ubuntuone-installer/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/dist-packages/ubuntuone-storage-protocol/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) NameError: name 'foo' is not defined >>> ---------- components: Library (Lib) messages: 157805 nosy: ezyang priority: normal severity: normal status: open title: Backtrace should not attempt to open file versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 21:08:26 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 08 Apr 2012 19:08:26 +0000 Subject: [issue12805] Optimizations for bytes.join() et. al In-Reply-To: <1333910265.25.0.343508440903.issue12805@psf.upfronthosting.co.za> Message-ID: <1333912247.13774.61.camel@raxxla> Serhiy Storchaka added the comment: > Main note: the patched test adds a space to the separator, but that is not enough to account for the difference. Sorry, I copied the wrong line. $ ./python -m timeit -s "seq=[bytes([i]*100000) for i in range(256)]" "b' '.join(seq)" 10 loops, best of 3: 45.6 msec per loop But the conclusions are not affected, for larger byte strings patched version will be 1.5-2 times slower in limit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 21:25:10 2012 From: report at bugs.python.org (mattip) Date: Sun, 08 Apr 2012 19:25:10 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1333913110.63.0.416452500717.issue14521@psf.upfronthosting.co.za> mattip added the comment: You are correct, the patch should use fabs I would go with a standard, cross-platform definition of Py_NAN so that pickled objects could be opened by other platforms. Would this patch be better? It's more complicated as I needed to cast the repr of Py_NAN to a unsigned char[]. It passes the tests in test.test_math and handles the copysign in a more intuitive way >>> math.copysign(1., float('nan')) => 1. on win32, microsoft compiler diff -r efeca6ff2751 Include/pymath.h --- a/Include/pymath.h Thu Apr 05 22:51:00 2012 +0200 +++ b/Include/pymath.h Sun Apr 08 22:20:16 2012 +0300 @@ -152,8 +152,13 @@ * doesn't support NaNs. */ #if !defined(Py_NAN) && !defined(Py_NO_NAN) +#if DBL_MANT_DIG == 53 /* ieee 754 doubles */ +extern double * _Py_NAN; +#define Py_NAN (*_Py_NAN) +#else #define Py_NAN (Py_HUGE_VAL * 0.) #endif +#endif /* Py_OVERFLOWED(X) * Return 1 iff a libm function overflowed. Set errno to 0 before calling diff -r efeca6ff2751 Modules/_math.c --- a/Modules/_math.c Thu Apr 05 22:51:00 2012 +0200 +++ b/Modules/_math.c Sun Apr 08 22:20:16 2012 +0300 @@ -24,6 +24,10 @@ static const double two_pow_p28 = 268435456.0; /* 2**28 */ static const double zero = 0.0; +#if DBL_MANT_DIG == 53 /* ieee 754 doubles */ +static const unsigned char _Py_NAN_as_char[8] = {0, 0, 0, 0, 0, 0, 0xf8, 0x7f}; +extern double * _Py_NAN = (double *)(_Py_NAN_as_char); +#endif /* acosh(x) * Method : * Based on ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 22:13:20 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 08 Apr 2012 20:13:20 +0000 Subject: [issue14528] Document whether strings implement __iter__ In-Reply-To: <1333879538.06.0.592518387164.issue14528@psf.upfronthosting.co.za> Message-ID: <1333916000.81.0.272624275655.issue14528@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry, I agree with Georg, this isn't a bug, not even a documentation bug. A type is free to implement iteration either by way of __iter__ or by way of __getitem__. How it chooses to do so is an implementation detail (and different implementations have made different choices). ---------- nosy: +rhettinger resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 22:27:43 2012 From: report at bugs.python.org (Jon Oberheide) Date: Sun, 08 Apr 2012 20:27:43 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison Message-ID: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> New submission from Jon Oberheide : The multiprocessing module performs a time-dependent comparison of the HMAC digest used for authentication: def deliver_challenge(connection, authkey): import hmac assert isinstance(authkey, bytes) message = os.urandom(MESSAGE_LENGTH) connection.send_bytes(CHALLENGE + message) digest = hmac.new(authkey, message).digest() response = connection.recv_bytes(256) # reject large message if response == digest: connection.send_bytes(WELCOME) else: connection.send_bytes(FAILURE) raise AuthenticationError('digest received was wrong') This comparison should be made time-independent as to not leak information about the expected digest and allow an attacker to derive the full digest. More info on such timing attacks: http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/ http://rdist.root.org/2010/07/19/exploiting-remote-timing-attacks/ ---------- components: Library (Lib) messages: 157809 nosy: Jon.Oberheide priority: normal severity: normal status: open title: multiprocessing module performs a time-dependent hmac comparison _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 23:45:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 08 Apr 2012 21:45:50 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1333921550.31.0.110013197664.issue14532@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 23:47:37 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 08 Apr 2012 21:47:37 +0000 Subject: [issue14531] Backtrace should not attempt to open file In-Reply-To: <1333911683.02.0.244330903259.issue14531@psf.upfronthosting.co.za> Message-ID: <1333921657.86.0.796649615509.issue14531@psf.upfronthosting.co.za> Ned Deily added the comment: That does seem like silly behavior. On the other hand, the only ill effect is likely the time required to execute the series of open calls which, in the interactive case, would not even be noticed on most systems. Would you be interested in writing a patch? ---------- nosy: +ned.deily priority: normal -> low stage: -> needs patch versions: +Python 3.2, Python 3.3 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 8 23:52:19 2012 From: report at bugs.python.org (Edward Yang) Date: Sun, 08 Apr 2012 21:52:19 +0000 Subject: [issue14531] Backtrace should not attempt to open file In-Reply-To: <1333911683.02.0.244330903259.issue14531@psf.upfronthosting.co.za> Message-ID: <1333921939.95.0.986217567494.issue14531@psf.upfronthosting.co.za> Edward Yang added the comment: "" is a valid name of a file on Unix systems. So the fix is not so clear. ezyang at javelin:~$ python Python 2.7.2+ (default, Oct 4 2011, 20:03:08) [GCC 4.6.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a Traceback (most recent call last): File "", line 1, in Here?s an idea: when a (multi-variable) calculus course arrives at the topic of the *chain rule*, it should use as a worked example the multilayer perceptron?a topic you usually only find in an introductory artificial intelligence course. In fact, it?s ideal, since the treatment of this topic in most AI courses (at this point, I?ve taken two?a byproduct of slightly mismatched class schedules when you study abroad) involves *no* extra theoretical computer science content whatsoever. If you know the definition of a multilayer perceptron, any Calculus student who knows the chain rule should be able to work out the back-propagation algorithm?or perhaps I should call it a *recurrence.* NameError: name 'a' is not defined ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 00:05:12 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 08 Apr 2012 22:05:12 +0000 Subject: [issue14528] Document whether strings implement __iter__ In-Reply-To: <1333879538.06.0.592518387164.issue14528@psf.upfronthosting.co.za> Message-ID: <1333922712.86.0.44243689005.issue14528@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Is there a mechanism for suggesting improvements to the documentation (e.g. for pedagogical reasons)? I tried to classify this as an enhancement request rather than as a bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 00:44:37 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 08 Apr 2012 22:44:37 +0000 Subject: [issue14522] Avoid using DuplicateHandle() on sockets in multiprocessing.connection In-Reply-To: <1333825363.09.0.353081584992.issue14522@psf.upfronthosting.co.za> Message-ID: <1333925077.55.0.492194591326.issue14522@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > multiprocessing.reduction still appears to use DuplicateHandle to copy sockets. It's probably a separate issue, then. This one is about multiprocessing.connection :) ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 00:59:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 08 Apr 2012 22:59:33 +0000 Subject: [issue7978] SocketServer doesn't handle syscall interruption In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 5493d44b56d8 by Antoine Pitrou in branch '3.2': Issue #7978: socketserver now restarts the select() call when EINTR is returned. http://hg.python.org/cpython/rev/5493d44b56d8 New changeset 97a0c6230ece by Antoine Pitrou in branch 'default': Issue #7978: socketserver now restarts the select() call when EINTR is returned. http://hg.python.org/cpython/rev/97a0c6230ece ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 01:12:46 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 08 Apr 2012 23:12:46 +0000 Subject: [issue7978] SocketServer doesn't handle syscall interruption In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset d941d1fcc6e6 by Antoine Pitrou in branch '2.7': Issue #7978: socketserver now restarts the select() call when EINTR is returned. http://hg.python.org/cpython/rev/d941d1fcc6e6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 01:16:48 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 08 Apr 2012 23:16:48 +0000 Subject: [issue14533] Modify regrtest to make test_main optional Message-ID: <1333927007.96.0.584520357529.issue14533@psf.upfronthosting.co.za> New submission from R. David Murray : The attached patch makes 'test_main' optional for stdlib tests. If a test module does not have a 'test_main', regrtest will use the unittest loadTestsFromModule loader to load the tests. This moves us further in the direction of using normal unittest facilities instead of specialized regrtest ones. Any test module that can be correctly run currently using python unittest -m test.test_xxx could be converted to use this by simply deleting its test_main, thus no longer requiring manual maintenance of the list of tests to run. Not all tests can be converted that easily, however, since test_main sometimes does some additional things (such as reap_children or reap_threads). ---------- files: dont_require_test_main.patch keywords: patch messages: 157816 nosy: michael.foord, pitrou, r.david.murray priority: normal severity: normal status: open title: Modify regrtest to make test_main optional type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25159/dont_require_test_main.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 01:21:19 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 08 Apr 2012 23:21:19 +0000 Subject: [issue7978] SocketServer doesn't handle syscall interruption In-Reply-To: Message-ID: STINNER Victor added the comment: You must recompute the timeout when select() is interrupted: see issue #12338. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 01:25:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 08 Apr 2012 23:25:20 +0000 Subject: [issue7978] SocketServer doesn't handle syscall interruption In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za> Message-ID: <1333927520.15.0.0134724815164.issue7978@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > You must recompute the timeout when select() is interrupted: see issue > #12338. Ah, right. It's a minor issue, though. I would suggest opening a separate issue for it. The patch is now committed to all 3 branches (I'm finally convinced this is a bug worth fixing), so I'm closing this issue. ---------- assignee: gregory.p.smith -> resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed type: behavior -> enhancement versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 01:25:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 08 Apr 2012 23:25:25 +0000 Subject: [issue7978] SocketServer doesn't handle syscall interruption In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za> Message-ID: <1333927525.84.0.432030897739.issue7978@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 01:29:57 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 08 Apr 2012 23:29:57 +0000 Subject: [issue12338] multiprocessing.util._eintr_retry doen't recalculate timeouts In-Reply-To: <1308144268.86.0.218604754177.issue12338@psf.upfronthosting.co.za> Message-ID: <1333927797.45.0.148520451142.issue12338@psf.upfronthosting.co.za> STINNER Victor added the comment: SocketServer has been changed to restart select() on EINTR, but it doesn't recompute the timeout. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 01:30:22 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 08 Apr 2012 23:30:22 +0000 Subject: [issue12338] multiprocessing.util._eintr_retry doen't recalculate timeouts In-Reply-To: <1308144268.86.0.218604754177.issue12338@psf.upfronthosting.co.za> Message-ID: <1333927822.01.0.639308118618.issue12338@psf.upfronthosting.co.za> STINNER Victor added the comment: > SocketServer has been changed to restart select() on EINTR, > but it doesn't recompute the timeout. See issue #7978. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 01:32:07 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 08 Apr 2012 23:32:07 +0000 Subject: [issue12338] multiprocessing.util._eintr_retry doen't recalculate timeouts In-Reply-To: <1308144268.86.0.218604754177.issue12338@psf.upfronthosting.co.za> Message-ID: <1333927927.8.0.615860427417.issue12338@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note that socketserver's timeout is not really important: it's just used for a polling loop, with a default of 0.5 seconds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 01:34:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 08 Apr 2012 23:34:06 +0000 Subject: [issue14531] Backtrace should not attempt to open file In-Reply-To: <1333911683.02.0.244330903259.issue14531@psf.upfronthosting.co.za> Message-ID: <1333928046.5.0.597190238906.issue14531@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 01:38:43 2012 From: report at bugs.python.org (Jerzy Kozera) Date: Sun, 08 Apr 2012 23:38:43 +0000 Subject: [issue7978] SocketServer doesn't handle syscall interruption In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za> Message-ID: <1333928323.52.0.929484286867.issue7978@psf.upfronthosting.co.za> Jerzy Kozera added the comment: I forgot to mention my patch is 3.3-only, sorry - it depends on changes from #12555 (http://hg.python.org/cpython/rev/41a1de81ef2b#l18.21 to be precise). To support 3.2 and 2.7: (1) select.error must be caught as in the original patch, (2) e.args[0] must be used - select.error doesn't have 'errno' attribute. Should I prepare the patch for 3.2 and 2.7? Regarding not updating the timeout, it was already mentioned above. Though as an afterthought, it might be worrying that if the process is receiving repeated signals with interval between them less than timeout, we might fall into infinite loop of select() when it should timeout, but that is probably very obscure case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 01:39:02 2012 From: report at bugs.python.org (Michael Foord) Date: Sun, 08 Apr 2012 23:39:02 +0000 Subject: [issue14533] Modify regrtest to make test_main optional In-Reply-To: <1333927007.96.0.584520357529.issue14533@psf.upfronthosting.co.za> Message-ID: <1333928342.15.0.213768112893.issue14533@psf.upfronthosting.co.za> Michael Foord added the comment: Looks good to me. Note that if module level setup and teardown is needed for running tests then it should be possible to do this with setUpModule and tearDownModule functions (unless those should *only* be done when running under regrtest). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 01:47:13 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 08 Apr 2012 23:47:13 +0000 Subject: [issue7978] SocketServer doesn't handle syscall interruption In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f8e7fcd581ff by Antoine Pitrou in branch '3.2': Fix the patch for issue #7978: select() raises select.error before 3.3, not OSError. http://hg.python.org/cpython/rev/f8e7fcd581ff New changeset 4298d6e79ecb by Antoine Pitrou in branch '2.7': Fix the patch for issue #7978: select() raises select.error before 3.3, not OSError. http://hg.python.org/cpython/rev/4298d6e79ecb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 01:48:12 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 08 Apr 2012 23:48:12 +0000 Subject: [issue7978] SocketServer doesn't handle syscall interruption In-Reply-To: <1333928323.52.0.929484286867.issue7978@psf.upfronthosting.co.za> Message-ID: <1333928564.3367.4.camel@localhost.localdomain> Antoine Pitrou added the comment: > To support 3.2 and 2.7: > (1) select.error must be caught as in the original patch, > (2) e.args[0] must be used - select.error doesn't have 'errno' > attribute. > Should I prepare the patch for 3.2 and 2.7? It shouldn't be necessary, I've just committed fixes. Thanks for noticing! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 01:48:49 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 08 Apr 2012 23:48:49 +0000 Subject: [issue14531] Backtrace should not attempt to open file In-Reply-To: <1333911683.02.0.244330903259.issue14531@psf.upfronthosting.co.za> Message-ID: <1333928929.17.0.570232129064.issue14531@psf.upfronthosting.co.za> STINNER Victor added the comment: The filename is retrieved from: traceback->frame->f_code->co_filename. co_filename is an arbitrary string. Example: >>> exec(compile("1+a", "/etc/passwd", "exec")) Traceback (most recent call last): File "", line 1, in File "/etc/passwd", line 1, in root:x:0:0:root:/root:/bin/bash NameError: name 'a' is not defined "root:x:0:0:root:/root:/bin/bash" is the first line of the /etc/passwd file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 01:59:03 2012 From: report at bugs.python.org (Jim Jewett) Date: Sun, 08 Apr 2012 23:59:03 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333765937.29.0.197499608927.issue14502@psf.upfronthosting.co.za> Message-ID: Jim Jewett added the comment: On Fri, Apr 6, 2012 at 10:32 PM, R. David Murray wrote: > R. David Murray added the comment: > I, on the other hand, would prefer if it were made part of the API contract that an > error is raised, and to fix any stdlib implementations *of that API* that don't conform > to that. ?(That is, locks from other modules may well not follow that API, and their > documentation should cover their API.) Do you consider it reasonable that all stdlib Locks follow that API, and change to raise either RuntimeError or a subclass? I don't feel comfortable declaring that (not even only for future feature releases), but if you do, or Guido does, or ... etc ... I'll submit patches for at least dummy_threading and logging. -jJ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 02:54:29 2012 From: report at bugs.python.org (Paul A.) Date: Mon, 09 Apr 2012 00:54:29 +0000 Subject: [issue14526] Python-2.6.8rc2 test never finishes ia64-hp-hpux11.31 In-Reply-To: <1333901799.59.0.535316814514.issue14526@psf.upfronthosting.co.za> Message-ID: <20120409005424.GE13585@iceland> Paul A. added the comment: On Sun, Apr 08, 2012 at 04:16:39PM +0000, R. David Murray wrote: > > R. David Murray added the comment: > > Can you clarify? In what sense has the 2.7.3 rc regressed? Shouldn't have left that out -- I was referring to the crash in that other bug I opened. I don't think that was happening in 2.7.2, but I should really confirm before spouting off too loudly. I'm not on that network today, so let me get back to you tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 03:52:02 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 09 Apr 2012 01:52:02 +0000 Subject: [issue14533] Modify regrtest to make test_main optional In-Reply-To: <1333927007.96.0.584520357529.issue14533@psf.upfronthosting.co.za> Message-ID: <1333936322.51.0.74354007344.issue14533@psf.upfronthosting.co.za> R. David Murray added the comment: I can't imagine when you'd *not* want setUpModule/tearDownModule to run, so that's a reasonable conversion path. The other path for reap_children and reap_threads would be to apply them to the individual classes that require them within the test module. Which you do depends on how many test classes need the cleanups, I think. I'm sure there will be other subtleties to be solved for other modules. Note that I'm not advocating anyone go through and wholesale convert test modules. But I think any time someone would otherwise have to update the list of tests in test_main, converting that test to eliminate test_main should be considered. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 03:58:18 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 09 Apr 2012 01:58:18 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za> Message-ID: <1333936698.99.0.254633014301.issue14502@psf.upfronthosting.co.za> R. David Murray added the comment: I think dummy_threading should be fixed (but only in 3.3, just in case it causes any backward compatibility issues with someone's code). Logging I'd leave to Vinay to decide about. I'm assuming that if any of the others devs nosy on this issue disagree with me that they will speak up :) ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 04:36:40 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 09 Apr 2012 02:36:40 +0000 Subject: [issue12537] mailbox's _become_message is very fragile In-Reply-To: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 5c1c402a63e5 by R David Murray in branch 'default': #12537: in mailbox avoid depending on knowledge of email package internals http://hg.python.org/cpython/rev/5c1c402a63e5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 04:43:23 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 09 Apr 2012 02:43:23 +0000 Subject: [issue12537] mailbox's _become_message is very fragile In-Reply-To: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za> Message-ID: <1333939403.83.0.465219074949.issue12537@psf.upfronthosting.co.za> R. David Murray added the comment: David, thanks for your assistance. I didn't wind up using your patch, but the work you did was valuable in preparing the patch I committed. What I did was turn your 'detect the attributes' recipe into a unit test. I then applied your patch, but it didn't quite work. I eventually figured out that the fix I suggested wasn't quite right, that in fact the right place to delete the attributes is in _become_message. So I moved the list of attributes you developed in your patch into class attributes, so that what the final patch does is to copy everything *except* the attributes you found. So, a successful resolution, thank you. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 04:50:09 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 09 Apr 2012 02:50:09 +0000 Subject: [issue14523] IDLE's subprocess startup error In-Reply-To: <1333840546.69.0.270630772659.issue14523@psf.upfronthosting.co.za> Message-ID: <1333939809.57.0.242674952479.issue14523@psf.upfronthosting.co.za> R. David Murray added the comment: I'm sorry, but the bug tracker isn't a good place to get help. You'll have better luck getting assistance for this on the python-list mailing list (see mail.python.org). ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed type: crash -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 10:08:31 2012 From: report at bugs.python.org (Josh Triplett) Date: Mon, 09 Apr 2012 08:08:31 +0000 Subject: [issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?) In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za> Message-ID: <1333958911.82.0.925391365111.issue10181@psf.upfronthosting.co.za> Josh Triplett added the comment: I currently use Python 2.7, and I'd like to make use of memoryview. Specifically, I work on BITS (http://biosbits.org/), which runs Python in ring 0 as part of GRUB, and I'd like to use memoryview to give Python access to data in physical memory. I ran into several of the problems documented here when trying to do so. I'd really love to see a backport of this fixed version into 2.7. ---------- nosy: +joshtriplett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 10:15:57 2012 From: report at bugs.python.org (Josh Triplett) Date: Mon, 09 Apr 2012 08:15:57 +0000 Subject: [issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?) In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za> Message-ID: <1333959357.15.0.779031124105.issue10181@psf.upfronthosting.co.za> Josh Triplett added the comment: > I currently use Python 2.7, and I'd like to make use of memoryview. Specifically, I work on BITS (http://biosbits.org/), which runs Python in ring 0 as part of GRUB, and I'd like to use memoryview to give Python access to data in physical memory. I ran into several of the problems documented here when trying to do so. I'd really love to see a backport of this fixed version into 2.7. More specifically, the primary functionality that I'd like to use exists in 3.3 as PyMemoryView_FromMemory. I've tried to approximate that function using the available API in 2.7, but that led me here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 12:38:24 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 09 Apr 2012 10:38:24 +0000 Subject: [issue14522] Avoid using DuplicateHandle() on sockets in multiprocessing.connection In-Reply-To: <1333825363.09.0.353081584992.issue14522@psf.upfronthosting.co.za> Message-ID: <1333967904.15.0.00359889375408.issue14522@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: possibly, multiprocessing.Connection uses handles, which can be socket handles on windows, and that code also uses DuplicateHandle. I think a generic solution must be found for multiprocessing, so I'll create a separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 12:52:42 2012 From: report at bugs.python.org (sbt) Date: Mon, 09 Apr 2012 10:52:42 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1333968762.94.0.141984861563.issue14532@psf.upfronthosting.co.za> sbt added the comment: I only looked quickly at the web pages, so I may have misunderstood. But it sounds like this applies when the attacker gets multiple chances to guess the digest for a *fixed* message (which was presumably chosen by the attacker). That is not the case here because deliver_challenge() generates a new message each time. Therefore the expected digest changes each time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 13:49:58 2012 From: report at bugs.python.org (sbt) Date: Mon, 09 Apr 2012 11:49:58 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1333972198.92.0.136170705083.issue4892@psf.upfronthosting.co.za> sbt added the comment: There is an undocumented function multiprocessing.allow_connection_pickling() whose docstring claims it allows connection and socket objects to be pickled. The attached patch fixes the multiprocessing.reduction module so that it works correctly. This means that TestPicklingConnections can be reenabled in the unit tests. The patch uses the new socket.share() and socket.fromshare() methods on Windows. ---------- keywords: +patch Added file: http://bugs.python.org/file25160/mp_pickle_conn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 13:56:22 2012 From: report at bugs.python.org (sbt) Date: Mon, 09 Apr 2012 11:56:22 +0000 Subject: [issue14522] Avoid using DuplicateHandle() on sockets in multiprocessing.connection In-Reply-To: <1333825363.09.0.353081584992.issue14522@psf.upfronthosting.co.za> Message-ID: <1333972582.86.0.360019959266.issue14522@psf.upfronthosting.co.za> sbt added the comment: > I think a generic solution must be found for multiprocessing, so I'll > create a separate issue. I have submitted a patch for Issue 4892 which makes connection and socket objects picklable. It uses socket.share() and socket.fromshare() on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 14:04:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 12:04:29 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1333973069.83.0.505361358128.issue4892@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Unless there's a technical barrier, I still think it would be better to use ForkingPickler in multiprocessing.connection, rather than modify global state (copyreg). The pickling support is multiprocessing-specific and wouldn't make sense for other pickles (e.g. stored to disk). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 15:01:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 13:01:46 +0000 Subject: [issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate In-Reply-To: <1327767887.13.0.0676848614688.issue13897@psf.upfronthosting.co.za> Message-ID: <1333976506.77.0.403708764367.issue13897@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This looks rather good on the principle. I think PyExcState needn't be public, it should be _PyExcState. I haven't checked the detailed mechanics of the patch, I hope someone else can. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 15:10:53 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 09 Apr 2012 13:10:53 +0000 Subject: [issue14534] Add method to mark unittest.TestCases as "do not run". Message-ID: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za> New submission from R. David Murray : A common pattern in testing is to have a base test class that implements test methods, and subclasses that provide various data that drives the tests to be run in different ways. It is convenient for the base class to inherit from TestCase, but this causes the normal test loader to load it as a test to be run, when most times it can't run by itself. My proposed solution is to make test case loading depend on an attribute of the class rather than the fact that it subclasses TestCase. TestCase would then have the attribute set to True by default. A decorator would be provided that sets the attribute to False, since that would make it visually obvious which TestCases are base classes and not to be loaded. (Note: once this is available the 'best practices' description of test file construction in the documentation for the stdlib 'test' module should be updated to use it.) ---------- assignee: michael.foord components: Library (Lib) keywords: easy messages: 157842 nosy: michael.foord, r.david.murray priority: normal severity: normal stage: needs patch status: open title: Add method to mark unittest.TestCases as "do not run". type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 15:13:13 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 09 Apr 2012 13:13:13 +0000 Subject: [issue14533] Modify regrtest to make test_main optional In-Reply-To: <1333927007.96.0.584520357529.issue14533@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset eff551437abd by R David Murray in branch 'default': #14533: if a test has no test_main, use loadTestsFromModule. http://hg.python.org/cpython/rev/eff551437abd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 15:14:12 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 09 Apr 2012 13:14:12 +0000 Subject: [issue14533] Modify regrtest to make test_main optional In-Reply-To: <1333927007.96.0.584520357529.issue14533@psf.upfronthosting.co.za> Message-ID: <1333977252.18.0.14442087423.issue14533@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 15:29:01 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 09 Apr 2012 13:29:01 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za> Message-ID: <1333978141.57.0.262436008387.issue8799@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Here is a new patch. 1) I?ve simplified and relaxed test_notify() for Condition objects. Condition variables don't guarantee that there won't be any spurious wakeups so the test must maintain internal bookkeeping so that it doesn't break with a different implementation of Condition. 2) The main thread now properly waits for the workers to "settle" in the test. 2) I've added two generic tests of Condition objects in their "natural environment" as building blocks for bigger things, a Queue and a Lock. ---------- versions: +Python 3.3 -Python 2.7, Python 3.2 Added file: http://bugs.python.org/file25161/lock_tests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 15:52:10 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 09 Apr 2012 13:52:10 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1333979530.05.0.496861087154.issue4892@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- nosy: +kristjan.jonsson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 16:27:45 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 09 Apr 2012 14:27:45 +0000 Subject: [issue14535] three code examples in docs are not syntax highlighted Message-ID: <1333981665.2.0.806826898617.issue14535@psf.upfronthosting.co.za> New submission from Ramchandra Apte : Three code examples in http://docs.python.org/py3k/library/multiprocessing.html#examples are not syntax highlighted. ---------- assignee: docs at python components: Documentation messages: 157845 nosy: docs at python, ramchandra.apte priority: normal severity: normal status: open title: three code examples in docs are not syntax highlighted versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 16:29:26 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Apr 2012 14:29:26 +0000 Subject: [issue13126] find() slower than rfind() In-Reply-To: <1318016796.03.0.16031959225.issue13126@psf.upfronthosting.co.za> Message-ID: <1333981766.12.0.0197488947018.issue13126@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I checked one example on a 32-bit system (you have a 64-bit?)), because I was afraid pessimization because of a lack of registers. str.find() is faster than str.rfind(), but the patch makes it even faster. But I would like to see the script and the results of benchmarking of the 1/2/3/20-character ascii/ucs1/ucs2/ucs4-substring in ascii/ucs1/ucs2/ucs4-string, in all possible combinations. May be, such benchmark scripts already exist? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 17:01:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 15:01:45 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za> Message-ID: <1333983705.62.0.724408536439.issue8799@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Condition variables don't guarantee that there won't be any spurious > wakeups What do you mean? The implementation doesn't seem prone to spurious wakeups, and the docs don't say so either. > I've added two generic tests of Condition objects in their "natural > environment" as building blocks for bigger things, a Queue and a Lock. Why would you build a Lock out of a Condition? ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 17:09:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 09 Apr 2012 15:09:48 +0000 Subject: [issue13165] Integrate stringbench in the Tools directory In-Reply-To: <1318520246.46.0.148882944484.issue13165@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 704630a9c5d5 by Antoine Pitrou in branch 'default': Issue #13165: stringbench is now available in the Tools/stringbench folder. http://hg.python.org/cpython/rev/704630a9c5d5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 17:12:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 15:12:46 +0000 Subject: [issue13165] Integrate stringbench in the Tools directory In-Reply-To: <1318520246.46.0.148882944484.issue13165@psf.upfronthosting.co.za> Message-ID: <1333984366.84.0.741198863802.issue13165@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 17:16:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 15:16:22 +0000 Subject: [issue13126] find() slower than rfind() In-Reply-To: <1318016796.03.0.16031959225.issue13126@psf.upfronthosting.co.za> Message-ID: <1333984582.55.0.38806917743.issue13126@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > But I would like to see the script and the results of benchmarking of > the 1/2/3/20-character ascii/ucs1/ucs2/ucs4-substring in ascii/ucs1 > /ucs2/ucs4-string, in all possible combinations. May be, such benchmark > scripts already exist? stringbench (the tool which produced those results) now exists in Tools/stringbench/stringbench.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 17:40:22 2012 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 09 Apr 2012 15:40:22 +0000 Subject: [issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate In-Reply-To: <1327767887.13.0.0676848614688.issue13897@psf.upfronthosting.co.za> Message-ID: <1333986022.47.0.851307719907.issue13897@psf.upfronthosting.co.za> Stefan Behnel added the comment: FWIW, Cython keeps the exception state in the generator struct and that works nicely. Note that Amaury is right in that extensions use tstate->exc_value and friends. Cython does so quite extensively, for example. I don't see any use in changing the plain fields into a struct, but it will definitely break code, and not just some. This is also unrelated to the topic of this issue, so it should be a separate issue in the first place, and that should then be rejected IMHO. Also note that there is a separate issue 14098 (with patch) on providing a public C-API for these three fields - as long as there is none but direct access to these public fields, a change that basically removes them should not even be seriously considered. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 17:40:53 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Apr 2012 15:40:53 +0000 Subject: [issue14536] Invalid links in svn.python.org Message-ID: <1333986053.37.0.658488076066.issue14536@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : Links "Subversion instructions" and "Developer FAQ" on http://svn.python.org/ are invalid. ---------- components: Devguide messages: 157851 nosy: ezio.melotti, storchaka priority: normal severity: normal status: open title: Invalid links in svn.python.org _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 17:44:11 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 09 Apr 2012 15:44:11 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1333986251.29.0.66456419252.issue4892@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: I just want to point out that each time socket.share() is called, the resulting data can only be used once by socket.fromshare(). I'm mentioning this because I know there is some caching mechanism in reduction.py and that this data is not cacheable/reuseable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 17:44:51 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Apr 2012 15:44:51 +0000 Subject: [issue13126] find() slower than rfind() In-Reply-To: <1333984582.55.0.38806917743.issue13126@psf.upfronthosting.co.za> Message-ID: <1333986425.24378.0.camel@raxxla> Serhiy Storchaka added the comment: > stringbench (the tool which produced those results) now exists in Tools/stringbench/stringbench.py. Thank you, yesterday they were not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 17:45:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 15:45:22 +0000 Subject: [issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate In-Reply-To: <1333986022.47.0.851307719907.issue13897@psf.upfronthosting.co.za> Message-ID: <1333985993.3379.8.camel@localhost.localdomain> Antoine Pitrou added the comment: > Note that Amaury is right in that extensions use tstate->exc_value and > friends. Cython does so quite extensively, for example. I understand for Cython, but why would pedestrian extension code look up tstate->exc_value? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 17:49:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 15:49:22 +0000 Subject: [issue14098] provide public C-API for reading/setting sys.exc_info() In-Reply-To: <1329983921.26.0.0291312337524.issue14098@psf.upfronthosting.co.za> Message-ID: <1333986562.43.0.414989376475.issue14098@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Stefan's latest patch looks fine to me. ---------- nosy: +pitrou stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 17:56:57 2012 From: report at bugs.python.org (Mark Shannon) Date: Mon, 09 Apr 2012 15:56:57 +0000 Subject: [issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate In-Reply-To: <1327767887.13.0.0676848614688.issue13897@psf.upfronthosting.co.za> Message-ID: <1333987017.14.0.700701013169.issue13897@psf.upfronthosting.co.za> Mark Shannon added the comment: 3rd party code should not be accessing fields in the threadstate object, but without the accessors proposed in issue 14098 there may be no alternative. Once the patch for issue 14098 has been applied it, would it then be acceptable to remove the surperfluous fields from the frameobject? The logic for accessing sys.exc_info can be moved to into the new accessor fucntions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 18:09:11 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 09 Apr 2012 16:09:11 +0000 Subject: [issue14520] Buggy Decimal.__sizeof__ In-Reply-To: <1333796139.51.0.465726080972.issue14520@psf.upfronthosting.co.za> Message-ID: <1333987751.8.0.350753579438.issue14520@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 18:14:27 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 09 Apr 2012 16:14:27 +0000 Subject: [issue14520] Buggy Decimal.__sizeof__ In-Reply-To: <1333796139.51.0.465726080972.issue14520@psf.upfronthosting.co.za> Message-ID: <1333988067.75.0.775317539337.issue14520@psf.upfronthosting.co.za> Mark Dickinson added the comment: In the C version of decimal, do distinct Decimal objects ever share coefficients? (This would be an obvious optimization for methods like Decimal.copy_negate; I don't know whether the C version applies such optimizations.) If there's potential for shared coefficients, that might make the "not count any memory twice" part tricky. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 18:24:39 2012 From: report at bugs.python.org (Rik Poggi) Date: Mon, 09 Apr 2012 16:24:39 +0000 Subject: [issue11060] distutils2 sdist does not complain about version that is not PEP 386 compliant In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za> Message-ID: <1333988679.05.0.195260603575.issue11060@psf.upfronthosting.co.za> Rik Poggi added the comment: Moving on, I've understood what the bug is about. I've made a couple of tests for this issue. I'm waiting for a review before adding others (if necessary). The fix is not going to be easy, because I'm not sure about the Metadata design. I think that what should be done is to make available the old version scheme check for metadata-version 1.0 and 1.1. ---------- Added file: http://bugs.python.org/file25162/issue_tests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 18:25:43 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 09 Apr 2012 16:25:43 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1333988743.28.0.187801712096.issue14521@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks for the updated patch! (BTW, you can attach patches as files to the issue rather than writing them inline.) Yes, this patch is more along the lines that I was thinking of. There are some issues, though: (1) we need to deal with endianness issues (including the ARM mixed-endian case). (2) It looks to me as though the (double *) cast violates strict aliasing rules; gcc's optimizations can do nasty things in this area. Rather than reinventing the wheel, we should use the same mechanisms as are already in Python's version of dtoa.c (e.g., see the use of the union to deal with aliasing issues); we may even be able to steal bits of David Gay's original code directly. I'll try to find time to look at this in the near future. I'm still not convinced that anything really needs to change here, though. I don't understand your comment about pickled objects; as far as I'm aware there aren't any issues with transferring pickled NaNs from one system to another. ---------- assignee: -> mark.dickinson nosy: +eric.smith priority: normal -> low stage: -> needs patch type: behavior -> enhancement versions: +Python 3.3 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 18:30:25 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 09 Apr 2012 16:30:25 +0000 Subject: [issue14520] Buggy Decimal.__sizeof__ In-Reply-To: <1333988067.75.0.775317539337.issue14520@psf.upfronthosting.co.za> Message-ID: <20120409183023.Horde.sab-ANjz9kRPgw6f8dfCS7A@webmail.df.eu> Martin v. L?wis added the comment: > In the C version of decimal, do distinct Decimal objects ever share > coefficients? (This would be an obvious optimization for methods > like Decimal.copy_negate; I don't know whether the C version > applies such optimizations.) If there's potential for shared > coefficients, that might make the "not count any memory twice" part > tricky. I know of three strategies to deal with such a case: a) expose the inner objects, preferably through tp_traverse, and don't account for them in the container, b) find a "canonical" owner of the contained objects, and only account for them along with the canonical container. c) compute the number N of shared owners, and divide the object size by N. Due to rounding, this may be somewhat incorrect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 18:54:38 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 09 Apr 2012 16:54:38 +0000 Subject: [issue14520] Buggy Decimal.__sizeof__ In-Reply-To: <1333988067.75.0.775317539337.issue14520@psf.upfronthosting.co.za> Message-ID: <20120409165437.GA11934@sleipnir.bytereef.org> Stefan Krah added the comment: Mark Dickinson wrote: > In the C version of decimal, do distinct Decimal objects ever share coefficients? The coefficients are members of the mpd_t struct (libmpdec data type), and they are not exposed as Python objects or shared. Cache locality is incredibly important: I have a patch that reserves a static coefficient of four words inside the PyDecObject. This patch speeds up _decimal by roughly another 30-40% for regularly sized decimals. If the decimal grows beyond that, libmpdec automatically switches to a dynamically allocated coefficient. I think sharing would probably slow things down a bit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 19:02:58 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 09 Apr 2012 17:02:58 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1333990978.74.0.454314062714.issue14521@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's an example based on the dtoa.c code. It only changes the return value of float('nan'), and doesn't affect any other existing uses of the Py_NAN macro. It needs tests. ---------- keywords: +patch Added file: http://bugs.python.org/file25163/issue14521.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 19:07:03 2012 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 09 Apr 2012 17:07:03 +0000 Subject: [issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate In-Reply-To: <1327767887.13.0.0676848614688.issue13897@psf.upfronthosting.co.za> Message-ID: <1333991223.04.0.413921862671.issue13897@psf.upfronthosting.co.za> Stefan Behnel added the comment: I can't speak for much outside of Cython, and Cython generated modules would best be regenerated with a newer Cython version anyway in order to work with Py3.3. I'm not sure that's currently required, though. As long as there is a way to access these fields directly from the struct (with the usual preprocessor conditional), I don't think Cython will actually start to use the PyErr_[GS]etExcInfo() functions in CPython - simply for performance reasons. Inlining the access is just way faster than calling into external functions, especially when that happens more than once. I'm still surprised about the general lack of resistence against incompatible changes to a public struct, though, especially when they come without an obvious gain. Is this really just for code beautification? I agree that this would be nice, but how can it be worth breaking code? I don't see any objection to the generator related changes in this patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 19:14:19 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 09 Apr 2012 17:14:19 +0000 Subject: [issue14520] Buggy Decimal.__sizeof__ In-Reply-To: <1333796139.51.0.465726080972.issue14520@psf.upfronthosting.co.za> Message-ID: <1333991659.42.0.160562864185.issue14520@psf.upfronthosting.co.za> Mark Dickinson added the comment: > and they are not exposed as Python objects or shared. Okay, thanks. Sounds like this isn't an issue at the moment then. +1 for having getsizeof report the total size used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 19:17:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 17:17:41 +0000 Subject: [issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate In-Reply-To: <1333991223.04.0.413921862671.issue13897@psf.upfronthosting.co.za> Message-ID: <1333991532.3379.23.camel@localhost.localdomain> Antoine Pitrou added the comment: > As long as there is a way to access these fields directly from the > struct (with the usual preprocessor conditional), I don't think Cython > will actually start to use the PyErr_[GS]etExcInfo() functions in > CPython - simply for performance reasons. Isn't this premature optimization? Do you have any workload where you measured a performance degradation? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 19:18:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 17:18:08 +0000 Subject: [issue14536] Invalid links in svn.python.org In-Reply-To: <1333986053.37.0.658488076066.issue14536@psf.upfronthosting.co.za> Message-ID: <1333991888.52.0.32213434198.issue14536@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for pointing it - I've fixed the "instructions". ---------- nosy: +pitrou resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 19:24:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 17:24:10 +0000 Subject: [issue14534] Add method to mark unittest.TestCases as "do not run". In-Reply-To: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za> Message-ID: <1333992250.24.0.972125881623.issue14534@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > A decorator would be provided that sets the attribute to False, since > that would make it visually obvious which TestCases are base classes > and not to be loaded. What's the point? Just derive from TestCase in the derived classes, not the base classes. -1 on useless complication. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 19:45:09 2012 From: report at bugs.python.org (Daniel Stutzbach) Date: Mon, 09 Apr 2012 17:45:09 +0000 Subject: [issue14534] Add method to mark unittest.TestCases as "do not run". In-Reply-To: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za> Message-ID: <1333993509.71.0.879699725785.issue14534@psf.upfronthosting.co.za> Daniel Stutzbach added the comment: Wouldn't the subclass inherit the False value? Then the user would need to remember to override the value again in the subclass, which is error prone. Antoine: I've used the pattern you describe on a couple of occasions, and it routinely confuses my code reviewers. ---------- nosy: +stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 19:50:38 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 09 Apr 2012 17:50:38 +0000 Subject: [issue14534] Add method to mark unittest.TestCases as "do not run". In-Reply-To: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za> Message-ID: <1333993838.71.0.189516591877.issue14534@psf.upfronthosting.co.za> R. David Murray added the comment: Antoine: I don't have any problem with that personally, but Michael did, and he's the maintainer :) But there is a small advantage: it means you don't have to keep repeating the 'unittest.TestCase' boilerplate in each subclass declaration, you only have to decorate the base class once. Daniel: Oops, you are right. Michael seemed to have some idea on how to implement the decorator. The class attribute was my contribution, and obviously that isn't going to work. I wanted something more transparent than a magic decorator, but it looks like magic will be required. Which, IMO, is a point in Antoine's favor. Let's see what Michael has to say. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 19:52:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 17:52:11 +0000 Subject: [issue14534] Add method to mark unittest.TestCases as "do not run". In-Reply-To: <1333993509.71.0.879699725785.issue14534@psf.upfronthosting.co.za> Message-ID: <1333993602.3379.28.camel@localhost.localdomain> Antoine Pitrou added the comment: > Antoine: I've used the pattern you describe on a couple of occasions, > and it routinely confuses my code reviewers. Really? What is confusing about it? Perhaps we should simply document it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 19:56:10 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Apr 2012 17:56:10 +0000 Subject: [issue13165] Integrate stringbench in the Tools directory In-Reply-To: <1318520246.46.0.148882944484.issue13165@psf.upfronthosting.co.za> Message-ID: <1333994170.77.0.823282377203.issue13165@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think that would be a useful tool for comparing two stringbench results. I propose an example of a script. Can use them separately or included in the stringbench.py, it's only an idea. ---------- nosy: +storchaka Added file: http://bugs.python.org/file25164/stringbench-diff.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 19:57:15 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Apr 2012 17:57:15 +0000 Subject: [issue13126] find() slower than rfind() In-Reply-To: <1318016796.03.0.16031959225.issue13126@psf.upfronthosting.co.za> Message-ID: <1333994235.61.0.378536048926.issue13126@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I used stringbench and self-writen script (see issue13165) for comparison and saw no convincing difference. The difference to str.find does not exceed accidental deviations for other functions which are not affected by the patch. Apparently, the accuracy of stringbench is not enough for a reliable measurement. ========== late match, 100 characters +8.6 +8.8 s="ABC"*33; ((s+"D")*500+s+"E").find(s+"E") (*100) +0.1 +0.2 s="ABC"*33; ((s+"D")*500+"E"+s).find("E"+s) (*100) +7.9 +7.4 s="ABC"*33; (s+"E") in ((s+"D")*300+s+"E") (*100) +7.2 +7.3 s="ABC"*33; ((s+"D")*500+s+"E").index(s+"E") (*100) +8.0 +7.9 s="ABC"*33; ((s+"D")*500+s+"E").partition(s+"E") (*100) -4.3 -4.3 s="ABC"*33; ("E"+s+("D"+s)*500).rfind("E"+s) (*100) -4.9 -6.9 s="ABC"*33; (s+"E"+("D"+s)*500).rfind(s+"E") (*100) -3.0 -3.0 s="ABC"*33; ("E"+s+("D"+s)*500).rindex("E"+s) (*100) -3.7 -4.2 s="ABC"*33; ("E"+s+("D"+s)*500).rpartition("E"+s) (*100) -4.0 -2.6 s="ABC"*33; ("E"+s+("D"+s)*500).rsplit("E"+s, 1) (*100) +28.0 +6.5 s="ABC"*33; ((s+"D")*500+s+"E").split(s+"E", 1) (*100) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 20:07:36 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 09 Apr 2012 18:07:36 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1333994856.62.0.300531805465.issue14521@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be it would be more reasonable if math.copysign(1., float('nan')) return a float('nan')? ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 20:13:01 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 09 Apr 2012 18:13:01 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1333995181.24.0.485983344122.issue14521@psf.upfronthosting.co.za> Mark Dickinson added the comment: > May be it would be more reasonable if math.copysign(1., float('nan')) > return a float('nan')? -1. That would go against all the existing standards. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 20:15:42 2012 From: report at bugs.python.org (mattip) Date: Mon, 09 Apr 2012 18:15:42 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1333995342.45.0.974412152862.issue14521@psf.upfronthosting.co.za> mattip added the comment: Your patch is much more reasonable than mine. Should I add a test that fails pre-patch and passes with the patch, or one that is skipped pre-patch and passes post-patch? I'm not sure what is accepted in the cpython development cycle ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 20:48:33 2012 From: report at bugs.python.org (Aaron Meurer) Date: Mon, 09 Apr 2012 18:48:33 +0000 Subject: [issue14537] "Fatal Python error: Cannot recover from stack overflow." with SymPy test suite Message-ID: <1333997313.25.0.0460793555995.issue14537@psf.upfronthosting.co.za> New submission from Aaron Meurer : Recently, after a small seemingly unrelated refactoring, the SymPy test suite in Python 3 started dying with "Fatal Python error: Cannot recover from stack overflow." Here's how to reproduce the error git clone git://github.com/sympy/sympy.git # Clone the development version of SymPy cd sympy git checkout 0856119bd7399a416c21e1692855a1077164f21c # This is the first commit to exhibit the problem. Do this in case we make an unrelated change that removes the problem. ./bin/use2to3 # Convert the codebase to Python 3 python3 py3k-sympy/setup.py test # Run the tests The issue is described in more detail at http://groups.google.com/group/sympy/browse_thread/thread/f664fe88e6b4f29d/3a44691c945695db#3a44691c945695db. Some key points: - The test that triggers the error is an XFAIL test (test that is expected to fail) that raises RuntimeError: maximum recursion depth exceeded. - The change that caused the error, 0856119bd7399a416c21e1692855a1077164f21c (see https://github.com/sympy/sympy/commit/0856119bd7399a416c21e1692855a1077164f21c), is seemingly unrelated. The only thing that I can think of is that it has added another call to the stack. - This kills Python with Abort Trap: 6 in Mac OS X, which generates a problem report to be sent to Apple. I have included a copy of it here: https://gist.github.com/2317869. - Others have reproduced this error as well, as can be seen by our test reporter tool. See the mailing list thread for more info. - I tested this in 3.2.3r2, and the error still occurred. I tried testing in the 3.3 alpha, but I could not get it to compile. ---------- messages: 157876 nosy: Aaron.Meurer priority: normal severity: normal status: open title: "Fatal Python error: Cannot recover from stack overflow." with SymPy test suite type: crash versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 20:57:48 2012 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 09 Apr 2012 18:57:48 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za> Message-ID: <1333997868.57.0.617708026995.issue14502@psf.upfronthosting.co.za> Vinay Sajip added the comment: Re. logging, logging._acquireLock and logging._releaseLock are not part of the public API and are undocumented at present. The case when _releaseLock does not raise an error is when threading couldn't be imported, so the _lock variable is None. I don't see the need for adding any documentation for this. Logging doesn't use dummy_thread: if threading isn't available, all lock acquisition and release operations become no-ops. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 21:02:21 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 19:02:21 +0000 Subject: [issue14537] "Fatal Python error: Cannot recover from stack overflow." with SymPy test suite In-Reply-To: <1333997313.25.0.0460793555995.issue14537@psf.upfronthosting.co.za> Message-ID: <1333998141.97.0.984319591345.issue14537@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 21:06:01 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 09 Apr 2012 19:06:01 +0000 Subject: [issue9691] sdist includes files that are not in MANIFEST.in In-Reply-To: <1282822249.86.0.974734126224.issue9691@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b5f0ce4ddf0c by ?ric Araujo in branch '2.7': Fix long-standing bugs with MANIFEST.in parsing on Windows (#6884). http://hg.python.org/cpython/rev/b5f0ce4ddf0c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 21:06:01 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 09 Apr 2012 19:06:01 +0000 Subject: [issue6884] Impossible to include file in sdist that starts with 'build' on Win32 In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b5f0ce4ddf0c by ?ric Araujo in branch '2.7': Fix long-standing bugs with MANIFEST.in parsing on Windows (#6884). http://hg.python.org/cpython/rev/b5f0ce4ddf0c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 21:06:03 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 09 Apr 2012 19:06:03 +0000 Subject: [issue14509] Build failures in non-pydebug builds without NDEBUG. In-Reply-To: <1333633371.25.0.0777678806587.issue14509@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset a11a2bbd8241 by Benjamin Peterson in branch '2.7': fix build without Py_DEBUG and DNDEBUG (closes #14509) http://hg.python.org/cpython/rev/a11a2bbd8241 New changeset 64bb1d258322 by Benjamin Peterson in branch '3.1': fix build without Py_DEBUG and DNDEBUG (closes #14509) http://hg.python.org/cpython/rev/64bb1d258322 New changeset 5168483316b5 by Benjamin Peterson in branch '3.2': merge 3.1 (#14509) http://hg.python.org/cpython/rev/5168483316b5 New changeset c20f604a2da6 by Benjamin Peterson in branch 'default': merge 3.2 (#14509) http://hg.python.org/cpython/rev/c20f604a2da6 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 21:26:27 2012 From: report at bugs.python.org (Jim Jewett) Date: Mon, 09 Apr 2012 19:26:27 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333997868.57.0.617708026995.issue14502@psf.upfronthosting.co.za> Message-ID: Jim Jewett added the comment: Vinay, The current question is what contract locks should follow, and whether all locks should follow it. Would it be acceptable for logging._releaseLock to raise a RuntimeError if the lock hadn't previously been acquired? In other words, would it be acceptable to replace the current None with a counter (and to note in comments that it should be safe from race conditions because it is only used when threading isn't available). -jJ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 21:31:04 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 19:31:04 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: Message-ID: <1333999534.3379.31.camel@localhost.localdomain> Antoine Pitrou added the comment: > The current question is what contract locks should follow, and whether > all locks should follow it. Would it be acceptable for > logging._releaseLock to raise a RuntimeError if the lock hadn't > previously been acquired? I don't see the point of this discussion. We are talking about threading.Lock (and, possibly, multiprocessing.Lock), not every lock API under the sun. Especially when it's a private API... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 21:32:24 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 09 Apr 2012 19:32:24 +0000 Subject: [issue14098] provide public C-API for reading/setting sys.exc_info() In-Reply-To: <1329983921.26.0.0291312337524.issue14098@psf.upfronthosting.co.za> Message-ID: <1333999944.27.0.96366995223.issue14098@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Fine with me as well. Stefan, please submit a contributor form. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 21:33:36 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 09 Apr 2012 19:33:36 +0000 Subject: [issue14520] Buggy Decimal.__sizeof__ In-Reply-To: <1333796139.51.0.465726080972.issue14520@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 010aa5d955ac by Stefan Krah in branch 'default': Issue #14520: Add __sizeof__() method to the Decimal object. http://hg.python.org/cpython/rev/010aa5d955ac ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 21:42:39 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 09 Apr 2012 19:42:39 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1334000559.8.0.035241554563.issue14521@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The test should fail pre-patch and pass post-patch. There will be no state in the repository where the patch is present and fails, since it will be committed along with the patch. Skipping tests is only ok for tests that lack prerequisites on some systems, and (exceptionally) for tests that document known bugs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 21:43:27 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 09 Apr 2012 19:43:27 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1334000607.39.0.413522467007.issue14521@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Also, mattip: if you want to contribute some chunk of code (such as the test), please submit a contributor form. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 21:51:51 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 09 Apr 2012 19:51:51 +0000 Subject: [issue14520] Buggy Decimal.__sizeof__ In-Reply-To: <1333796139.51.0.465726080972.issue14520@psf.upfronthosting.co.za> Message-ID: <1334001111.73.0.30563045524.issue14520@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks for the explanations. The new __sizeof__() method should now report the exact memory usage. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 22:01:56 2012 From: report at bugs.python.org (Michel Leunen) Date: Mon, 09 Apr 2012 20:01:56 +0000 Subject: [issue14538] HTMLParser Message-ID: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> New submission from Michel Leunen : HTMLParser fails to parse this structure of tags: '' Parsing stops after the first meta tag ignoring the remainers from HTMLParser import HTMLParser parser = process_html() parser.feed('') Python 2.7.2+ Ubuntu 11.10 ---------- components: Library (Lib) messages: 157890 nosy: Michel.Leunen priority: normal severity: normal status: open title: HTMLParser type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 22:04:38 2012 From: report at bugs.python.org (Michel Leunen) Date: Mon, 09 Apr 2012 20:04:38 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334001878.23.0.201609045104.issue14538@psf.upfronthosting.co.za> Changes by Michel Leunen : ---------- title: HTMLParser -> HTMLParser: parsing error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 22:17:05 2012 From: report at bugs.python.org (Rik Poggi) Date: Mon, 09 Apr 2012 20:17:05 +0000 Subject: [issue11218] pattern=None when following documentation for load_tests and unittest.main() In-Reply-To: <1297758807.39.0.713611114484.issue11218@psf.upfronthosting.co.za> Message-ID: <1334002625.49.0.0101642909705.issue11218@psf.upfronthosting.co.za> Rik Poggi added the comment: I think the doc should be improved (http://docs.python.org/library/unittest.html#load-tests-protocol), it's not clear how pattern in the example (last one) could not be None. Changing the discover signature doesn't seem to be an option since the TestLoader.discover doc http://docs.python.org/library/unittest.html#unittest.TestLoader.discover says: The pattern is deliberately not stored as a loader attribute so that packages can continue discovery themselves. ---------- nosy: +rik.poggi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 22:26:57 2012 From: report at bugs.python.org (Jim Jewett) Date: Mon, 09 Apr 2012 20:26:57 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1334003217.79.0.307875672037.issue3561@psf.upfronthosting.co.za> Jim Jewett added the comment: @Brian -- to clarify, (1) Does issue3561.diff completely supersede prependpath_in-progress.diff? (And should that be the one currently subject to review?) (2) What happens with multiple installations? Do users have to manually unset the path to avoid surprises? Does this become obsolete if the py.exe shim delegating to the appropriate py* is included with 3.3? Does installing 3.3.2 in over top of 3.3.1 add the directory to the path twice? ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 22:31:26 2012 From: report at bugs.python.org (Brian Curtin) Date: Mon, 09 Apr 2012 20:31:26 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1334003486.41.0.0489975896232.issue3561@psf.upfronthosting.co.za> Changes by Brian Curtin : Removed file: http://bugs.python.org/file24574/prependpath_in-progress.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 22:36:38 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 20:36:38 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1334003798.55.0.687372814399.issue3561@psf.upfronthosting.co.za> Antoine Pitrou added the comment: UI-wise, I'm not sure why it looks like an installable component rather than a separate checkbox. Is it a limitation of the installation software? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 22:42:09 2012 From: report at bugs.python.org (Michael Foord) Date: Mon, 09 Apr 2012 20:42:09 +0000 Subject: [issue14534] Add method to mark unittest.TestCases as "do not run". In-Reply-To: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za> Message-ID: <1334004129.69.0.0315079342513.issue14534@psf.upfronthosting.co.za> Michael Foord added the comment: So the technique I suggested is that the TestLoader checks classes for the "testbase" (or whatever we call it) *in the class dict*. So inheritance doesn't matter - a class is only excluded from test loading if it has the attribute directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 22:45:07 2012 From: report at bugs.python.org (Brian Curtin) Date: Mon, 09 Apr 2012 20:45:07 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1334004307.24.0.0299862479297.issue3561@psf.upfronthosting.co.za> Brian Curtin added the comment: I unlinked the old diff. issue3561.diff is the one that matters. As for what happens with multiple installations, it's no different than how you'd already be managing it or anything else like it. If you install 2.7 with the path option enabled and then you install 3.2 with the path option enabled, 3.2 goes in front of 2.7. The installations don't touch each other. If we want to get smart and detect other installations on the Path, I believe this gets a lot more complicated. It does not become obsolete with the launcher. The launcher solves a wider problem in a different way. You could just switch to the launcher if you wanted to, but because we (probably will) have that feature doesn't mean the bare python.exe can't grow this functionality. People have been asking for it for years. It's the first step of every tutorial on the internet. It takes up a special page on the information for a sprint I just saw. As for the question of 3.3.2 over 3.3.1: I'm not sure yet. I'll build a few installers with different versions and run some upgrades to see what happens. We're using MSI's builtin ability to manage everything here, so I would imagine it knows what to do, but I'll confirm. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 22:45:55 2012 From: report at bugs.python.org (Michael Foord) Date: Mon, 09 Apr 2012 20:45:55 +0000 Subject: [issue14534] Add method to mark unittest.TestCases as "do not run". In-Reply-To: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za> Message-ID: <1334004355.22.0.546407334705.issue14534@psf.upfronthosting.co.za> Michael Foord added the comment: Here are my objections to the standard (but not widely used outside our own tests) mixin pattern for base testcases (copied and pasted from issue 14408): Because you then have classes that inherit from object calling methods that clearly don't exist (until you subclass them *and* TestCase). It looks weird and also means the classes can't be tested in isolation. With a class decorator the code would *look* straightforward, and the hidden attribute is just an implementation detail. It still looks weird to see code calling methods that obviously don't exist, and with no indication *at the call site* where they come from. Making it clearer with naming would help: "TestThingMixin" or similar. There are classes like this in the unittest test suite, and I was very confused by them initially until I found where and how they were used. It is obviously *not* a pattern that is widely known for test base classes, as we have this problem of it not being done even in the standard library tests. In contrast I think code similar to the following would be clear and readable without knowing about multiple inheritance and the mixin trick: @test_base_class class SomeTestBase(TestCase): ... Besides which, the mixin pattern won't *stop* working if we provide this extra functionality - it would just be an alternative for those (like myself) who think it impedes code readability. :-) At this point we're off topic for the *specific issue*, and I'm fine with our own standard library tests moving to use mixins to support standard unittest invocation. I would suggest the base test cases include Mixin in their name to make it clear how they should be used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 22:47:49 2012 From: report at bugs.python.org (Brian Curtin) Date: Mon, 09 Apr 2012 20:47:49 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1334004469.24.0.0649111051537.issue3561@psf.upfronthosting.co.za> Brian Curtin added the comment: > UI-wise, I'm not sure why it looks like an installable component rather than a separate checkbox. Is it a limitation of the installation software? I originally did it as a separate check box UI-wise but couldn't hook that into be an actual "Feature" in MSI terms. The way it's currently done allows it to be added to certain tables, allowing us to conditionally modify the "Environment" table which contains the optional path addition. I am by no means an MSI expert. This is just the way Martin and I talked about it at PyCon and the way I've seen it done around the web. If there's a way to tie a checkbox to the Feature table, I would like that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 22:47:56 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 20:47:56 +0000 Subject: [issue14534] Add method to mark unittest.TestCases as "do not run". In-Reply-To: <1334004129.69.0.0315079342513.issue14534@psf.upfronthosting.co.za> Message-ID: <1334004146.3379.43.camel@localhost.localdomain> Antoine Pitrou added the comment: > So the technique I suggested is that the TestLoader checks classes for > the "testbase" (or whatever we call it) *in the class dict*. So > inheritance doesn't matter - a class is only excluded from test > loading if it has the attribute directly. Why not document the official recommendation in the docs? Adding another gimmick isn't very useful. It doesn't add a functionality. It doesn't even make it significantly easier to write tests (unless you have more test classes than test methods). And it means that people have to remember two idioms instead of one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 22:50:56 2012 From: report at bugs.python.org (Jim Jewett) Date: Mon, 09 Apr 2012 20:50:56 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334004656.38.0.968062979535.issue14538@psf.upfronthosting.co.za> Jim Jewett added the comment: What do you think it should do? My thought is that meta tags may or may not be void, but certainly should not be nested. As XML, I would parse that as *missing closing tag But for html, there is more cleanup. The catch is that this module probably can't keep up with BeautifulSoup or HTML5lib ... is this particular tag situation common enough to be even have a defined handling, let alone one that is worth adding to a "simple" module? ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 22:57:57 2012 From: report at bugs.python.org (mattip) Date: Mon, 09 Apr 2012 20:57:57 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1334005077.94.0.941848089062.issue14521@psf.upfronthosting.co.za> mattip added the comment: I added tests to the mark.dickinson patch, test.test_math passes. ---------- Added file: http://bugs.python.org/file25165/math_patch2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 22:58:18 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 09 Apr 2012 20:58:18 +0000 Subject: [issue14502] Document better what happens on releasing an unacquired lock In-Reply-To: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za> Message-ID: <1334005098.99.0.521723231025.issue14502@psf.upfronthosting.co.za> Georg Brandl added the comment: Agreed. Jim, I think you're trying to get consistency where none is required. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 22:59:09 2012 From: report at bugs.python.org (mattip) Date: Mon, 09 Apr 2012 20:59:09 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1334005149.39.0.457120319155.issue14521@psf.upfronthosting.co.za> mattip added the comment: I also submitted a form. Sorry about the patch name, still learning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 23:10:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 21:10:22 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1333705938.64.0.743606507616.issue14082@psf.upfronthosting.co.za> Message-ID: <1334005492.3379.50.camel@localhost.localdomain> Antoine Pitrou added the comment: > I?m writing a shutil.copyxattr() first which could simple get another > argument for the namespaces that should be copied. Sounds good to me :-) > However what to do inside copy2()? > > I?m tending to either: > > 1. copy only user.* > 2. ignore errors in any namespace != user > > Personally, I find the second approach rather non-deterministic. But it's also more practical, e.g. when running as root you would probably be surprised if only a subset of xattrs get copied, wouldn't you? ?Practicality beats purity.? For reference, here is part of the documentation for GNU cp's "-a" option: `-a' `--archive' Preserve as much as possible of the structure and attributes of the original files in the copy (but do not attempt to preserve internal directory structure; i.e., `ls -U' may list the entries in a copied directory in a different order). Try to preserve SELinux security context and extended attributes (xattr), but ignore any failure to do that and print no corresponding diagnostic. Equivalent to `-dR --preserve=all' with the reduced diagnostics. Meaning that "cp -a" tries to copy all xattrs and silences errors when it's not possible to do so. "cp --preserve=all" seems to have a similar error-silencing behaviour: `all' Preserve all file attributes. Equivalent to specifying all of the above, but with the difference that failure to preserve SELinux security context or extended attributes does not change `cp''s exit status. In contrast to `-a', all but `Operation not supported' warnings are output. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 23:19:23 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 21:19:23 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334006363.78.0.269464944382.issue14538@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 23:20:19 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 09 Apr 2012 21:20:19 +0000 Subject: [issue14412] Sqlite Integer Fields In-Reply-To: <1332759601.85.0.320524122366.issue14412@psf.upfronthosting.co.za> Message-ID: <1334006419.47.0.752615927745.issue14412@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Given the lack of progress here, I will be releasing 2.7.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 23:29:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 21:29:08 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: <1332849673.66.0.0828799259938.issue14423@psf.upfronthosting.co.za> Message-ID: <1334006948.0.0.568650832597.issue14423@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Some comments: - you also need to modify the C version in Modules/_datetimemodule.c (make sure the tests exercise both versions!) - the doc needs a "versionadded" tag - I don't understand this: + if self.isocalendar()[1] != 1: + if self.weekday() > 3: # Jan 1 is not in week one + self += timedelta(7 - self.weekday()) What if self.weekday() <= 3 ? Surely some adjustment is needed as well? (you should probably add more tests to cover the various cases) - this comment: + # Test that we get the OverflowError when the year has 52 weeks seems wrong since ValueError is raised ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 23:39:39 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 09 Apr 2012 21:39:39 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334007579.08.0.742479039994.issue14538@psf.upfronthosting.co.za> Ezio Melotti added the comment: With Python 2.7.3rc2 and 3.3.0a0 (strict=False) I get: Start tag: a End tag : a Start tag: script End tag : script Start tag: meta Data : Start tag: body End tag : body This is better, but still not 100% correct, the "" shouldn't be seen as data. ---------- assignee: -> ezio.melotti stage: -> test needed versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 23:50:13 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 09 Apr 2012 21:50:13 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: <1332849673.66.0.0828799259938.issue14423@psf.upfronthosting.co.za> Message-ID: <1334008213.67.0.732587422156.issue14423@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Before you invest in a C version, let's discuss whether this feature is desirable. The proposed function implements a very simple and not very common calculation. Note that even dateutil does not provide direct support for this: you are instructed to use relativedelta to add weeks to January 1st of the given year. If we are going to add yet another way to construct dates, I would like to consider some universal solution. For example, a "make_date" function that would behave similar to the timedelta constructor: take a large number of keyword arguments and return a date. For example, make_date(year=2000, isoweek=5, weekday=3) make_date(year=2000, isoday=63) etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 23:51:15 2012 From: report at bugs.python.org (zodalahtathi) Date: Mon, 09 Apr 2012 21:51:15 +0000 Subject: [issue14539] logging module: logger does not print log message with logging.INFO level Message-ID: <1334008275.31.0.522161663981.issue14539@psf.upfronthosting.co.za> New submission from zodalahtathi : The logging module does not print logging message when the logging level is set to a level inferior to the default level. I can reproduce it using the Python3 (3.2.2) package from Ubuntu 12.04 beta2, or using a hand compiled Python 3.2.2. The bug is NOT present in Python 3.2.1. ~ $ python3 Python 3.2.3rc2 (default, Mar 21 2012, 16:59:51) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import logging >>> logger = logging.getLogger() >>> logger.getEffectiveLevel() <= logging.WARN True >>> logger.warn("warning message") warning message >>> logger.setLevel(logging.INFO) >>> logger.getEffectiveLevel() <= logging.INFO True >>> logger.info("info message") >>> ---------- messages: 157908 nosy: zodalahtathi priority: normal severity: normal status: open title: logging module: logger does not print log message with logging.INFO level type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 23:52:13 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 09 Apr 2012 21:52:13 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1334003798.55.0.687372814399.issue3561@psf.upfronthosting.co.za> Message-ID: <20120409235212.Horde.EKF0Idjz9kRPg1oMO8FEzZA@webmail.df.eu> Martin v. L?wis added the comment: > UI-wise, I'm not sure why it looks like an installable component > rather than a separate checkbox. Is it a limitation of the > installation software? You are misinterpreting the UI. The list is not of "installable components", but of "features". Adjusting the path is a feature just as registering the .py extension. That feature can be installed and uninstalled. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 23:53:48 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 09 Apr 2012 21:53:48 +0000 Subject: [issue14539] logging module: logger does not print log message with logging.INFO level In-Reply-To: <1334008275.31.0.522161663981.issue14539@psf.upfronthosting.co.za> Message-ID: <1334008429.0.0.226409495221.issue14539@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 9 23:57:55 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 09 Apr 2012 21:57:55 +0000 Subject: [issue14534] Add method to mark unittest.TestCases as "do not run". In-Reply-To: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za> Message-ID: <1334008675.77.0.0932078134293.issue14534@psf.upfronthosting.co.za> R. David Murray added the comment: Note that I did just document the mixin idiom in the Lib/test docs. Which core developers probably don't read :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 00:05:47 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 09 Apr 2012 22:05:47 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1334009147.85.0.0939094269827.issue3561@psf.upfronthosting.co.za> Martin v. L?wis added the comment: IANANSOE (I am not a native speaker of English), but it seems to me that "Prepend path" is a bit terse, in particular since "Path" is being prepended *to*. How about "Add python.exe to the search path"? That it is added to the beginning could be elaborated (i.e. prepended) in the feature description. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 00:20:25 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 09 Apr 2012 22:20:25 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: <1334008213.67.0.732587422156.issue14423@psf.upfronthosting.co.za> Message-ID: <4F8360A5.7090106@egenix.com> Marc-Andre Lemburg added the comment: Alexander Belopolsky wrote: > > Alexander Belopolsky added the comment: > > Before you invest in a C version, let's discuss whether this feature is desirable. The proposed function implements a very simple and not very common calculation. Note that even dateutil does not provide direct support for this: you are instructed to use relativedelta to add weeks to January 1st of the given year. Which is wrong, since the start of the first ISO week of a year can in fact start in the preceeding year... http://en.wikipedia.org/wiki/ISO_week_date and it's not a simple calculation. ISO weeks are in common use throughout Europe, it's part of the ISO 8601 standard. mxDateTime has had such constructors for ages: http://www.egenix.com/products/python/mxBase/mxDateTime/doc/#_Toc293683820 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 00:30:02 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Apr 2012 22:30:02 +0000 Subject: [issue13165] Integrate stringbench in the Tools directory In-Reply-To: <1333994170.77.0.823282377203.issue13165@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > I think that would be a useful tool for comparing two stringbench results. Please open a new issue for such improvement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 00:34:03 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 09 Apr 2012 22:34:03 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: <4F8360A5.7090106@egenix.com> Message-ID: Alexander Belopolsky added the comment: On Mon, Apr 9, 2012 at 6:20 PM, Marc-Andre Lemburg wrote: > Which is wrong, since the start of the first ISO week of a year > can in fact start in the preceeding year... Hmm, the dateutil documentation seems to imply that relativedelta takes care of this: http://labix.org/python-dateutil#head-72c4689ec5608067d118b9143cef6bdffb6dad4e (Search the page for "ISO") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 00:36:07 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Apr 2012 22:36:07 +0000 Subject: [issue14537] "Fatal Python error: Cannot recover from stack overflow." with SymPy test suite In-Reply-To: <1333997313.25.0.0460793555995.issue14537@psf.upfronthosting.co.za> Message-ID: <1334010967.0.0.902402236859.issue14537@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like an issue in SymPy, a stack overflow. Why did you report this issue on CPython bug tracker? Is there an infinite loop in a recursive function call? Can you try to get the full Python traceback using faulthandler? Use "-X faulthandler" command line option, or use "import faulthandler; faulthandler.enable()" at the beginning of your program. You have to install it manually for Python < 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 00:38:10 2012 From: report at bugs.python.org (Jim Jewett) Date: Mon, 09 Apr 2012 22:38:10 +0000 Subject: [issue10408] Denser dicts and linear probing In-Reply-To: <1289659692.61.0.467153013048.issue10408@psf.upfronthosting.co.za> Message-ID: <1334011090.29.0.185496220618.issue10408@psf.upfronthosting.co.za> Jim Jewett added the comment: FWIW, doing a linear probe only within a cache line (changing the 1's bit) before applying perturb might also be useful -- and the results may change if the size of a dictentry were reduced. (Mark Shannon's now-integrated patch doesn't actually do that for the keys, but it would be doable.) ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 00:43:27 2012 From: report at bugs.python.org (Aaron Meurer) Date: Mon, 09 Apr 2012 22:43:27 +0000 Subject: [issue14537] "Fatal Python error: Cannot recover from stack overflow." with SymPy test suite In-Reply-To: <1333997313.25.0.0460793555995.issue14537@psf.upfronthosting.co.za> Message-ID: <1334011407.53.0.22912832035.issue14537@psf.upfronthosting.co.za> Aaron Meurer added the comment: We do have a stack overflow, but this should be raising a RuntimeError, not killing Python. The way it is now, Python dies completely with abort trap 6 (hence the Mac OS X problem report). Sorry if I didn't make this clear in the OP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 00:48:52 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Apr 2012 22:48:52 +0000 Subject: [issue14537] "Fatal Python error: Cannot recover from stack overflow." with SymPy test suite In-Reply-To: <1333997313.25.0.0460793555995.issue14537@psf.upfronthosting.co.za> Message-ID: <1334011732.69.0.58167632858.issue14537@psf.upfronthosting.co.za> STINNER Victor added the comment: SymPy uses a C extension, numpy. The problem may be related to numpy. CPython tries to catch segmentation fault, but when a C extension is used, CPython may fail to protect your program against stack overflow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 00:50:38 2012 From: report at bugs.python.org (Aaron Meurer) Date: Mon, 09 Apr 2012 22:50:38 +0000 Subject: [issue14537] "Fatal Python error: Cannot recover from stack overflow." with SymPy test suite In-Reply-To: <1333997313.25.0.0460793555995.issue14537@psf.upfronthosting.co.za> Message-ID: <1334011838.33.0.885710023753.issue14537@psf.upfronthosting.co.za> Aaron Meurer added the comment: No it does not. SymPy is a pure Python library. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 00:56:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Apr 2012 22:56:25 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: Message-ID: <1334011854.3379.53.camel@localhost.localdomain> Antoine Pitrou added the comment: > Hmm, the dateutil documentation seems to imply that relativedelta > takes care of this: This is all a bit moot since we don't have a "relativedelta" in the stdlib. I think the two questions here are: - is this feature desirable? I think the answer is "yes" - is the implementation correct? I don't know :-) Talk of a magical generic constructor sounds a bit futile to me, especially if the constructor's behaviour becomes so complicated that it's difficult to understand for users... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 00:59:26 2012 From: report at bugs.python.org (Brian Curtin) Date: Mon, 09 Apr 2012 22:59:26 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1334012366.31.0.918680484434.issue3561@psf.upfronthosting.co.za> Brian Curtin added the comment: Agreed. I will work up a more friendly text to go along with the feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 01:01:46 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 09 Apr 2012 23:01:46 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: <1334011854.3379.53.camel@localhost.localdomain> Message-ID: Alexander Belopolsky added the comment: On Mon, Apr 9, 2012 at 6:56 PM, Antoine Pitrou wrote: > This is all a bit moot since we don't have a "relativedelta" in the > stdlib. It is still worthwhile to see how it is done elsewhere. So far, we have dateutil that does not have this function and mxDateTime that keeps this and other ISO related functions in a submodule. Does anyone know how this is done in other languages? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 01:27:48 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 09 Apr 2012 23:27:48 +0000 Subject: [issue14537] "Fatal Python error: Cannot recover from stack overflow." with SymPy test suite In-Reply-To: <1333997313.25.0.0460793555995.issue14537@psf.upfronthosting.co.za> Message-ID: <1334014068.39.0.286684531959.issue14537@psf.upfronthosting.co.za> STINNER Victor added the comment: The (first) Python stack overflow occurs at: ----------- (gdb) py-bt Traceback (most recent call first): File "/home/haypo/issue14537/sympy/py3k-sympy/sympy/core/expr.py", line 2531, in expand from sympy.simplify.simplify import fraction File "/home/haypo/issue14537/sympy/py3k-sympy/sympy/core/cache.py", line 91, in wrapper func_cache_it_cache[k] = r = func(*args, **kw_args) File "/home/haypo/issue14537/sympy/py3k-sympy/sympy/functions/elementary/hyperbolic.py", line 514, in as_real_imag return (self.expand(deep, **hints), S.Zero) File "/home/haypo/issue14537/sympy/py3k-sympy/sympy/functions/elementary/hyperbolic.py", line 525, in _eval_expand_complex re_part, im_part = self.as_real_imag(deep=deep, **hints) File "/home/haypo/issue14537/sympy/py3k-sympy/sympy/core/expr.py", line 2551, in expand expr = func(deep=deep, **hints) File "/home/haypo/issue14537/sympy/py3k-sympy/sympy/core/cache.py", line 91, in wrapper func_cache_it_cache[k] = r = func(*args, **kw_args) File "/home/haypo/issue14537/sympy/py3k-sympy/sympy/functions/elementary/hyperbolic.py", line 514, in as_real_imag return (self.expand(deep, **hints), S.Zero) File "/home/haypo/issue14537/sympy/py3k-sympy/sympy/functions/elementary/hyperbolic.py", line 525, in _eval_expand_complex (gdb) where #0 _Py_CheckRecursiveCall (where=0x624f4b " in comparison") at Python/ceval.c:736 #1 0x0000000000419e6a in PyObject_RichCompare (v='sympy', w='sympy', op=2) at Objects/object.c:604 #2 0x0000000000419f2d in PyObject_RichCompareBool (v='sympy', w='sympy', op=2) at Objects/object.c:628 #3 0x00000000005e854e in lookdict (mp=0x7ffff1b3b1a8, key='sympy', hash=-191038920480525830) at Objects/dictobject.c:341 #4 0x00000000005e99ca in PyDict_GetItem (op= {'sympy.logic.inference': , ..., key='sympy') at Objects/dictobject.c:752 #5 0x00000000004f1510 in import_submodule (mod=None, subname='sympy', fullname='sympy') at Python/import.c:3313 #6 0x00000000004f064b in load_next (mod=None, altmod=None, inputname='sympy.simplify.simplify', p_outputname=0x7fffffe67e28, p_prefix=0x7fffffe67e20) at Python/import.c:3150 #7 0x00000000004ef610 in import_module_level (name='sympy.simplify.simplify', globals= {...}, locals=None, fromlist=('fraction',), level=0) at Python/import.c:2843 ----------- Ok, now I see the problem: import_submodule() uses PyDict_GetItem() whereas PyDict_GetItem() *clears* the exception (!). It should use PyDict_GetItemWithError() instead. Try attached patch. The problem is a generic problem: PyDict_GetItem() should be replaced by PyDict_GetItemWithError() everywhere... But it would be nice to start with import.c :-) ---------- keywords: +patch Added file: http://bugs.python.org/file25166/import_pydict_getitem.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 01:28:42 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 09 Apr 2012 23:28:42 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: Message-ID: <4F8370A6.9010405@egenix.com> Marc-Andre Lemburg added the comment: Alexander Belopolsky wrote: > > Alexander Belopolsky added the comment: > > On Mon, Apr 9, 2012 at 6:20 PM, Marc-Andre Lemburg > wrote: >> Which is wrong, since the start of the first ISO week of a year >> can in fact start in the preceeding year... > > Hmm, the dateutil documentation seems to imply that relativedelta > takes care of this: > > http://labix.org/python-dateutil#head-72c4689ec5608067d118b9143cef6bdffb6dad4e > > (Search the page for "ISO") That's not realtivedelta taking care of it, it's the way it is used: the week with 4.1. in it is the first ISO week of a year; it then goes back to the previous Monday and adds 14 weeks from there to go to the Monday of the 15th week. This works fine as long as 4.1. doesn't fall on a Monday... You don't really expect anyone to remember such rules, do you ? :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 03:29:29 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 10 Apr 2012 01:29:29 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1334021369.06.0.0708332253761.issue14243@psf.upfronthosting.co.za> Nick Coghlan added the comment: I agree we need to add something here to better support the idiom where the "close" and "delete" operations on a NamedTemporaryFile are decoupled without the delete becoming a completely independent call to os.unlink(). I agree with RDM's proposal in issue 14514 that the replacement should be "delete on __exit__ but not on close". As with generator context managers, I'd also add in the "last ditch" cleanup behaviour in __del__. Converting the issue to a feature request for 3.3 - there's no bug here, just an interaction with Windows that makes the existing behavioural options inconvenient. After all, you can currently get deterministic cleanup (with a __del__ fallback) via: @contextmanager def named_temp(name): f = NamedTemporaryFile(name, delete=False) try: yield f finally: try: os.unlink(name) except OSError: pass You need to be careful to make sure you keep the CM alive (or it will delete the file behind your back), but the idiom RDM described in the other issues handles that for you: with named_temp(fname) as f: data = "Data\n" f.write(data) f.close() # Windows compatibility with open(fname) as f: self.assertEqual(f.read(), data) As far as the API goes, I'm inclined to make a CM with the above behavour available as a new class method on NamedTemporaryFile: with NamedTemporaryFile.delete_after(fname) as f: # As per the workaround ---------- title: NamedTemporaryFile unusable under Windows -> tempfile.NamedTemporaryFile not particularly useful on Windows type: behavior -> enhancement versions: -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 03:31:35 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 10 Apr 2012 01:31:35 +0000 Subject: [issue14514] Equivalent to tempfile.NamedTemporaryFile that deletes file at context exit In-Reply-To: <1333677629.14.0.589008132421.issue14514@psf.upfronthosting.co.za> Message-ID: <1334021495.96.0.788509351417.issue14514@psf.upfronthosting.co.za> Nick Coghlan added the comment: I converted issue #14243 to a feature request, so this is now a duplicate. ---------- nosy: +ncoghlan resolution: -> duplicate status: open -> closed superseder: -> tempfile.NamedTemporaryFile not particularly useful on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 03:33:24 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 10 Apr 2012 01:33:24 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1334021604.51.0.839775763734.issue14243@psf.upfronthosting.co.za> Nick Coghlan added the comment: Although, for the stdlib version, I wouldn't suppress the OS Error (I'd follow what we currently do for TemporaryDirectory) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 04:11:16 2012 From: report at bugs.python.org (Paul A.) Date: Tue, 10 Apr 2012 02:11:16 +0000 Subject: [issue14540] Crash in Modules/_ctypes/libffi/src/dlmalloc.c on ia64-hp-hpux11.31 Message-ID: <1334023876.29.0.692126392594.issue14540@psf.upfronthosting.co.za> New submission from Paul A. : The following stack trace happened towards the end of a Python-2.7.3rc2 build, but I also get much the same results with 2.7.2; one difference I noticed was I didn't think I needed to add -DHAVE_USR_INCLUDE_MALLOC_H there. running build_scripts creating build/scripts-2.7 copying and adjusting /usr/local/src/Python-2.7.3rc2/Tools/scripts/pydoc -> build/scripts-2.7 copying and adjusting /usr/local/src/Python-2.7.3rc2/Tools/scripts/idle -> build/scripts-2.7 copying and adjusting /usr/local/src/Python-2.7.3rc2/Tools/scripts/2to3 -> build/scripts-2.7 copying and adjusting /usr/local/src/Python-2.7.3rc2/Lib/smtpd.py -> build/scripts-2.7 changing mode of build/scripts-2.7/pydoc from 644 to 755 changing mode of build/scripts-2.7/idle from 644 to 755 changing mode of build/scripts-2.7/2to3 from 644 to 755 changing mode of build/scripts-2.7/smtpd.py from 644 to 755 sh[3]: 1340 Abort(coredump) (gdb) bt #0 0xc0000000004395d0:0 in kill+0x30 () from /usr/lib/hpux64/libc.so.1 #1 0xc0000000002e8180:0 in raise+0x120 () from /usr/lib/hpux64/libc.so.1 #2 0xc0000000003f8c50:0 in abort+0x170 () from /usr/lib/hpux64/libc.so.1 #3 0xc000000010f0c7f0:0 in free (mem=0x60000000000053d0) at /usr/local/src/Python-2.7.3rc2/Modules/_ctypes/libffi/src/dlmalloc.c:4288 #4 0xc000000000bfcde0:0 in _UNW_free_mpool()+0xc0 () from /usr/lib/hpux64/libunwind.so.1 #5 0xc00000000004cb50:0 in EM_mark_BOS+0x50 () from /usr/lib/hpux64/dld.so ---------- components: ctypes messages: 157928 nosy: pda priority: normal severity: normal status: open title: Crash in Modules/_ctypes/libffi/src/dlmalloc.c on ia64-hp-hpux11.31 type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 04:19:33 2012 From: report at bugs.python.org (Paul A.) Date: Tue, 10 Apr 2012 02:19:33 +0000 Subject: [issue14526] Python-2.6.8rc2 test never finishes ia64-hp-hpux11.31 In-Reply-To: <1333850796.49.0.00984513973581.issue14526@psf.upfronthosting.co.za> Message-ID: <1334024373.42.0.741358535169.issue14526@psf.upfronthosting.co.za> Paul A. added the comment: Apparently my memory was faulty the other day... 2.7.2 does crash the same way as Python-2.7.3rc2 on this box. I opened a new bug report for that, so will close this one. I'll also sign up for core-mentorship as you suggest, and see what I can do to help. ---------- resolution: -> postponed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 04:25:24 2012 From: report at bugs.python.org (Paul A.) Date: Tue, 10 Apr 2012 02:25:24 +0000 Subject: [issue14524] Python-2.7.3rc2/Modules/_ctypes/libffi/src/dlmalloc.c won't compile on ia64-hp-hpux11.31 without -DHAVE_USR_INCLUDE_MALLOC_H In-Reply-To: <1333849818.58.0.912863620165.issue14524@psf.upfronthosting.co.za> Message-ID: <1334024724.52.0.98438321903.issue14524@psf.upfronthosting.co.za> Paul A. added the comment: Will close this -- I'll try to help improve configure as I can get time. ---------- resolution: -> postponed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 04:45:34 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 10 Apr 2012 02:45:34 +0000 Subject: [issue14512] Pydocs module docs server not working on Windows. In-Reply-To: <1333645625.74.0.578211515784.issue14512@psf.upfronthosting.co.za> Message-ID: <1334025934.38.0.829383653052.issue14512@psf.upfronthosting.co.za> Nick Coghlan added the comment: Hmm, we changed a few things with the way the back end server for pydoc works in 3.2. I didn't realise there was a Windows shortcut though, and I don't know how it gets generated. It sounds like it is still using the "-g" option, which is now deprecated. If you run "pydoc -b" from a command line window, does that work correctly? ("-g" should still work as well, even though it's deprecated, but knowing whether or not "-b" is also broken may help diagnose the problem) ---------- assignee: docs at python -> components: -Documentation nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 04:52:33 2012 From: report at bugs.python.org (Paul A.) Date: Tue, 10 Apr 2012 02:52:33 +0000 Subject: [issue14527] How to link with an external libffi? In-Reply-To: <1333851935.11.0.629390980004.issue14527@psf.upfronthosting.co.za> Message-ID: <1334026353.34.0.281847155594.issue14527@psf.upfronthosting.co.za> Paul A. added the comment: Yes, I think my libffi setup is okay, but python apparently doesn't (according to the deeper-down log files I didn't initially know about). The following is a suspicious-looking snippet from build/temp.hp-ux-B.11.31-ia64-2.7/libffi/config.log... I have to question the usefulness of that linker error message. My immediate thought is that maybe conftstm.o is a 32-bit object file, but I don't see anything earlier in the log to indicate it was even created. configure:6159: gcc463 -o conftest -I. -IInclude -I./Include -D_TERMIOS_INCLUDED -I/usr/local/lp64/include -mlp64 -L/usr/local/src/Python-2.7.2 -L/usr/local/lp64/lib conftest.c conftstm.o >&5 ld: Mismatched Data ABI. Expected EF_IA_64_ABI64 but found None in file conftstm.o Fatal error. ---------- components: +ctypes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 04:56:46 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 10 Apr 2012 02:56:46 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: <4F8370A6.9010405@egenix.com> Message-ID: Alexander Belopolsky added the comment: On Mon, Apr 9, 2012 at 7:28 PM, Marc-Andre Lemburg wrote: > You don't really expect anyone to remember such rules, do you ? :-) No, but it is still a one-line function that those who need it can easily implement. I am on the fence here because we already have date.isocalendar() function, so it is natural to desire its inverse, but still at least on this side of the pond an Easter(year) date constructor would see more use than that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 05:47:33 2012 From: report at bugs.python.org (mattip) Date: Tue, 10 Apr 2012 03:47:33 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1334029653.44.0.0982363923548.issue14521@psf.upfronthosting.co.za> mattip added the comment: The pickle issue occurs in the numpy module, on windows >> cPickle.dumps(numpy.array(float('nan'))) yeilds "cnumpy.core.multiarray\n_reconstruct\np1\n(cnumpy\nndarray\np2\n(I0\ntS'b'\ntRp3\n(I1\n(tcnumpy\ndtype\np4\n(S'f8'\nI0\nI1\ntRp5\n(I3\nS'<'\nNNNI-1\nI-1\nI0\ntbI00\nS'\\x00\\x00\\x00\\x00\\x00\\x00\\xf8\\xff'\ntb." While this is not a python core issue, it seems that python core could be one possible solution point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 07:42:26 2012 From: report at bugs.python.org (Martin von Gagern) Date: Tue, 10 Apr 2012 05:42:26 +0000 Subject: [issue11218] pattern=None when following documentation for load_tests and unittest.main() In-Reply-To: <1297758807.39.0.713611114484.issue11218@psf.upfronthosting.co.za> Message-ID: <1334036546.49.0.741996683976.issue11218@psf.upfronthosting.co.za> Martin von Gagern added the comment: Rik, I don't follow your argument on not changing discover. Currently, if code calls discover with pattern=None, there will be an exception. So there cannot be any working code out there which passes pattern=None. Therefore, it should be all right for the implementation to detect the None and replace it by a default. No currently working code should be affected, and new code could be shorter that way. The pattern still wouldn't be stored inside the loader, so the doc there still holds. Only the fallback for None would be stored. By the way, what's the rationale behind passing the pattern to the load_tests function? Shouldn't each package decide which of its files constitute the test suite, independent of what the parent module used as a filter? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 08:47:02 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 10 Apr 2012 06:47:02 +0000 Subject: [issue14512] Pydocs module docs server not working on Windows. In-Reply-To: <1333645625.74.0.578211515784.issue14512@psf.upfronthosting.co.za> Message-ID: <1334040422.82.0.89261153976.issue14512@psf.upfronthosting.co.za> Terry J. Reedy added the comment: C:\Programs\Python32\Tools\Scripts>..\..\pythonw pydocgui.pyw -b has the same behavior I described. So does -g. The shortcut has been part of the Windows installation for many versions. It obviously uses pydocgui.py. C:\Programs\Python32\Lib>pydoc.py -b # starts one python.exe process # prints on the next lines in the command window Server ready at http://localhost:50695/ Server commands: [b]rowser, [q]uit server> # and opens blank localhost:50695 browser window after asking for permission for python to access local network (which I gave). 'b' at prompt opens another blank window. C:\Programs\Python32\Lib>pydoc.py -w difflib #prints wrote difflib.html #which it did, looking as expected when opened in browser, with lots of cross-links. So what it seems is not working in either case is opening the html page in the browser or connecting it to the server. C:\Programs\Python32\Lib>webbrowser.py python.org opens the page in *Internet Explorer* rather than Firefox (my default browser). pydoc tried to connect to the server in a new FF tab. When I re-ran pydoc and tried to open localhost:50695 in IE, it gave me the result of a Bing search (one help forum post), so neither browser can find anything at that url. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 08:54:11 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 10 Apr 2012 06:54:11 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1334040851.66.0.451686471304.issue14521@psf.upfronthosting.co.za> Mark Dickinson added the comment: > The pickle issue occurs in the numpy module, on windows I'm still not clear what the issue is. Is there something wrong in the output of the pickle example you show? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 09:34:00 2012 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 10 Apr 2012 07:34:00 +0000 Subject: [issue14539] logging module: logger does not print log message with logging.INFO level In-Reply-To: <1334008275.31.0.522161663981.issue14539@psf.upfronthosting.co.za> Message-ID: <1334043240.72.0.130200953904.issue14539@psf.upfronthosting.co.za> Vinay Sajip added the comment: You haven't configured any handlers for the logger, so by default it wouldn't actually log anything. However, when no handlers are configured, logging uses an internal "last resort" handler to print the message to sys.stderr, and this handler has a threshold of WARNING (it's meant to print stdlib warnings and errors when no handlers are configured by an application). If you add the lines, you should see something like this: >>> logging.basicConfig(level=logging.INFO, format='%(message)s') >>> logging.info('info message') info message See http://docs.python.org/py3k/howto/logging.html#what-happens-if-no-configuration-is-provided for more information. ---------- assignee: -> vinay.sajip resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 10:26:13 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 10 Apr 2012 08:26:13 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: <1332849673.66.0.0828799259938.issue14423@psf.upfronthosting.co.za> Message-ID: <1334046373.88.0.130008948509.issue14423@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: -haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 11:13:06 2012 From: report at bugs.python.org (mattip) Date: Tue, 10 Apr 2012 09:13:06 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1334049186.77.0.789197869267.issue14521@psf.upfronthosting.co.za> mattip added the comment: The pickle output has the sign-bit set. Ignoring the sign-bit, it is unpickled correctly. However math.copysign using this value will now return minus on platforms where copysign(3., float('nan')) is known to work. Perhaps the whole can of worms should not have been opened in the first place. Another solution would be to raise a ValueError if copysign(x, float('nan')) is called... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 11:36:09 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 10 Apr 2012 09:36:09 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1334050569.4.0.234490658516.issue14521@psf.upfronthosting.co.za> Mark Dickinson added the comment: > The pickle output has the sign-bit set. Ignoring the sign-bit, it is > unpickled correctly. Okay, thanks for the clarification. I just wanted to be clear whether there's a real problem with pickle that should be fixed in 2.7 or not. Again, I don't see this as a bug: pickle is transferring the sign bit correctly, so the only issue again is that float('nan') happens to produce a nan whose sign bit is set (depending on platform, compiler options, etc.). I don't see it as a problem that one can end up with some 'positive' nans and some 'negative' nans on a single system. As far as I know, none of this violates any documentation or standards (IEEE 754 explicitly places no interpretation on the sign bit of a nan, and makes no guarantees or recommendations about the sign bit of the result of converting the string 'nan'). So at worst, this is a minor violation of user expectations. Though I do agree that having float('-nan') having its sign bit unset is especially surprising. So while I don't see this as a bug that should be fixed for 2.7, I'm happy to 'fix' this for Python 3.3, partly for the portability improvement, and partly to avoid having the string-to-float conversions do INF*0 calculations at run time; that bit's always made me feel uncomfortable. Thanks for the updated patch; I'll take a look shortly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 11:48:20 2012 From: report at bugs.python.org (=?utf-8?q?Esben_Agerb=C3=A6k_Black?=) Date: Tue, 10 Apr 2012 09:48:20 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: <1334011854.3379.53.camel@localhost.localdomain> Message-ID: Esben Agerb?k Black added the comment: I believe that it is a good solution to have, for lack of a better term; bi-directional features so in my opinion .isocalendar() merits having a constructor that takes an ISO format. Sadly no :-( I looked it over once more and it seems there is an error where the date is not offset correctly for years beginning on Tuesday, Wednesday or Thursday. I will updater my patch ASAP. + if self.isocalendar()[1] != 1: + if self.weekday() > 3: # Jan 1 is not in week one + self += timedelta(7 - self.weekday()) + else: + self -= timedelta(self.weekday()) ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 12:05:21 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 10 Apr 2012 10:05:21 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za> Message-ID: <1334052321.23.0.196121442961.issue8799@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: We shouldn't be testing implementation details. The Condition variables are canonically prone to "spurious wakeups" and "stolen wakeups". The fact that the current implementation doesn't have them shouldn't place that burden on future implementations of threading.Condition on this platform. >From the docs: "Note: Condition variables can be, depending on the implementation, subject to both spurious wakeups (when wait() returns without a notify() call) and stolen wakeups (when another thread acquires the lock before the awoken thread.) For this reason, it is always necessary to verify the state the thread is waiting for when wait() returns and optionally repeat the call as often as necessary." 2) You would build a lock yourself if you wanted exact control over its behaviour. In this case, we are just doing what threading.Lock() does, but it could be more complicated. At any rate, it proves a useful toy usage of a condition variable in the context of making sure that it works properly as part of the unit tests. I could leave the original test in place and just add the new ones, but the old test is at least provably a subject to a race condition as per the original issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 12:26:45 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 10 Apr 2012 10:26:45 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1334053605.96.0.497806970971.issue14478@psf.upfronthosting.co.za> Stefan Krah added the comment: I think it would be a good idea to fix this in the Python version for the other implementations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 12:38:59 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 10 Apr 2012 10:38:59 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1334052321.23.0.196121442961.issue8799@psf.upfronthosting.co.za> Message-ID: <1334054009.3389.5.camel@localhost.localdomain> Antoine Pitrou added the comment: > The Condition variables are canonically prone to "spurious wakeups" > and "stolen wakeups". No, they aren't. Just because POSIX says they are doesn't mean *our* condition variables are the same. Spurious wakeups are an annoyance, and our implementation AFAICT never exhibited them. > From the docs: "Note: Condition variables can be, depending on the > implementation, subject to both spurious wakeups (when wait() returns > without a notify() call) and stolen wakeups (when another thread > acquires the lock before the awoken thread.) For this reason, it is > always necessary to verify the state the thread is waiting for when > wait() returns and optionally repeat the call as often as necessary." Ah, thanks, indeed. Except that... this was added by yourself in 483bbebc57bf, after issue 10260, but *without* being part of the original patch that you uploaded on that issue. So this never got reviewed and was instead sneaked in the docs in a commit of yours. Unless other people disagree, I think this addition should be reverted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 12:44:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 10 Apr 2012 10:44:41 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: Message-ID: <1334054351.3389.8.camel@localhost.localdomain> Antoine Pitrou added the comment: > No, but it is still a one-line function that those who need it can > easily implement. It's so easy that the patch isn't a one-liner and it seems to still have bugs wrt. intended behaviour. > I am on the fence here because we already have > date.isocalendar() function, so it is natural to desire its inverse, > but still at least on this side of the pond an Easter(year) date > constructor would see more use than that. This isn't an either/or situation. We can have both from_iso_week() and Easter() if both are useful. And I don't get this "side of the pond" argument. Python is not meant only for the American public, that's why all strings are now unicode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 14:18:29 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 10 Apr 2012 12:18:29 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1334060309.77.0.13235700817.issue14243@psf.upfronthosting.co.za> R. David Murray added the comment: "delete_after" what? I know it is somewhat implicit in the fact that it is a context manager call, but that is not the only context the method name will be seen in. (eg: 'dir' list of methods, doc index, etc). Even as a context manager my first thought in reading it was "delete after what?", and then I went, "oh, right". How about "delete_on_exit"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 14:29:46 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 10 Apr 2012 12:29:46 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1334060986.85.0.216475501797.issue14243@psf.upfronthosting.co.za> R. David Murray added the comment: By the way, I still think it would be nicer just to have the context manager work as expected with delete=True (ie: doesn't delete until the end of the context manager, whether the file is closed or not). I'm OK with being voted down on that, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 14:31:30 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 10 Apr 2012 12:31:30 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1334060986.85.0.216475501797.issue14243@psf.upfronthosting.co.za> Message-ID: <1334060760.5371.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > By the way, I still think it would be nicer just to have the context > manager work as expected with delete=True (ie: doesn't delete until > the end of the context manager, whether the file is closed or not). > I'm OK with being voted down on that, though. Indeed, the current behaviour under Windows seems to be kind of a nuisance, and having to call a separate method doesn't sound very user-friendly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 15:08:59 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Tue, 10 Apr 2012 13:08:59 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1334060760.5371.1.camel@localhost.localdomain> Message-ID: <5A500C6B-914E-4380-868E-471DEA930177@jaraco.com> Jason R. Coombs added the comment: I agree. If the primary usage of the class does not work well on Windows, developers will continue to write code using the primary usage because it works on their unix system, and it will continue to cause failures when run on windows. Because Python should run cross-platform, I consider this a bug in the implementation and would prefer it be adapted such that the primary use case works well on all major platforms. If there is a separate class method for different behavior, it should be for the specialized behavior, not for the preferred, portable behavior. I recognize there are backward-compatibility issues here, so maybe it's necessary to deprecate NamedTemporaryFile in favor of a replacement. ---------- title: tempfile.NamedTemporaryFile not particularly useful on Windows -> tempfile.NamedTemporaryFile not particularly useful on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 15:15:29 2012 From: report at bugs.python.org (sbt) Date: Tue, 10 Apr 2012 13:15:29 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1334063729.89.0.233999743809.issue4892@psf.upfronthosting.co.za> sbt added the comment: Updated patch which uses ForkingPickler in Connection.send(). Note that connection sharing still has to be enabled using allow_connection_pickling(). Support could be enabled automatically, but that would introduce more circular imports which confuse me. It might be worthwhile refactoring to eliminate all circular imports. ---------- Added file: http://bugs.python.org/file25167/mp_pickle_conn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 15:32:30 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 10 Apr 2012 13:32:30 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: <1334054351.3389.8.camel@localhost.localdomain> Message-ID: Alexander Belopolsky added the comment: On Tue, Apr 10, 2012 at 6:44 AM, Antoine Pitrou wrote: > It's so easy that the patch isn't a one-liner and it seems to still have > bugs wrt. intended behaviour. Unless I miss something, the inverse to isocalendar() is simply from datetime import * def fromiso(year, week, day): d = date(year, 1, 4) return d + timedelta((week - 1) * 7 + day - d.isoweekday()) At least it works in my testing: (2012, 15, 2) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 15:42:47 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 10 Apr 2012 13:42:47 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1334065367.33.0.05253526615.issue14243@psf.upfronthosting.co.za> R. David Murray added the comment: Well, fixing NamedTemporaryFile in either of the ways we've discussed isn't going to fix people writing non-portable code. A unix coder isn't necessarily going to close the file before reading it. However, it would at least significantly increase the odds that the code would be portable, while the current situation *ensures* that the code is not portable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 15:55:38 2012 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 10 Apr 2012 13:55:38 +0000 Subject: [issue14541] test_sndhdr fails when run from an installation Message-ID: <1334066138.27.0.944851053898.issue14541@psf.upfronthosting.co.za> New submission from Vinay Sajip : test_sndhdr fails when run from an installed Python, due to a missing directory in the installation. The attached patch should rectify this. ---------- components: Library (Lib) files: Makefile.pre.in.diff keywords: easy, patch messages: 157953 nosy: georg.brandl, vinay.sajip priority: normal severity: normal status: open title: test_sndhdr fails when run from an installation type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file25168/Makefile.pre.in.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 15:57:30 2012 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 10 Apr 2012 13:57:30 +0000 Subject: [issue14541] test_sndhdr fails when run from an installation In-Reply-To: <1334066138.27.0.944851053898.issue14541@psf.upfronthosting.co.za> Message-ID: <1334066250.75.0.411769375032.issue14541@psf.upfronthosting.co.za> Vinay Sajip added the comment: Whoops, I think I added Georg when I meant Victor ... ---------- nosy: +haypo -georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 16:16:45 2012 From: report at bugs.python.org (Jim Jewett) Date: Tue, 10 Apr 2012 14:16:45 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1334067405.21.0.830985954446.issue14478@psf.upfronthosting.co.za> Jim Jewett added the comment: Stefan Krah has a good point. Since the only cost is an extra slot, and this is for users who have already chosen to use Decimal instead of a more efficient (but possibly less accurate) representation, even without the native speedups to Decimal ... I guess I'm now +1. It is clearly an implementation detail, so I don't think the docs need to be changed. I'm not sure the tests do, nor am I sure *how* to test for it in a black-box fashion. I have reviewed the patch and have no objections. So unless a new objection comes up in the next few days, I would say this is ready to be checked in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 16:30:22 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 10 Apr 2012 14:30:22 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset a012d5df2c73 by Stefan Krah in branch 'default': Issue #14478: Cache the hash of a Decimal in the C version. http://hg.python.org/cpython/rev/a012d5df2c73 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 16:35:01 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 10 Apr 2012 14:35:01 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1334068501.89.0.905956489314.issue14478@psf.upfronthosting.co.za> Stefan Krah added the comment: I changed the C version to cache the hash as well: For the submitted test case the speedup is only 5x, but hashing times vary greatly depending of the size of the coefficient and the exponent. BTW, the tests already call both hash() and __hash__() on the same number, so retrieving the cached value is actually tested. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 17:13:10 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 10 Apr 2012 15:13:10 +0000 Subject: [issue14541] test_sndhdr fails when run from an installation In-Reply-To: <1334066138.27.0.944851053898.issue14541@psf.upfronthosting.co.za> Message-ID: <1334070790.94.0.390582120293.issue14541@psf.upfronthosting.co.za> STINNER Victor added the comment: Data files were added by the issue #9243 for new tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 17:15:53 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 10 Apr 2012 15:15:53 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1334070953.25.0.0683775652857.issue14478@psf.upfronthosting.co.za> Stefan Krah added the comment: The patch for the Python version looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 17:32:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 10 Apr 2012 15:32:42 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1334071962.9.0.471486536319.issue4892@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Support could be enabled automatically, but that would introduce more > circular imports which confuse me. Are you sure? AFAICT: - connection depends on forking - reduction depends on forking and connection But connection doesn't depend on reduction, neither does forking. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 18:06:50 2012 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 10 Apr 2012 16:06:50 +0000 Subject: [issue14541] test_sndhdr fails when run from an installation In-Reply-To: <1334066138.27.0.944851053898.issue14541@psf.upfronthosting.co.za> Message-ID: <1334074010.36.0.913049263963.issue14541@psf.upfronthosting.co.za> Vinay Sajip added the comment: > Data files were added by the issue #9243 for new tests. That's fine, it's just that the Makefile needs to include the new directory test/sndhdrdata (which my patch does). I could have committed the change, but thought you should be in the loop. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 18:10:40 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Apr 2012 16:10:40 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1334070953.25.0.0683775652857.issue14478@psf.upfronthosting.co.za> Message-ID: <1334074381.2496.19.camel@raxxla> Serhiy Storchaka added the comment: > The patch for the Python version looks good to me Oh, but used by James Hutchison approach is faster. When I disable the _decimal: Unpatched: int: 2.24056077003479 CachingDecimal: 8.49468207359314 Decimal: 187.68132972717285 With rhettinger's LBYL patch: int: 2.1670639514923096 CachingDecimal: 8.790924310684204 Decimal: 10.426796436309814 With EAFP patch: int: 2.1392786502838135 CachingDecimal: 8.431122303009033 Decimal: 8.263015270233154 ---------- Added file: http://bugs.python.org/file25169/decimal_hash_2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r a012d5df2c73 Lib/decimal.py --- a/Lib/decimal.py Tue Apr 10 16:27:58 2012 +0200 +++ b/Lib/decimal.py Tue Apr 10 18:46:19 2012 +0300 @@ -547,7 +547,7 @@ class Decimal(object): """Floating point class for decimal arithmetic.""" - __slots__ = ('_exp','_int','_sign', '_is_special') + __slots__ = ('_exp','_int','_sign', '_is_special', '_hash') # Generally, the value of the Decimal instance is given by # (-1)**_sign * _int * 10**_exp # Special values are signified by _is_special == True @@ -983,6 +983,10 @@ def __hash__(self): """x.__hash__() <==> hash(x)""" + try: + return self._hash + except AttributeError: + pass # In order to make sure that the hash of a Decimal instance # agrees with the hash of a numerically equal integer, float @@ -992,20 +996,22 @@ if self.is_snan(): raise TypeError('Cannot hash a signaling NaN value.') elif self.is_nan(): - return _PyHASH_NAN + hash_ = _PyHASH_NAN else: if self._sign: - return -_PyHASH_INF + hash_ = -_PyHASH_INF else: - return _PyHASH_INF - - if self._exp >= 0: - exp_hash = pow(10, self._exp, _PyHASH_MODULUS) + hash_ = _PyHASH_INF else: - exp_hash = pow(_PyHASH_10INV, -self._exp, _PyHASH_MODULUS) - hash_ = int(self._int) * exp_hash % _PyHASH_MODULUS - ans = hash_ if self >= 0 else -hash_ - return -2 if ans == -1 else ans + if self._exp >= 0: + exp_hash = pow(10, self._exp, _PyHASH_MODULUS) + else: + exp_hash = pow(_PyHASH_10INV, -self._exp, _PyHASH_MODULUS) + hash_ = int(self._int) * exp_hash % _PyHASH_MODULUS + if self < 0: hash_ = -hash_ + if hash_ == -1: hash_ = -2 + self._hash = hash_ + return hash_ def as_tuple(self): """Represents the number as a triple tuple. From report at bugs.python.org Tue Apr 10 18:11:15 2012 From: report at bugs.python.org (sbt) Date: Tue, 10 Apr 2012 16:11:15 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1334074275.63.0.510653243132.issue4892@psf.upfronthosting.co.za> sbt added the comment: > But connection doesn't depend on reduction, neither does forking. If registration of (Pipe)Connection is done in reduction then you can't make (Pipe)Connection picklable *automatically* unless you make connection depend on reduction (possibly indirectly). A circular import can be avoided by making reduction not import connection at module level. So not hard to fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 18:14:58 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 10 Apr 2012 16:14:58 +0000 Subject: [issue14541] test_sndhdr fails when run from an installation In-Reply-To: <1334066138.27.0.944851053898.issue14541@psf.upfronthosting.co.za> Message-ID: <1334074498.07.0.92642835817.issue14541@psf.upfronthosting.co.za> STINNER Victor added the comment: Python 3.2 should also be fixed. You may need to patch Tools/msi/msi.py in Python 3.2, not in Python 3.3 (see changeset fb7bb61c8847). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 19:00:10 2012 From: report at bugs.python.org (James Hutchison) Date: Tue, 10 Apr 2012 17:00:10 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1334077210.31.0.804080673441.issue14478@psf.upfronthosting.co.za> James Hutchison added the comment: In the patch: This: + except AttributeError: + pass should be: + except: Checking for the AttributeError is very slightly slower. Not by a lot, but I think if we're going for speed we might as well be as fast as possible. I can't imagine any other exception coming from that try statement. Using except: pass as opposed to sticking everything inside the except statement is also very slightly slower as well Simple test case, 10 million loops: except: 7.140999794006348 except AttributeError: 7.8440001010894775 Exception code in except: 7.483999967575073 after except/pass: 7.75 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 19:14:33 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Apr 2012 17:14:33 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1334077210.31.0.804080673441.issue14478@psf.upfronthosting.co.za> Message-ID: <1334078212.2496.23.camel@raxxla> Serhiy Storchaka added the comment: > I can't imagine any other exception coming from that try statement. KeyboardInterrupt ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 19:14:39 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 10 Apr 2012 17:14:39 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1334078079.49.0.363906994185.issue14478@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > Checking for the AttributeError is very slightly slower Why are you trying to micro-optimize the Python version, when the C implementation does it better and faster? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 19:19:40 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 10 Apr 2012 17:19:40 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za> Message-ID: <1334078380.27.0.999136726691.issue8799@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Stolen wakeups are a fact of life though, even in cpython's implementation of condition variables. And for the user of a condition variable the difference is so subtle as to not warrant special mention. This is, btw, not just a posix thing. It is same on windows, java, and in fact, comes from the original definition of a condition variable as part of the "monitor" pattern. Condition variables are defined have this caveat to allow for flexibility in their implementation. Look anywhere in the internets and you will find this, including here: http://www.cs.berkeley.edu/~kubitron/courses/cs162/hand-outs/synch.html The canonical and correct way to use a condition variable is to repeatedly wait() and verify that the wakeup condition holds. The wait_for() method abstracts this into a convenient helper. There is no need to befuddle the issue by special casing the python version as being guaranteed to not have suprious wakeups, but otherwise do have the stolen thread problem. Quite the contrary, we should be careful to never overspecify our interfaces so that we may not change their ipmlementation details later. A good summary of the situation and the reason for the specification can be found here: http://stackoverflow.com/questions/8594591/why-does-pthread-cond-wait-have-spurious-wakeups The comment I added to the documentation clarifies the reason why other examples in the docs were using while loops and teaches shows people how to use these constructs in a robust manner. Removing it is a bad idea and I think you will find others will agree. Take it up on python-dev if you want. Unless you disagree, I'll add these test cases in addition to the broken one, which can then be fixed or removed later if it turns out to be problematic to other people. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 19:29:19 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Apr 2012 17:29:19 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1334077210.31.0.804080673441.issue14478@psf.upfronthosting.co.za> Message-ID: <1334079099.2496.30.camel@raxxla> Serhiy Storchaka added the comment: > Using except: pass as opposed to sticking everything inside the except statement is also very slightly slower as well I ran the test several times and didn't see the difference between pass and sticking variants more than between different runs of the same variant. If it is, then this is a reason for the interpreter optimization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 19:44:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 10 Apr 2012 17:44:57 +0000 Subject: [issue14541] test_sndhdr fails when run from an installation In-Reply-To: <1334066138.27.0.944851053898.issue14541@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b2242224fb7f by Vinay Sajip in branch '3.2': Issue #14541: Added test/sndhdrdata to Makefile.pre.in for installation. http://hg.python.org/cpython/rev/b2242224fb7f New changeset 54bc19fc5b46 by Vinay Sajip in branch 'default': Issue #14541: Merged addition of test/sndhdrdata to Makefile.pre.in from 3.2. http://hg.python.org/cpython/rev/54bc19fc5b46 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 19:53:05 2012 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 10 Apr 2012 17:53:05 +0000 Subject: [issue14541] test_sndhdr fails when run from an installation In-Reply-To: <1334066138.27.0.944851053898.issue14541@psf.upfronthosting.co.za> Message-ID: <1334080385.37.0.970388942799.issue14541@psf.upfronthosting.co.za> Vinay Sajip added the comment: Closing, as msi.py for 3.2 appears to already include sndhdrdata. ---------- assignee: -> vinay.sajip resolution: -> fixed status: open -> closed versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 20:01:50 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 10 Apr 2012 18:01:50 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1334054009.3389.5.camel@localhost.localdomain> Message-ID: Charles-Fran?ois Natali added the comment: >> The Condition variables are canonically prone to "spurious wakeups" >> and "stolen wakeups". > > No, they aren't. Just because POSIX says they are doesn't mean *our* > condition variables are the same. Spurious wakeups are an annoyance, and > our implementation AFAICT never exhibited them. I agree with Antoine. Spurious wakeups are an implementation issue (mainly has to do with efficiency on SMP systems and interrupted syscalls), but are definitely not a part of the "standard" API. Since our implementation doesn't exhibit this problem, there's no reason to scare and confuse people. For example, our locks are special in the sense that they can be released by a thread other than the one that acquired it, etc, and this behavior is documented. However, while I think the spurious wakeups reference could be removed, I think that the advice of repeatedly chcking the invariant shoud be kept, because it is always desirable (stolen wakeup, and better logic). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 20:03:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 10 Apr 2012 18:03:33 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1334078380.27.0.999136726691.issue8799@psf.upfronthosting.co.za> Message-ID: <1334080681.5371.20.camel@localhost.localdomain> Antoine Pitrou added the comment: > Stolen wakeups are a fact of life though, even in cpython's > implementation of condition variables. And for the user of a > condition variable the difference is so subtle as to not warrant > special mention. I don't think it's a subtle difference. Being woken up too late is not the same as being woken up spuriously. Also, the term "stolen wakeup" makes it unnecessarily dramatic. There is no "stealing" involved here. > Look anywhere in the internets and you will find this, including here: > http://www.cs.berkeley.edu/~kubitron/courses/cs162/hand-outs/synch.html Thanks, will take a look. > Quite the contrary, we should be careful to never overspecify our > interfaces so that we may not change their ipmlementation details > later. The interface is already, de facto, specified by its one and only implementation, which has been in use for a long time. It's also specified by its documentation, before it was silently modified by you. There's probably code out there that relies on wait() not returning prematurately. > A good summary of the situation and the reason for the specification > can be found here: > http://stackoverflow.com/questions/8594591/why-does-pthread-cond-wait-have-spurious-wakeups So the reason appears to be: ?Spurious wakeups may sound strange, but on some multiprocessor systems, making condition wakeup completely predictable might substantially slow all condition variable operations.? Python is a high-level language, so making condition variable ops "substantially" slower is not a blocking issue for us. What follows is even less enlightening: ?The intent was to force correct/robust code by requiring predicate loops. This was driven by the provably correct academic contingent among the "core threadies" in the working group, though I don't think anyone really disagreed with the intent once they understood what it meant.? > The comment I added to the documentation clarifies the reason why > other examples in the docs were using while loops and teaches shows > people how to use these constructs in a robust manner. Teaching people to use loops is fine. But there's no need to mislead them with inaccurate descriptions of the implementation's behaviour. > Unless you disagree, I'll add these test cases in addition to the > broken one, which can then be fixed or removed later if it turns out > to be problematic to other people. Really, can you stop being aggressive? You haven't proved that test is wrong, and it passes consistently fine on all buildbots. If you don't agree with what is being tested, that's another matter. But please accept that the test is ok w.r.t. Condition's specified behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 20:17:39 2012 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 10 Apr 2012 18:17:39 +0000 Subject: [issue14098] provide public C-API for reading/setting sys.exc_info() In-Reply-To: <1329983921.26.0.0291312337524.issue14098@psf.upfronthosting.co.za> Message-ID: <1334081859.05.0.695906085322.issue14098@psf.upfronthosting.co.za> Stefan Behnel added the comment: Done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 20:25:10 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 10 Apr 2012 18:25:10 +0000 Subject: [issue13165] Integrate stringbench in the Tools directory In-Reply-To: Message-ID: <1334082449.2496.36.camel@raxxla> Serhiy Storchaka added the comment: > Please open a new issue for such improvement. Well, I'll do it as soon as slightly improve the script. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 20:29:30 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Tue, 10 Apr 2012 18:29:30 +0000 Subject: [issue12978] Figure out extended attributes on BSDs In-Reply-To: <1316014526.21.0.982877507813.issue12978@psf.upfronthosting.co.za> Message-ID: <1334082570.65.0.166181503156.issue12978@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 20:39:36 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 10 Apr 2012 18:39:36 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za> Message-ID: <1334083176.07.0.925096151156.issue8799@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm proposing the following changes to the threading docs. Most of them are cleanups and small improvements, but I also rewrote the offending paragraph, and made the wait_for example more proeminent. ---------- Added file: http://bugs.python.org/file25170/tpconditiondoc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 21:19:13 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 10 Apr 2012 19:19:13 +0000 Subject: [issue10484] http.server.is_cgi fails to handle CGI URLs containing PATH_INFO In-Reply-To: <1290324717.4.0.0270982528857.issue10484@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 89eeaa18700f by Senthil Kumaran in branch '2.7': fix the incorrect changes made for PATH_INFO value - Issue10484 http://hg.python.org/cpython/rev/89eeaa18700f New changeset 827a4062b1d6 by Senthil Kumaran in branch '3.2': 3.2- fix the incorrect changes made for PATH_INFO value - Issue10484 http://hg.python.org/cpython/rev/827a4062b1d6 New changeset 8bcc5768bc05 by Senthil Kumaran in branch 'default': merge - fix the incorrect changes made for PATH_INFO value - Issue10484 http://hg.python.org/cpython/rev/8bcc5768bc05 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 21:23:25 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 10 Apr 2012 19:23:25 +0000 Subject: [issue14258] Better explain re.LOCALE and re.UNICODE for \S and \W In-Reply-To: <1331522526.82.0.873716298557.issue14258@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 4d49a2415ced by Senthil Kumaran in branch '2.7': Fix closes Issue14258 - Clarify the re.LOCALE and re.UNICODE flags for \S class http://hg.python.org/cpython/rev/4d49a2415ced ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 21:35:28 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 10 Apr 2012 19:35:28 +0000 Subject: [issue10484] http.server.is_cgi fails to handle CGI URLs containing PATH_INFO In-Reply-To: <1290324717.4.0.0270982528857.issue10484@psf.upfronthosting.co.za> Message-ID: <1334086528.33.0.596599202445.issue10484@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I had to carefully review a lot of changes for this. In addition, I did setup a apache and tested the behaviors too. Few notes - - The test for _url_collapse_path_split is not directly helpful, especially for PATH_INFO. I removed my previous changes I had made as I think, it is a mistake to test PATH_INFO in there. - There is not a test for path_info, it should be added. I could test only on local apache setup. - Coming the changes itself, the previous _url_collapse_path_split was just fine for what it is supposed to do. Return head and tail for certain definitions of parsing (removing . and .. and tail is last part and rest is head). - I incorporated Glenn Linderman logic in is_cgi to have explicit head and tail. Glenn's comment and cgi directories could overridden is important and in that ascept the previous commit had to be changed. I also looked at changes in the patches contained in issue 13893, but I found that those broke behavior or exhibited the security issue again. taking care of all these, I have the made the changes to the cgi module and also verified pratically that PATH_INFO is indeed sent correctly. Ran python -m CGIHttpServer and placed cgi-bin/file1.py and sent some requests to verify PATH_INFO. The values were proper. With this, I think this issue can be closed. The rest of the cgi changes can be handled in their respective issues. A test to PATH_INFO could just be added. ---------- Added file: http://bugs.python.org/file25171/file1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 22:21:12 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 10 Apr 2012 20:21:12 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1334083176.07.0.925096151156.issue8799@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I'm proposing the following changes to the threading docs. Most of them are cleanups and small improvements, but I also rewrote the offending paragraph, and made the wait_for example more proeminent. Looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 22:41:02 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 10 Apr 2012 20:41:02 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334090462.95.0.338386555856.issue14532@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: > Therefore the expected digest changes each time. Exactly. Timing attacks (which aren't really new :-) depend on a constant digest to successively determine the characters composing the digest. Here, that won't work, because the digest changes every time. ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 22:50:15 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 10 Apr 2012 20:50:15 +0000 Subject: [issue14540] Crash in Modules/_ctypes/libffi/src/dlmalloc.c on ia64-hp-hpux11.31 In-Reply-To: <1334023876.29.0.692126392594.issue14540@psf.upfronthosting.co.za> Message-ID: <1334091015.12.0.545255208732.issue14540@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: This stack trace is strange. Is it really the python binary? Anyway, if it's segfaulting inside dlmalloc, there's probably not much we can do. Actually, I wonder why we still ship it... ---------- nosy: +neologix, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 22:52:31 2012 From: report at bugs.python.org (=?utf-8?q?Esben_Agerb=C3=A6k_Black?=) Date: Tue, 10 Apr 2012 20:52:31 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: Message-ID: Esben Agerb?k Black added the comment: 1) Yes I agree, your solution is somewhat more concise, I have corrected the code accordingly. 2) I get errors for all my test when I build "my" python and run "./python.exe -m test.datetimetester -j3" I asume this is because I have yet to implement the c version in Modules/_datetimemodule.c is this the correct assumption? Kind regards On Tue, Apr 10, 2012 at 3:32 PM, Alexander Belopolsky < report at bugs.python.org> wrote: > > Alexander Belopolsky added the comment: > > On Tue, Apr 10, 2012 at 6:44 AM, Antoine Pitrou > wrote: > > It's so easy that the patch isn't a one-liner and it seems to still have > > bugs wrt. intended behaviour. > > Unless I miss something, the inverse to isocalendar() is simply > > from datetime import * > > def fromiso(year, week, day): > d = date(year, 1, 4) > return d + timedelta((week - 1) * 7 + day - d.isoweekday()) > > At least it works in my testing: > > (2012, 15, 2) > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 22:57:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 10 Apr 2012 20:57:09 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2f51dca92883 by Antoine Pitrou in branch '3.2': Issue #8799: Fix and improve the threading.Condition documentation. http://hg.python.org/cpython/rev/2f51dca92883 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 22:58:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 10 Apr 2012 20:58:08 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: Message-ID: <1334091156.5371.28.camel@localhost.localdomain> Antoine Pitrou added the comment: > 1) Yes I agree, your solution is somewhat more concise, I have corrected > the code accordingly. > 2) I get errors for all my test when I build "my" python and run > "./python.exe -m test.datetimetester -j3" > I asume this is because I have yet to implement the c version in > Modules/_datetimemodule.c > is this the correct assumption? You should probably run "./python.exe -m test -v test_datetime" instead. Not sure that will fix your test failures, though :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 22:59:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 10 Apr 2012 20:59:18 +0000 Subject: [issue14540] Crash in Modules/_ctypes/libffi/src/dlmalloc.c on ia64-hp-hpux11.31 In-Reply-To: <1334023876.29.0.692126392594.issue14540@psf.upfronthosting.co.za> Message-ID: <1334091558.23.0.210790759277.issue14540@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Anyway, if it's segfaulting inside dlmalloc, there's probably not much we can do. > Actually, I wonder why we still ship it... I think it's bundled with our copy of libffi. I agree the stacktrace is strange. At the very least it looks truncated. Also it looks like our dlmalloc has shadowed the built-in malloc, which would be quite disturbing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 22:59:47 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 10 Apr 2012 20:59:47 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za> Message-ID: <1334091587.69.0.581171045071.issue8799@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I've fixed the docs in 3.2 and 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 23:22:29 2012 From: report at bugs.python.org (Bill Jefferson) Date: Tue, 10 Apr 2012 21:22:29 +0000 Subject: [issue14542] reverse() doesn't reverse sort correctly Message-ID: <1334092948.92.0.355966941096.issue14542@psf.upfronthosting.co.za> New submission from Bill Jefferson : reverse() doesn't reverse sort correctly in Python 25 and 27. sort() works correctly, but reverse doesn't. The following uses reverse(). Incorrect. Even though the date comes first, reverse() sorts on the file name, "B57IBMCD_T.....zip" 2012-04-05 B57IBMCD_T7.2.3.1.zip 2012-03-23 B57IBMCD_T7.2.2.3.zip 2012-02-22 B57IBMCD_T7.2.2.2.zip 2012-02-13 B57IBMCD_T7.2.2.1.zip 2012-01-23 B57IBMCD_T7.2.1.1.zip 2012-03-28 B57IBMCD_T7.0.4.6.zip 2012-03-08 B57IBMCD_T7.0.4.5.zip 2012-03-03 B57IBMCD_T7.0.4.4.zip 2012-02-29 B57IBMCD_T7.0.4.3.zip 2012-01-06 B57IBMCD_T7.0.4.2.zip 2011-12-08 B57IBMCD_T7.0.4.1.zip 2012-01-06 B57IBMCD_T7.0.3.1.zip 2012-01-06 B57IBMCD_T7.0.2.2.zip 2012-01-06 B57IBMCD_T7.0.2.1.zip 2012-01-06 B57IBMCD_T6.2.4.9.zip 2011-12-07 B57IBMCD_T6.2.4.9-r1.zip 2011-09-13 B57IBMCD_T6.2.4.8.zip 2012-03-28 B57IBMCD_T6.2.4.12.zip 2012-02-15 B57IBMCD_T6.2.4.11.zip 2011-12-06 B57IBMCD_T6.2.4.10.zip ---------- components: Demos and Tools, IDLE, Windows files: EX38.PY messages: 157988 nosy: billje priority: normal severity: normal status: open title: reverse() doesn't reverse sort correctly type: performance versions: Python 2.7 Added file: http://bugs.python.org/file25172/EX38.PY _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 23:34:15 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 10 Apr 2012 21:34:15 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334093655.33.0.842095829528.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: + if (has_getickcount64) { + ULONGLONG ticks; + ticks = Py_GetTickCount64(); + result = (double)ticks * 1e-3 + } ";" is missing after "1e-3", it does not compile on Windows because of this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 10 23:45:48 2012 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 10 Apr 2012 21:45:48 +0000 Subject: [issue14542] reverse() doesn't reverse sort correctly In-Reply-To: <1334092948.92.0.355966941096.issue14542@psf.upfronthosting.co.za> Message-ID: <1334094348.56.0.434494052694.issue14542@psf.upfronthosting.co.za> Eric V. Smith added the comment: list.reverse() does not reverse a list, it reverses its current values. >>> help([].reverse) Help on built-in function reverse: reverse(...) L.reverse() -- reverse *IN PLACE* >>> ---------- nosy: +eric.smith resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 00:08:59 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 10 Apr 2012 22:08:59 +0000 Subject: [issue14478] Decimal hashing very slow, could be cached In-Reply-To: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za> Message-ID: <1334095739.31.0.664917847045.issue14478@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I don't see a need to cache the hash value in the pure Python version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 00:12:37 2012 From: report at bugs.python.org (zodalahtathi) Date: Tue, 10 Apr 2012 22:12:37 +0000 Subject: [issue14539] logging module: logger does not print log message with logging.INFO level In-Reply-To: <1334008275.31.0.522161663981.issue14539@psf.upfronthosting.co.za> Message-ID: <1334095957.97.0.429066101266.issue14539@psf.upfronthosting.co.za> zodalahtathi added the comment: Thank you for the explanation ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 00:21:11 2012 From: report at bugs.python.org (Stefan Krah) Date: Tue, 10 Apr 2012 22:21:11 +0000 Subject: [issue14341] sporadic (?) test_urllib2 failures In-Reply-To: <1331943969.2.0.17966534502.issue14341@psf.upfronthosting.co.za> Message-ID: <1334096471.94.0.28008108409.issue14341@psf.upfronthosting.co.za> Stefan Krah added the comment: How about silencing the AssertionError until a better solution is found? The patch works here. ---------- keywords: +patch Added file: http://bugs.python.org/file25173/issue14341.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 00:47:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 10 Apr 2012 22:47:40 +0000 Subject: [issue14341] sporadic (?) test_urllib2 failures In-Reply-To: <1331943969.2.0.17966534502.issue14341@psf.upfronthosting.co.za> Message-ID: <1334098060.28.0.680066194002.issue14341@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, the point of the test is to check that the warnings are issued, so silencing them kind of defeats it. Senthil, why did you use check_warning instead of assertWarns? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 01:17:49 2012 From: report at bugs.python.org (Dino Viehland) Date: Tue, 10 Apr 2012 23:17:49 +0000 Subject: [issue14543] Upgrade OpenSSL on Windows to 0.9.8u Message-ID: <1334099869.05.0.692647995835.issue14543@psf.upfronthosting.co.za> New submission from Dino Viehland : OpenSSL has had many fixes since the 0.9.8l version, and in particular there is one issue which prevents it from connecting with SSL with a client certificate: the end result is the SSL connection hangs or times out. Updating the OpenSSL version will fix this and enable better compatibility across platforms. I've attached my repro but if you want to try it you'll need a different server + private key pair to authenticate with. I've also confirmed re-building Python with 0.9.8m fixes the problem and Python currently ships with 0.9.8l. ---------- components: Extension Modules files: repro.py messages: 157995 nosy: benjamin.peterson, dino.viehland priority: release blocker severity: normal status: open title: Upgrade OpenSSL on Windows to 0.9.8u type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file25174/repro.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 01:19:09 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 10 Apr 2012 23:19:09 +0000 Subject: [issue14543] Upgrade OpenSSL on Windows to 0.9.8u In-Reply-To: <1334099869.05.0.692647995835.issue14543@psf.upfronthosting.co.za> Message-ID: <1334099949.41.0.413352693783.issue14543@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 01:20:25 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 10 Apr 2012 23:20:25 +0000 Subject: [issue14543] Upgrade OpenSSL on Windows to 0.9.8u In-Reply-To: <1334099869.05.0.692647995835.issue14543@psf.upfronthosting.co.za> Message-ID: <1334100025.66.0.403045374411.issue14543@psf.upfronthosting.co.za> STINNER Victor added the comment: Why not upgrading to OpenSSL 1.0, at least for Python 3.3? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 01:31:39 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 10 Apr 2012 23:31:39 +0000 Subject: [issue14543] Upgrade OpenSSL on Windows to 0.9.8u In-Reply-To: <1334099869.05.0.692647995835.issue14543@psf.upfronthosting.co.za> Message-ID: <1334100699.8.0.381983553425.issue14543@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, 3.3 already links with openssl-1.0.0a. However, updating to the latest 1.0.x would probably be good. ---------- nosy: +georg.brandl versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 01:38:01 2012 From: report at bugs.python.org (Dino Viehland) Date: Tue, 10 Apr 2012 23:38:01 +0000 Subject: [issue14543] Upgrade OpenSSL on Windows to 0.9.8u In-Reply-To: <1334099869.05.0.692647995835.issue14543@psf.upfronthosting.co.za> Message-ID: <1334101081.25.0.672161580142.issue14543@psf.upfronthosting.co.za> Dino Viehland added the comment: A 1.0 version would be fine w/ me (I tested it with one of those and it worked as well) - I was just thinking a bug fix release might want to stick w/ a bug fix release of OpenSSL too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 01:43:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 10 Apr 2012 23:43:18 +0000 Subject: [issue14543] Upgrade OpenSSL on Windows to 0.9.8u In-Reply-To: <1334101081.25.0.672161580142.issue14543@psf.upfronthosting.co.za> Message-ID: <1334101065.5371.33.camel@localhost.localdomain> Antoine Pitrou added the comment: > A 1.0 version would be fine w/ me (I tested it with one of those and > it worked as well) - I was just thinking a bug fix release might want > to stick w/ a bug fix release of OpenSSL too. Agreed, I was replying to Victor about 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 02:25:16 2012 From: report at bugs.python.org (Glenn Linderman) Date: Wed, 11 Apr 2012 00:25:16 +0000 Subject: [issue10484] http.server.is_cgi fails to handle CGI URLs containing PATH_INFO In-Reply-To: <1290324717.4.0.0270982528857.issue10484@psf.upfronthosting.co.za> Message-ID: <1334103916.32.0.138267378443.issue10484@psf.upfronthosting.co.za> Glenn Linderman added the comment: Senthil, thanks for your work on this. Regarding: I also looked at changes in the patches contained in issue 13893, but I found that those broke behavior or exhibited the security issue again. I'd be curious to know what problems you discovered, since I had hoped I had fixed them all (and know I fixed enough to work in my environment). I'll review your code in the next while, and attempt to include it in mine, and test it in my environment... I really don't want to maintain my own code, but do need functional code... hopefully once the other issues are fixed I can just use released code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 03:11:58 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 11 Apr 2012 01:11:58 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1334106718.21.0.552067223475.issue2377@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, I have fixed test_trace by tweaking the trace module in default. I have decided to follow Antoine's suggestion-by-question and get test_pydoc working before I merge by getting ImportError spruced up in default but pydoc changed in bootstrap_importlib. I am *not* going to try to get registry-based imports working because I don't have a Windows machine and could quite easily break the build. I would rather have a Windows expert add the support. IOW: * Issue #1559549 * Fix pydoc in bootstrap_importlib * Big patch merged into default * ??? * Profit! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 03:13:07 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 11 Apr 2012 01:13:07 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1334106787.41.0.876099912226.issue2377@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- dependencies: +ImportError needs attributes for module and file name _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 03:17:55 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 11 Apr 2012 01:17:55 +0000 Subject: [issue1559549] ImportError needs attributes for module and file name Message-ID: <1334107075.61.0.187992596132.issue1559549@psf.upfronthosting.co.za> Brett Cannon added the comment: This is now officially blocking my importlib bootstrap work (issue #2377), so I have assigned this to myself to get done and I hope to get this committed within a week *without* updating Python/import.c and the requisite tests or pydoc (which I will make part of my merge instead). If Brian beats me to getting this checked in that's great, but otherwise I will get to it myself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 03:57:15 2012 From: report at bugs.python.org (Paul A.) Date: Wed, 11 Apr 2012 01:57:15 +0000 Subject: [issue14540] Crash in Modules/_ctypes/libffi/src/dlmalloc.c on ia64-hp-hpux11.31 In-Reply-To: <1334023876.29.0.692126392594.issue14540@psf.upfronthosting.co.za> Message-ID: <1334109435.63.0.129511427427.issue14540@psf.upfronthosting.co.za> Paul A. added the comment: I'd be more than happy to use my own installation of libffi instead, but it seems the --with-system-ffi configure flag doesn't work. I've also opened a different bug for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 04:05:30 2012 From: report at bugs.python.org (Paul A.) Date: Wed, 11 Apr 2012 02:05:30 +0000 Subject: [issue14527] How to link with an external libffi? In-Reply-To: <1333851935.11.0.629390980004.issue14527@psf.upfronthosting.co.za> Message-ID: <1334109930.42.0.491479337388.issue14527@psf.upfronthosting.co.za> Paul A. added the comment: While this is no solution by any means, I think it'd be better for the scenario to be a fatal configure error. After all, if I say --with-system-ffi, it means I really, really want want to use my own libffi. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 06:46:31 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 11 Apr 2012 04:46:31 +0000 Subject: [issue14544] Limit "global" keyword name conflicts in language spec to those enforced by CPython Message-ID: <1334119591.44.0.0449104949206.issue14544@psf.upfronthosting.co.za> New submission from Nick Coghlan : The language spec currently includes the following paragraph [1]: Names listed in a global statement must not be defined as formal parameters or in a for loop control target, class definition, function definition, or import statement. While the first restriction is real (and enforced by CPython), since formal parameters are explicitly defined as local variables, there's no obvious rationale for the last 4 restrictions (and CPython doesn't enforce any of them). The proposal is that the paragraph be simplified to: Names listed in a global statement must not also be defined as formal function parameters. Attempting to do so raises SyntaxError. The current (incorrect!) CPython implementation detail note will be removed. A similar clarification will also be made in the "nonlocal" statement documentation. [1] http://docs.python.org/dev/reference/simple_stmts.html#the-global-statement ---------- messages: 158005 nosy: ncoghlan priority: normal severity: normal status: open title: Limit "global" keyword name conflicts in language spec to those enforced by CPython type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 06:51:52 2012 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 11 Apr 2012 04:51:52 +0000 Subject: [issue14544] Limit "global" keyword name conflicts in language spec to those enforced by CPython In-Reply-To: <1334119591.44.0.0449104949206.issue14544@psf.upfronthosting.co.za> Message-ID: <1334119912.69.0.350781238844.issue14544@psf.upfronthosting.co.za> Alex Gaynor added the comment: This shouldn't be a problem for PyPy, in fact I'm almost positive that we implement this already (since Django has a test that uses this "feature"). If/when the spec is changed please make sure there are tests for all these cases so we *know* it works though. ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 06:52:28 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 11 Apr 2012 04:52:28 +0000 Subject: [issue14544] Limit "global" keyword name conflicts in language spec to those enforced by CPython In-Reply-To: <1334119591.44.0.0449104949206.issue14544@psf.upfronthosting.co.za> Message-ID: <1334119948.63.0.970553089421.issue14544@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thread link: http://mail.python.org/pipermail/python-ideas/2012-April/014783.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 07:03:36 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 11 Apr 2012 05:03:36 +0000 Subject: [issue14544] Limit "global" keyword name conflicts in language spec to those enforced by CPython In-Reply-To: <1334119591.44.0.0449104949206.issue14544@psf.upfronthosting.co.za> Message-ID: <1334120616.88.0.593328503417.issue14544@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 07:26:11 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 11 Apr 2012 05:26:11 +0000 Subject: [issue14545] html module should not be available in Python 3.1 Message-ID: <1334121971.71.0.628267633735.issue14545@psf.upfronthosting.co.za> New submission from Chris Jerdonek : The Python documentation says that the html module (defining html.escape()) is new in Python 3.2: http://docs.python.org/dev/library/html.html However, it's importable in Python 3.1, but without the escape() function. See below for evidence. This prevents the usual EAFP code from not working: try: # Python 3.2 deprecates cgi.escape() and adds the html module as a replacement. import html except ImportError: import cgi as html > python Python 3.1.4 (default, Apr 10 2012, 21:58:25) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import html >>> html.escape Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'escape' >>> dir(html) ['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__path__'] >>> html.__file__ '/opt/local/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/html/__init__.py' ---------- components: None messages: 158008 nosy: cjerdonek priority: normal severity: normal status: open title: html module should not be available in Python 3.1 type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 07:28:54 2012 From: report at bugs.python.org (Chris Rebert) Date: Wed, 11 Apr 2012 05:28:54 +0000 Subject: [issue14544] Limit "global" keyword name conflicts in language spec to those enforced by CPython In-Reply-To: <1334119591.44.0.0449104949206.issue14544@psf.upfronthosting.co.za> Message-ID: <1334122134.03.0.247677282276.issue14544@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 08:01:21 2012 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 11 Apr 2012 06:01:21 +0000 Subject: [issue14545] html module should not be available in Python 3.1 In-Reply-To: <1334121971.71.0.628267633735.issue14545@psf.upfronthosting.co.za> Message-ID: <1334124081.69.0.648927886112.issue14545@psf.upfronthosting.co.za> Ezio Melotti added the comment: The doc for the html module was added in 5633af590057 (see #2830) and it was previously undocumented even if it was importable. Moving the versionadded under html.escape sounds good to me. As a side note, it would be better to do try: # Python 3.2 deprecates cgi.escape() and adds html.escape() as a replacement. from html import escape except ImportError: from cgi import escape rather than importing the whole cgi module as "html" just to use the escape function. ---------- assignee: -> docs at python components: +Documentation -None keywords: +easy nosy: +docs at python, ezio.melotti stage: -> needs patch versions: +Python 3.2, Python 3.3 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 08:35:23 2012 From: report at bugs.python.org (Glenn Linderman) Date: Wed, 11 Apr 2012 06:35:23 +0000 Subject: [issue10484] http.server.is_cgi fails to handle CGI URLs containing PATH_INFO In-Reply-To: <1290324717.4.0.0270982528857.issue10484@psf.upfronthosting.co.za> Message-ID: <1334126123.72.0.387958713986.issue10484@psf.upfronthosting.co.za> Glenn Linderman added the comment: A minor detail of efficiency: _url_collapse_path_split is used only one place, from is_cgi. _url_collapse_path_split splits the path, and is_cgi now puts it back together. This seems inefficient. Would it not be better for _url_collapse_path_split to be renamed to _url_collapse_path and simply return a single value, the path canonicalized (.. removed)? Then is_cgi would not need to put it back together before taking it apart another way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 08:50:45 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 11 Apr 2012 06:50:45 +0000 Subject: [issue14545] html module should not be available in Python 3.1 In-Reply-To: <1334121971.71.0.628267633735.issue14545@psf.upfronthosting.co.za> Message-ID: <1334127045.13.0.350786543149.issue14545@psf.upfronthosting.co.za> Georg Brandl added the comment: "html" is a package. The "html.parser" module, which was already in 3.0, cannot be importable without a "html" package, so in all 3.x versions there was at least an empty html/__init__.py. That said, I have no objection to Ezio's suggestion. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 09:22:18 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 11 Apr 2012 07:22:18 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334128938.15.0.26055625419.issue14532@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- nosy: +haypo status: open -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 09:22:31 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 11 Apr 2012 07:22:31 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334128951.24.0.555554652857.issue14532@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- status: -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 10:47:28 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 11 Apr 2012 08:47:28 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1334128951.26.0.618416919937.issue14532@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: if response == digest: can be replaced by: if sum(x^y for x, y in itertools.zip_longest(response, digest, fillvalue=256)) == 0: I hope that zip_longest() does not depend too much on response and digest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 11:19:09 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 11 Apr 2012 09:19:09 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za> Message-ID: <1334135949.26.0.642480368783.issue8799@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: A few comments: 1) with cv: make_an_item_available() + cv.notify() 2) one of the benefits of wait_for() is that it automates the tricky timekeeping needed if one wants an somewhat accurate timeout, you may want to mention this specifically. 3) the offending part. I see that you don't want to use the technical terms of spurious wakeups or stolen wakeups. That's ok, but the resulting explanation is somwhat bogus. I suggest the following: The ``while`` loop checking for the application's condition is necessary because :meth:`~Condition.wait` can return after an arbitrary long time, and the condition which prompted the :meth:`~Condition.notify` call may not yet, or no longer, hold true. This is an inherent property of multi-threaded programming and the use of this pattern is essential for the robust use of Condition objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 11:23:38 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Wed, 11 Apr 2012 09:23:38 +0000 Subject: [issue14545] html module should not be available in Python 3.1 In-Reply-To: <1334121971.71.0.628267633735.issue14545@psf.upfronthosting.co.za> Message-ID: <1334136218.27.0.366398968097.issue14545@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Ezio, I appreciate the suggestion/tip. Thanks. Regarding Georg's clarification that '"html" is a package,' I don't know if that was intended to correct my comment, Ezio's comment, the docs, or all of the above. In any case, that point should also be corrected in the docs as the docs currently say about html, "This *module* defines utilities to manipulate HTML." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 11:30:14 2012 From: report at bugs.python.org (Glenn Linderman) Date: Wed, 11 Apr 2012 09:30:14 +0000 Subject: [issue10484] http.server.is_cgi fails to handle CGI URLs containing PATH_INFO In-Reply-To: <1290324717.4.0.0270982528857.issue10484@psf.upfronthosting.co.za> Message-ID: <1334136614.17.0.242823625004.issue10484@psf.upfronthosting.co.za> Glenn Linderman added the comment: I note that there is no test for tail_part == '.'. I suggest adding a couple, such as the following which I added to my local copy for testing of the next item: '/a/b/.': ('/a/b', ''), '/a/b/c/../d/e/../../../../f/../.': ('/', ''), Given your comment that you found bugs in my code, I figured out how to run the tests against my code, and found the bugs. Here is a slightly shorter, more efficient (it cuts 40% off the execution time, see time_test.py), and to me much clearer version of _url_collapse_path_split, and it passes all the tests: def _url_collapse_path_split(path): # Similar to os.path.split(os.path.normpath(path)) but specific to URL # path semantics rather than local operating system semantics. path_parts = path.split('/') head_parts = [] for part in path_parts[:-1]: if part == '..': head_parts.pop() # IndexError if more '..' than prior parts elif part and part != '.': head_parts.append( part ) if path_parts: tail_part = path_parts.pop() if tail_part: if tail_part == '..': head_parts.pop() tail_part = '' elif tail_part == '.': tail_part = '' else: tail_part = '' return ('/' + '/'.join(head_parts), tail_part) ---------- Added file: http://bugs.python.org/file25175/time_test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 11:38:51 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 11 Apr 2012 09:38:51 +0000 Subject: [issue14545] html module should not be available in Python 3.1 In-Reply-To: <1334121971.71.0.628267633735.issue14545@psf.upfronthosting.co.za> Message-ID: <1334137131.8.0.13368758329.issue14545@psf.upfronthosting.co.za> Georg Brandl added the comment: The comment that "html" was a package was not meant as a correction, but as an explanation why it already exists previous to its status as an official "module" in 3.2. No correction to "package"is needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 12:12:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Apr 2012 10:12:20 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1334135949.26.0.642480368783.issue8799@psf.upfronthosting.co.za> Message-ID: <1334138807.3328.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > A few comments: > 1) > with cv: > make_an_item_available() > + cv.notify() Did I forget this? Ow. > 2) one of the benefits of wait_for() is that it automates the tricky > timekeeping needed if one wants an somewhat accurate timeout, you may > want to mention this specifically. Ok. > 3) the offending part. I see that you don't want to use the technical > terms of spurious wakeups or stolen wakeups. That's ok, but the > resulting explanation is somwhat bogus. I suggest the following: > > The ``while`` loop checking for the application's condition is > necessary > because :meth:`~Condition.wait` can return after an arbitrary long > time, and the condition which prompted the :meth:`~Condition.notify` > call may not yet, or no longer, hold true. This is an inherent > property of multi-threaded programming and the use of this pattern is > essential for the robust use of Condition objects. But, once again, "the condition may not yet hold true" is false. However, the rest of the suggestion looks good, thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 12:46:24 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 11 Apr 2012 10:46:24 +0000 Subject: [issue14387] Include\accu.h incompatible with Windows.h In-Reply-To: <1332417184.03.0.15615521555.issue14387@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f91ecbc8bafc by Kristj?n Valur J?nsson in branch '3.2': Issue #14387 : undefine 'small' so that it doesn't clash with Windows headers. http://hg.python.org/cpython/rev/f91ecbc8bafc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 12:50:35 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 11 Apr 2012 10:50:35 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za> Message-ID: <1334141435.67.0.602603936134.issue8799@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: > But, once again, "the condition may not yet hold true" is false. In our current implementation, yes. But it is intentionally left undefined in the specification of the condition variable protocol, for very good reasons. While I'm fine with not mentioning it in the docs, I would be very much against us actually specifying the opposite (that early wakeups never occur) because this will unnecessarily limit our options. Since the while() loop pattern is already recommended because of the "stolen wakeup" problem, leaving the "early/spurious" wakeup behaviour" undefined is wise, since there is nothing to be gained by actually guaranteeing that there will be no early wakeups. This is just good software engineering practice. This is also why we, IMHO, shouldn't rely on this behaviour in the unittests. One should never write tests that depend on unspecified behaviour, again, good engineering practice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 13:00:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Apr 2012 11:00:02 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1334141435.67.0.602603936134.issue8799@psf.upfronthosting.co.za> Message-ID: <1334141668.3328.8.camel@localhost.localdomain> Antoine Pitrou added the comment: Le mercredi 11 avril 2012 ? 10:50 +0000, Kristj?n Valur J?nsson a ?crit : > > But, once again, "the condition may not yet hold true" is false. > In our current implementation, yes. But it is intentionally left > undefined in the specification of the condition variable protocol, for > very good reasons. No, it is not "left undefined". If the documentation doesn't say spurious wakeups may occur, then they are not supposed to occur. Predictable behaviour is a good thing for users. > While I'm fine with not mentioning it in the docs, I would be very > much against us actually specifying the opposite (that early wakeups > never occur) because this will unnecessarily limit our options. Which options? > This is also why we, IMHO, shouldn't rely on this behaviour in the > unittests. Disagreed. Unit tests should definitely protect against the introduction of bugs (willingly or not). And unpredictable behaviour is usually considered a bug. If you think the condition variable specification should be changed, you can always ask for approval on python-dev. But I don't even see the point: you are not demonstrating any *practical* advantage in doing so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 13:15:40 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 11 Apr 2012 11:15:40 +0000 Subject: [issue8536] Support new features of ZLIB 1.2.4 In-Reply-To: <1272302591.08.0.11918516326.issue8536@psf.upfronthosting.co.za> Message-ID: <1334142940.24.0.812601927319.issue8536@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 13:18:18 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 11 Apr 2012 11:18:18 +0000 Subject: [issue1522400] irda socket support Message-ID: <1334143098.93.0.160591510484.issue1522400@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 13:25:59 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 11 Apr 2012 11:25:59 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: > if response == digest: > can be replaced by: > ? ?if sum(x^y for x, y in itertools.zip_longest(response, digest, > fillvalue=256)) == 0: Yeah, sure, but is it useful at all? The digest changes at every connection attempt, so this should not be exploitable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 13:32:43 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 11 Apr 2012 11:32:43 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1334141668.3328.8.camel@localhost.localdomain> Message-ID: Charles-Fran?ois Natali added the comment: [...] > Disagreed. Unit tests should definitely protect against the introduction > of bugs (willingly or not). And unpredictable behaviour is usually > considered a bug. > > If you think the condition variable specification should be changed, you > can always ask for approval on python-dev. But I don't even see the > point: you are not demonstrating any *practical* advantage in doing so. One can imagine, for example, that another implementation (or maybe CPython in a later version) exposes native condition variables on POSIX, instead of emulating them (e.g. what happended for TLS implementation). In that case, we could get spurious wakeups, and code not designed to cope with them would break. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 13:40:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Apr 2012 11:40:33 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: Message-ID: <1334144100.3328.11.camel@localhost.localdomain> Antoine Pitrou added the comment: Le mercredi 11 avril 2012 ? 11:32 +0000, Charles-Fran?ois Natali a ?crit : > One can imagine, for example, that another implementation (or maybe > CPython in a later version) exposes native condition variables on > POSIX, instead of emulating them (e.g. what happended for TLS > implementation). That's right, but spurious wakeups would be a good argument against accepting such an implementation. Or that implementation should be fixed to avoid them. That said, we couldn't use the POSIX implementation anyway, since our API allows the user to choose the type of lock, while POSIX AFAICT would only accept a POSIX mutex (which doesn't have the same semantics as an arbitrary Python lock). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 13:52:35 2012 From: report at bugs.python.org (Yap Sok Ann) Date: Wed, 11 Apr 2012 11:52:35 +0000 Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za> Message-ID: <1334145155.59.0.07128016864.issue7511@psf.upfronthosting.co.za> Yap Sok Ann added the comment: On 64-bit Windows with Visual Studio 2008 Professional, I also need to apply vcvars4.diff to avoid getting the ValueError. Is this something to be expected? ---------- nosy: +sayap _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 13:57:03 2012 From: report at bugs.python.org (Mark Shannon) Date: Wed, 11 Apr 2012 11:57:03 +0000 Subject: [issue14432] Bug in generator if the generator in created in a C thread In-Reply-To: <1332948868.24.0.309034348776.issue14432@psf.upfronthosting.co.za> Message-ID: <1334145423.85.0.448638132959.issue14432@psf.upfronthosting.co.za> Mark Shannon added the comment: Rather than ensuring that f_tstate always points to the current frame, just remove it altogether. Patch attached ---------- nosy: +Mark.Shannon Added file: http://bugs.python.org/file25176/remove_f_tstate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 14:02:29 2012 From: report at bugs.python.org (Bill Jefferson) Date: Wed, 11 Apr 2012 12:02:29 +0000 Subject: [issue14542] reverse() doesn't reverse sort correctly In-Reply-To: <1334094348.56.0.434494052694.issue14542@psf.upfronthosting.co.za> Message-ID: <1334145746.35931.YahooMailNeo@web161904.mail.bf1.yahoo.com> Bill Jefferson added the comment: Eric..... Thanks for answering, but I don't understand the difference between "reversing a list" and "reversing it's current values". If I have a list containing elements: A, B, C, D and reverse the list's current values, I get: D, C, B, A, which is the same as reversing the list. Please explain in more detail. Perhaps you can recommend good reference material. Since sort() sorts a list ascending (and works correctly), shouldn't reverse() sort the list descending? Am I using the wrong function?? I have attached my program: Bill..... #EX38.PY Get listing of all files in a directory #http://stackoverflow.com/questions/237079/how-to-get-file-creation-modification-date-times-in-python # Answer 37 import os, datetime topDir = "C:/BrcmCDs" dateFirst = True # put dates before file names # DateFirst = False # put file names before dates def modDate(fileN): # returns a 10-place date string ??? t = os.path.getmtime(directory+"/"+fileN) ??? return str(datetime.datetime.fromtimestamp(t))[0:10] ??? for directory, dirnames, filenames in os.walk(topDir): ??? outList = [] ??? print "Directory: ", directory ??? print ??? for fileA in filenames: ??????? if (fileA[0:10] == "B57IBMCD_T" and ??????????? fileA[-4:] == ".zip"): ??????????? dateString = modDate(fileA) ??????????? if dateFirst: ?????????????? fileString = dateString + " " + fileA ??????????? else: ?????????????? fileString = fileA + " " + dateString ??????????? ??????????? outList.append(fileString) ??????????? outList.sort() # sort the file list, ascending # outList.reverse() # reverse the file list, desending ??????? print outList #show all files # now save list to a file: # https://bbs.archlinux.org/viewtopic.php?id=75839 f = open("fileList.TXT", "w") f.write("\n".join(map(lambda x: str(x), outList))) f.close() ? Regards from: William Jefferson Photography 514 Daniels St., #211 Raleigh, NC 27605 Cell Phone: (919) 931-6681 EMail: shaggers3 at yahoo.com Brides & Weddings: http://www.WilliamJeffersonPhotography.com Special Events: http://www.DancingLight.org ________________________________ From: Eric V. Smith To: shaggers3 at yahoo.com Sent: Tuesday, April 10, 2012 5:45 PM Subject: [issue14542] reverse() doesn't reverse sort correctly Eric V. Smith added the comment: list.reverse() does not reverse a list, it reverses its current values. Help on built-in function reverse: reverse(...) ? ? L.reverse() -- reverse *IN PLACE* >>> ---------- nosy: +eric.smith resolution:? -> invalid stage:? -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 14:06:26 2012 From: report at bugs.python.org (Mark Shannon) Date: Wed, 11 Apr 2012 12:06:26 +0000 Subject: [issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate In-Reply-To: <1327767887.13.0.0676848614688.issue13897@psf.upfronthosting.co.za> Message-ID: <1334145986.03.0.466350698578.issue13897@psf.upfronthosting.co.za> Mark Shannon added the comment: According to PEP 384 (Defining a Stable ABI) the thread state object is opaque, so we should be free to add or remove fields. Nevertheless, I have added a new patch that simply moves the f_exc... fields from the frame object to the generator. It is not as efficient as the first patch, but at least it moves fields relevant only to generators into the generator object. ---------- Added file: http://bugs.python.org/file25177/exc_info2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 14:11:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Apr 2012 12:11:02 +0000 Subject: [issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate In-Reply-To: <1334145986.03.0.466350698578.issue13897@psf.upfronthosting.co.za> Message-ID: <1334145929.3328.13.camel@localhost.localdomain> Antoine Pitrou added the comment: > According to PEP 384 (Defining a Stable ABI) the thread state object > is opaque, so we should be free to add or remove fields. Mmh, be aware the stable ABI is only a restricted part of the official API. There are APIs which are not part of the stable ABI, but are still public and officially supported. That said, I agree the thread state *structure* shouldn't be part of the official API. If necessary, we can provide accessors for some of its members. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 14:28:56 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 11 Apr 2012 12:28:56 +0000 Subject: [issue14542] reverse() doesn't reverse sort correctly In-Reply-To: <1334092948.92.0.355966941096.issue14542@psf.upfronthosting.co.za> Message-ID: <1334147336.74.0.0574888372172.issue14542@psf.upfronthosting.co.za> Mark Dickinson added the comment: Bill, list.reverse doesn't do any *sorting* at all; it merely *reverses* the list contents. >>> x = [1, 3, 4, 2] >>> x.reverse() >>> x [2, 4, 3, 1] If you want to do a reverse sort, you can either first sort normally and then reverse the result, or (easier) use the 'reverse' keyword argument to the list.sort method, as follows: >>> x = [1, 3, 4, 2] >>> x.sort(reverse=True) >>> x [4, 3, 2, 1] I suspect Eric meant to write "does not reverse sort" instead of "does not reverse". ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 15:12:23 2012 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 11 Apr 2012 13:12:23 +0000 Subject: [issue14452] SysLogHandler sends invalid messages when using unicode In-Reply-To: <1333105941.84.0.159307303218.issue14452@psf.upfronthosting.co.za> Message-ID: <1334149943.11.0.215406763651.issue14452@psf.upfronthosting.co.za> Vinay Sajip added the comment: I have a possible suggestion about how to resolve this issue: The SysLogHandler will not do BOM insertion unless the message is Unicode. If it is Unicode, it will add the attribute 'UTF8BOM' to the LogRecord, with the value u'\ufeff'. The record will then be formatted; if the format string contains the UTF8BOM placeholder, it will be replaced with the value u'\ufeff', which, when encoded, results in the UTF-8 BOM value '\xef\xbb\xbf'. The user of the format string is responsible for ensuring that: 1. If there's no UTF8BOM placeholder in the format string, everything in the formatted result must always encode to plain ASCII when encoded using UTF-8. 2. If there is a UTF8BOM placeholder in the format string, everything in the formatted result prior to the placeholder must always encode to plain ASCII when encoded using UTF-8. The stuff following can, of course, be free of that restriction. 3. The end result of encoding should be a prefix which is bytes of pure ASCII, then the BOM (if the placeholder is present in the format string), then bytes of UTF-8 encoded Unicode. In any case, a Unicode string will be encoded using UTF-8. If no UTF8BOM placeholder was present, no BOM will be; the message can be considered to just be a set of octets, which just happens to be UTF-8 encoded Unicode. If the placeholder was present, the BOM should appear at the appropriate place to comply with RFC 5424. On 3.2, the message will always be Unicode, and the above processing will take place (whereas on 2.x it will be conditional on the type of the formatted message string being Unicode). This seems to provide a resolution to the issue which can be solved without API changes, and with changes to the format string if BOM insertion is needed. With no UTF8BOM placeholder, the BOM will simply not be inserted. Can you comment on this suggestion? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 15:30:52 2012 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 11 Apr 2012 13:30:52 +0000 Subject: [issue14542] reverse() doesn't reverse sort correctly In-Reply-To: <1334092948.92.0.355966941096.issue14542@psf.upfronthosting.co.za> Message-ID: <1334151052.73.0.683395995656.issue14542@psf.upfronthosting.co.za> Eric V. Smith added the comment: Thanks, Mark. Indeed, my answer as written is meaningless. I meant it doesn't sort in reverse, it just reverses. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 15:39:23 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Apr 2012 13:39:23 +0000 Subject: [issue1522400] irda socket support Message-ID: <1334151563.61.0.23956352589.issue1522400@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 15:51:58 2012 From: report at bugs.python.org (Jon Oberheide) Date: Wed, 11 Apr 2012 13:51:58 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334152318.9.0.697823745516.issue14532@psf.upfronthosting.co.za> Jon Oberheide added the comment: Ah yeah, I suppose it's not be exploitable in this case due to the challenge nonce. However, it might still be a good thing to fix for to set an example for other hmac module users (internal or external) that might not have the same situation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 15:53:32 2012 From: report at bugs.python.org (Jon Oberheide) Date: Wed, 11 Apr 2012 13:53:32 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334152412.0.0.19027939581.issue14532@psf.upfronthosting.co.za> Jon Oberheide added the comment: In fact, it'd probably be useful to have a time_independenct_comparison() helper function somewhere in general. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 16:18:22 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 11 Apr 2012 14:18:22 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1334152412.0.0.19027939581.issue14532@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: I don't see the point of obfuscating the code to avoid a vulnerability to which the code is not even vulnerable, just so that it can be used as example... There are *thousands* of ways to introduce security flaws, and the Python code base if not a security handbook ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 16:27:48 2012 From: report at bugs.python.org (Jon Oberheide) Date: Wed, 11 Apr 2012 14:27:48 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334154468.6.0.277890641342.issue14532@psf.upfronthosting.co.za> Jon Oberheide added the comment: You call it obfuscating, I call it security correctness and developer education. Tomayto, tomahto. ;-) Anywho, your call of course, feel free to close. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 16:29:36 2012 From: report at bugs.python.org (Carton He) Date: Wed, 11 Apr 2012 14:29:36 +0000 Subject: [issue14546] lll.py can't handle multiple parameters correctly Message-ID: <1334154576.79.0.440664410533.issue14546@psf.upfronthosting.co.za> New submission from Carton He : Space errors in calling of lll(arg) of main() cause it only applies to the last parameter instead of all parameters. Patch attached for Python 3.1 ---------- components: Demos and Tools files: lll.py.patch keywords: patch messages: 158036 nosy: carton priority: normal severity: normal status: open title: lll.py can't handle multiple parameters correctly versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file25178/lll.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 16:36:46 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 11 Apr 2012 14:36:46 +0000 Subject: [issue14546] lll.py can't handle multiple parameters correctly In-Reply-To: <1334154576.79.0.440664410533.issue14546@psf.upfronthosting.co.za> Message-ID: <1334155006.56.0.373031099715.issue14546@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the patch. Do you have any interest in writing a test for this? Tests for tools go in Lib/test/test_tools.py. ---------- nosy: +r.david.murray stage: -> test needed type: -> behavior versions: +Python 3.2, Python 3.3 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 16:41:04 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 11 Apr 2012 14:41:04 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1334154468.6.0.277890641342.issue14532@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > You call it obfuscating, I call it security correctness and developer education. Tomayto, tomahto. ;-) Well, I'd be prompt to changing to a more robust digest check algorithm if the current one had a flaw, but AFAICT, it's not the case (but I'm no security expert). > Anywho, your call of course, feel free to close. Being a core Python developer doesn't mean I'm right ;-) I just don't think that "set an example for other hmac module users" is a good reason on its own to complicate the code, which is currently readable and - AFICT - safe (complexity usually introduces bugs). Furthermore, I somehow doubt that hmac users will go and have a look at the multiprocessing connection challenge code when looking for an example. One thing that could definitely be interesting is to look through the code base and example to see if a similar - but vulnerable - pattern is used, and fix such occurrences. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 16:42:49 2012 From: report at bugs.python.org (Johannes Buchner) Date: Wed, 11 Apr 2012 14:42:49 +0000 Subject: [issue14547] Python symlink to script behaves unexpectedly Message-ID: <1334155369.29.0.554259242167.issue14547@psf.upfronthosting.co.za> New submission from Johannes Buchner : If I have a script foo/bar.py import baz and create a symlink to it, called barhere.py ln -s foo/bar.py barhere.py when I run it, it behaves unexpectedly, specifically it behaves differently than if I had copied it here. It prefers to import baz from foo/baz, not from the current folder. Apparently Python (2.7.2-r3) handles symlinks differently than just looking at the content (everything is a file philosophy in UNIX). ---------- messages: 158039 nosy: j13r priority: normal severity: normal status: open title: Python symlink to script behaves unexpectedly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 16:53:02 2012 From: report at bugs.python.org (sbt) Date: Wed, 11 Apr 2012 14:53:02 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334155982.28.0.395259503794.issue14532@psf.upfronthosting.co.za> sbt added the comment: I think it would be reasonable to add a safe comparison function to hmac. Its documentation could explain briefly when it would be preferable to "==". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 17:06:06 2012 From: report at bugs.python.org (Bill Jefferson) Date: Wed, 11 Apr 2012 15:06:06 +0000 Subject: [issue14542] reverse() doesn't reverse sort correctly In-Reply-To: <1334147336.74.0.0574888372172.issue14542@psf.upfronthosting.co.za> Message-ID: <1334156764.4104.YahooMailNeo@web161906.mail.bf1.yahoo.com> Bill Jefferson added the comment: Mark and Eric...... Wonderful! I got it now. I used x.sort(reverse=True) and x.sort(reverse=False) and it works just fine. Thanks for your help. Bill...... ? Regards from: William Jefferson Photography 514 Daniels St., #211 Raleigh, NC 27605 Cell Phone: (919) 931-6681 EMail: shaggers3 at yahoo.com Brides & Weddings: http://www.WilliamJeffersonPhotography.com Special Events: http://www.DancingLight.org ________________________________ From: Mark Dickinson To: shaggers3 at yahoo.com Sent: Wednesday, April 11, 2012 8:28 AM Subject: [issue14542] reverse() doesn't reverse sort correctly Mark Dickinson added the comment: Bill, list.reverse doesn't do any *sorting* at all;? it merely *reverses* the list contents. [2, 4, 3, 1] If you want to do a reverse sort, you can either first sort normally and then reverse the result, or (easier) use the 'reverse' keyword argument to the list.sort method, as follows: [4, 3, 2, 1] I suspect Eric meant to write "does not reverse sort" instead of "does not reverse". ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 17:06:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 11 Apr 2012 15:06:09 +0000 Subject: [issue14341] sporadic (?) test_urllib2 failures In-Reply-To: <1331943969.2.0.17966534502.issue14341@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 751c7b81f6ee by Senthil Kumaran in branch 'default': use assertWarns instead of check_warnings - Issue14341 http://hg.python.org/cpython/rev/751c7b81f6ee ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 17:11:00 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 11 Apr 2012 15:11:00 +0000 Subject: [issue14341] sporadic (?) test_urllib2 failures In-Reply-To: <1331943969.2.0.17966534502.issue14341@psf.upfronthosting.co.za> Message-ID: <1334157060.99.0.833829056568.issue14341@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Hi Antoine, I saw that check_warnings was commonly used ( and perhaps I had used to earlier without any problems) and overlooked assertWarns. But I think, it is good to remove support.check_warnings dependency here and just use assertWarnings. Let me see if this squashes that sporadic failures in builldbots. I think, the test_http_cookiejar and test_urllib2 dependency (if any) should also be looked at irrespective of this. I shall check that. Thanks, Senthil Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 17:11:08 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 11 Apr 2012 15:11:08 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334157068.22.0.574034998316.issue14532@psf.upfronthosting.co.za> R. David Murray added the comment: It would also be reasonable to add a comment to the code mentioning why this particular (security) comparison is *not* vulnerable to a timing attack, which would serve the education purpose if someone does look at the code. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 17:29:27 2012 From: report at bugs.python.org (Jon Oberheide) Date: Wed, 11 Apr 2012 15:29:27 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334158167.22.0.330276758065.issue14532@psf.upfronthosting.co.za> Jon Oberheide added the comment: > One thing that could definitely be interesting is to look through the > code base and example to see if a similar - but vulnerable - pattern > is used, and fix such occurrences. Based on some quick greps, I didn't see many internal users of hmac and the current users don't seem to use it in a scenario that would be at risk (eg. attacker supplied digest compared against an expected digest). Given that this issue has affected a lot of security-sensitive third-party code (keyczar, openid providers, almost every python web service that implements "secure cookies" [1] or other HMAC-based REST API signatures), I do like the idea of adding a warning in the relevant documentation as sbt proposed. The only reason I'd recommend _not_ putting a time_independent_comparison() function in the hmac module is that it's not really HMAC-specific. In practice, any fixed-length secrets should be compared in a time-independent manner. It just happens that HMAC verification is a pretty common case for this vulnerable construct. :-) [1] https://github.com/facebook/tornado/blob/master/tornado/web.py#L1981 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 17:41:51 2012 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 11 Apr 2012 15:41:51 +0000 Subject: [issue14452] SysLogHandler sends invalid messages when using unicode In-Reply-To: <1333105941.84.0.159307303218.issue14452@psf.upfronthosting.co.za> Message-ID: <1334158911.23.0.810656051391.issue14452@psf.upfronthosting.co.za> Guido van Rossum added the comment: But why on earth would one want a BOM in UTF-8-encoded data? It is byte-order independent! ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 17:46:33 2012 From: report at bugs.python.org (Tim Golden) Date: Wed, 11 Apr 2012 15:46:33 +0000 Subject: [issue14452] SysLogHandler sends invalid messages when using unicode In-Reply-To: <1334158911.23.0.810656051391.issue14452@psf.upfronthosting.co.za> Message-ID: <4F85A6E4.4020702@timgolden.me.uk> Tim Golden added the comment: It's used by some systems (Windows Notepad does this if you save as UTF8) to indicate that the byte stream *is* UTF8-encoded. It's not so much a BOM as a magic cookie. I can't speak for syslog, I'm afraid TJG ---------- nosy: +tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 17:52:05 2012 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 11 Apr 2012 15:52:05 +0000 Subject: [issue14452] SysLogHandler sends invalid messages when using unicode In-Reply-To: <1333105941.84.0.159307303218.issue14452@psf.upfronthosting.co.za> Message-ID: <1334159525.38.0.897541009404.issue14452@psf.upfronthosting.co.za> Vinay Sajip added the comment: > But why on earth would one want a BOM in UTF-8-encoded data? It is byte-order independent! Lord only knows, but the RFC does call for it - msg157572 has an actual excerpt from RFC 5424. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 18:32:32 2012 From: report at bugs.python.org (sbt) Date: Wed, 11 Apr 2012 16:32:32 +0000 Subject: [issue14548] garbage collection just after multiprocessing's fork causes exceptions Message-ID: <1334161952.16.0.996503370024.issue14548@psf.upfronthosting.co.za> New submission from sbt : When running test_multiprocessing on Linux I occasionally see a stream of errors caused by ignored weakref callbacks: Exception AssertionError: AssertionError() in ignored These do not cause the unittests to fail. Finalizers from the parent process are supposed to be cleared after the fork. But if a garbage collection before that then Finalizer callbacks can be run in the "wrong" process. Disabling gc during fork seems to prevent the errors. Or maybe the Finalizer should record the pid of the process which created it and only invoke the callback if it matches the current pid. (Compare Issure 1336 conscerning subprocess.) ---------- messages: 158049 nosy: sbt priority: normal severity: normal status: open title: garbage collection just after multiprocessing's fork causes exceptions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 18:36:49 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 11 Apr 2012 16:36:49 +0000 Subject: [issue14545] html module should not be available in Python 3.1 In-Reply-To: <1334121971.71.0.628267633735.issue14545@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2776ccf003cc by Georg Brandl in branch '3.2': Closes #14545: make clearer what was added. http://hg.python.org/cpython/rev/2776ccf003cc New changeset f5f8a7fd881c by Georg Brandl in branch 'default': #14545: merge 3.2 http://hg.python.org/cpython/rev/f5f8a7fd881c ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 18:40:38 2012 From: report at bugs.python.org (Mark Shannon) Date: Wed, 11 Apr 2012 16:40:38 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1334162438.76.0.154062476358.issue13903@psf.upfronthosting.co.za> Mark Shannon added the comment: I don't really understand your objection to changing the method-cache size. As I said, I can remove the change, but that will cause the performance regression that Antoine noticed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 18:40:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Apr 2012 16:40:48 +0000 Subject: [issue14548] garbage collection just after multiprocessing's fork causes exceptions In-Reply-To: <1334161952.16.0.996503370024.issue14548@psf.upfronthosting.co.za> Message-ID: <1334162448.77.0.475070603374.issue14548@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Disabling gc during fork seems to prevent the errors. Sounds reasonable to me. ---------- components: +Library (Lib) nosy: +neologix, pitrou type: -> behavior versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 18:42:42 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 11 Apr 2012 16:42:42 +0000 Subject: [issue14549] Recursive inclusion of packages Message-ID: <1334162562.68.0.805161870888.issue14549@psf.upfronthosting.co.za> New submission from ?ric Araujo : For projects with more than a few packages, it is tedious to list all subpackages manually in setup.cfg. There was once a find_packages in distutils2.util (copied from distribute), but when we moved away from setup.py it was removed (I don?t remember all the details). A new field would be best if we could find a good name, or we could have special syntax in the existing packages field (like ?packages = distutils2.*?). ---------- assignee: eric.araujo components: Distutils2 messages: 158053 nosy: alexis, eric.araujo, erik.bray, tarek priority: normal severity: normal stage: needs patch status: open title: Recursive inclusion of packages type: enhancement versions: 3rd party, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 19:07:17 2012 From: report at bugs.python.org (Nadeem Vawda) Date: Wed, 11 Apr 2012 17:07:17 +0000 Subject: [issue14548] garbage collection just after multiprocessing's fork causes exceptions In-Reply-To: <1334161952.16.0.996503370024.issue14548@psf.upfronthosting.co.za> Message-ID: <1334164037.08.0.825465442243.issue14548@psf.upfronthosting.co.za> Changes by Nadeem Vawda : ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 19:09:11 2012 From: report at bugs.python.org (Erik Bray) Date: Wed, 11 Apr 2012 17:09:11 +0000 Subject: [issue14549] Recursive inclusion of packages In-Reply-To: <1334162562.68.0.805161870888.issue14549@psf.upfronthosting.co.za> Message-ID: <1334164151.15.0.833509357068.issue14549@psf.upfronthosting.co.za> Erik Bray added the comment: +1 for the wildcard syntax. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 19:13:36 2012 From: report at bugs.python.org (Erik Bray) Date: Wed, 11 Apr 2012 17:13:36 +0000 Subject: [issue14549] Recursive inclusion of packages In-Reply-To: <1334162562.68.0.805161870888.issue14549@psf.upfronthosting.co.za> Message-ID: <1334164416.25.0.393908195106.issue14549@psf.upfronthosting.co.za> Erik Bray added the comment: Potential downside: Say I have foo, foo.bar, and foo.tests. I want to install foo and foo.bar, but not foo.tests. Then I have to manually list all the packages I do want: packages = foo foo.bar That's fine, but one nice thing about find_packages is that it had an optional exclude argument. So maybe in addition to the wildcard syntax it couldn't hurt to add an exclude-packages option? I don't think that would be too complicated. Something similar for extension module sources would also be desirable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 19:17:50 2012 From: report at bugs.python.org (Craig Sawyer) Date: Wed, 11 Apr 2012 17:17:50 +0000 Subject: [issue14550] os.path.abspath() returns physical path, not logical path. Message-ID: <1334164670.66.0.0156847857752.issue14550@psf.upfronthosting.co.za> New submission from Craig Sawyer : we have os.path.abspath() and os.path.realpath(). the difference according to the documentation is realpath() returns the physical path (i.e. no symlinks in the path). while abspath() uses getcwd() but because of POSIX.1-2008 (IEEE Std 1003.1-2008) says os.getcwd() returns without symbolic links as well, so os.path.abspath() == os.path.realpath() near as I can tell. I think os.path.abspath() should return a logical path(i.e. one with symlinks). The only solution I know of is to getenv('PWD') except that is not guaranteed to be around in POSIX (some BSD's don't offer PWD I understand). The other option is to ask /bin/pwd which is part of the POSIX standard. Anyways, I couldn't find a previous bug around this issue, but I think there should be a way in the standard library to get a logical path, as well as a realpath(). ---------- components: None messages: 158056 nosy: csawyer-yumaed priority: normal severity: normal status: open title: os.path.abspath() returns physical path, not logical path. type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 19:21:58 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 11 Apr 2012 17:21:58 +0000 Subject: [issue14547] Python symlink to script behaves unexpectedly In-Reply-To: <1334155369.29.0.554259242167.issue14547@psf.upfronthosting.co.za> Message-ID: <1334164918.15.0.131250065583.issue14547@psf.upfronthosting.co.za> R. David Murray added the comment: The content of a symbolic symlink is a symbolic reference to another location in the file system. If you had used a hard link it would certainly work as you expected. The behavior with respect to symbolic links ought to be documented here: http://docs.python.org/using/cmdline.html but doesn't seem to be. ---------- nosy: +ncoghlan, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 19:22:14 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Apr 2012 17:22:14 +0000 Subject: [issue14550] os.path.abspath() returns physical path, not logical path. In-Reply-To: <1334164670.66.0.0156847857752.issue14550@psf.upfronthosting.co.za> Message-ID: <1334164934.74.0.317040099659.issue14550@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > while abspath() uses getcwd() but because of POSIX.1-2008 (IEEE Std > 1003.1-2008) says os.getcwd() returns without symbolic links as well, > so os.path.abspath() == os.path.realpath() near as I can tell. Just because getcwd() doesn't contain any symbolic links doesn't mean the rest of the path is stripped of all symlinks. > I think there should be a way in the standard library to get a logical > path, as well as a realpath(). This doesn't make sense. There could be an arbitrary number of "logical" paths pointing to a single physical one. Which one should Python choose? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 19:33:10 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 11 Apr 2012 17:33:10 +0000 Subject: [issue14549] Recursive inclusion of packages In-Reply-To: <1334162562.68.0.805161870888.issue14549@psf.upfronthosting.co.za> Message-ID: <1334165590.58.0.985527003724.issue14549@psf.upfronthosting.co.za> ?ric Araujo added the comment: IMO the best behavior would be to always recurse and have an option to exclude specific submodules. When the Django devs want to package their code, they think about a Python package named django, docs and scripts, not about django, django.views, django.http, etc. I proposed glob syntax or a new key to be conservative, but now I?ll add a third proposal: packages = foo packages-exclude = foo.spam For a package foo with subpackages ham and spam, this would get foo and foo.ham. Note that this was discussed on the fellowship ML two years ago but I don?t have the time to re-read the thread now. (Why is it not named exclude-packages? 1) you can exclude single-file modules too with this option 2) it makes it clear that it?s a ?sub-option? of packages) About extension modules sources: good idea, but it should be its own feature request. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 19:33:37 2012 From: report at bugs.python.org (Craig Sawyer) Date: Wed, 11 Apr 2012 17:33:37 +0000 Subject: [issue14550] os.path.abspath() returns physical path, not logical path. In-Reply-To: <1334164670.66.0.0156847857752.issue14550@psf.upfronthosting.co.za> Message-ID: <1334165617.65.0.879412160031.issue14550@psf.upfronthosting.co.za> Craig Sawyer added the comment: Antoine, I see your point about getcwd() not having symlinks, doesn't mean any path outside of getcwd() might have symlinks, and I agree this is true. I apologize. As for which one to choose, it should choose based on PWD (i.e. the current working directory's parent directories). I'd love to see something like os.path.abspath(path, logical=True) which would use PWD instead of getcwd() to get the current working directories path. i.e. symlinks are honored within the current path. From a language perspective this probably means needing os.getpwd() or something similar, that would return the pwd information. I know pwd isn't always guaranteed to be around, so the failsafe should be to return getcwd() in that case, just like os.path.abspath() does now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 19:39:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Apr 2012 17:39:25 +0000 Subject: [issue14550] os.path.abspath() should have an option to use PWD In-Reply-To: <1334164670.66.0.0156847857752.issue14550@psf.upfronthosting.co.za> Message-ID: <1334165965.3.0.340819604727.issue14550@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, reformulating the title a bit. ---------- components: +Library (Lib) -None title: os.path.abspath() returns physical path, not logical path. -> os.path.abspath() should have an option to use PWD versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 19:44:28 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Apr 2012 17:44:28 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za> Message-ID: <1334166268.98.0.183101440397.issue8799@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, doc improved in 9d4109af8f3b. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 19:48:07 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 11 Apr 2012 17:48:07 +0000 Subject: [issue14515] tempfile.TemporaryDirectory documented as returning object but returns name In-Reply-To: <1333678068.19.0.790451967958.issue14515@psf.upfronthosting.co.za> Message-ID: <1334166487.84.0.640101436272.issue14515@psf.upfronthosting.co.za> R. David Murray added the comment: I misread the docs. They aren't wrong, but it is still the case that they don't mention that the directory name is what you get on entry to the context, which is what led to my confusion. Here's a patch. ---------- keywords: +patch nosy: +ncoghlan Added file: http://bugs.python.org/file25179/tempdir-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 19:50:06 2012 From: report at bugs.python.org (sbt) Date: Wed, 11 Apr 2012 17:50:06 +0000 Subject: [issue14548] garbage collection just after multiprocessing's fork causes exceptions In-Reply-To: <1334161952.16.0.996503370024.issue14548@psf.upfronthosting.co.za> Message-ID: <1334166606.98.0.35513676805.issue14548@psf.upfronthosting.co.za> sbt added the comment: Patch to disable gc. ---------- keywords: +patch Added file: http://bugs.python.org/file25180/mp_disable_gc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 20:22:24 2012 From: report at bugs.python.org (sbt) Date: Wed, 11 Apr 2012 18:22:24 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1334168544.43.0.938319524672.issue4892@psf.upfronthosting.co.za> sbt added the comment: The last patch did not work on Unix. Here is a new version where the reduction functions are automatically registered, so allow_connection_pickling() is redundant. ---------- Added file: http://bugs.python.org/file25181/mp_pickle_conn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 20:28:31 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 11 Apr 2012 18:28:31 +0000 Subject: [issue14551] imp.load_source docs removed from python3 docs...is this correct? Message-ID: <1334168911.32.0.490760920072.issue14551@psf.upfronthosting.co.za> New submission from R. David Murray : This was removed in 2cf7bb2bbfb8 along with a bunch of other functions. Yet in issue 13959 Brett mentions needing to implement it. I don't see any replacement for its functionality in importlib, so I would think it would be a function we would want to keep. It certainly still exists, and I'm sure many people are using it. ---------- messages: 158066 nosy: brett.cannon, pitrou, r.david.murray priority: normal severity: normal status: open title: imp.load_source docs removed from python3 docs...is this correct? type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 20:37:44 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 11 Apr 2012 18:37:44 +0000 Subject: [issue10484] http.server.is_cgi fails to handle CGI URLs containing PATH_INFO In-Reply-To: <1290324717.4.0.0270982528857.issue10484@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset c67efb8ffca4 by Senthil Kumaran in branch '2.7': Issue 10484 - Incorporate improvements to CGI module - Suggested by Glenn Linderman. Refactor code and tests http://hg.python.org/cpython/rev/c67efb8ffca4 New changeset fc001124a3ee by Senthil Kumaran in branch '3.2': 3.2 - Issue 10484 - Incorporate improvements to CGI module - Suggested by Glenn Linderman. Refactor code and tests http://hg.python.org/cpython/rev/fc001124a3ee New changeset 23f648d7053b by Senthil Kumaran in branch 'default': merge to default - Issue 10484 - Incorporate improvements to CGI module - Suggested by Glenn Linderman. Refactor code and tests http://hg.python.org/cpython/rev/23f648d7053b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 20:39:11 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 11 Apr 2012 18:39:11 +0000 Subject: [issue10484] http.server.is_cgi fails to handle CGI URLs containing PATH_INFO In-Reply-To: <1290324717.4.0.0270982528857.issue10484@psf.upfronthosting.co.za> Message-ID: <1334169551.0.0.0260241885089.issue10484@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Hello Glenn, Your suggestions were valid. I have made those changes in the code. Thanks! I think, we can close this bug now and move over to others. Thanks, Senthil ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 21:17:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 11 Apr 2012 19:17:52 +0000 Subject: [issue14508] gprof2html is broken In-Reply-To: <1333630868.14.0.473747405241.issue14508@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 4d603d6782db by R David Murray in branch '3.2': #14508: make gprof2html script runnable under python3 http://hg.python.org/cpython/rev/4d603d6782db New changeset 73fba223c0a5 by R David Murray in branch 'default': #14508: make gprof2html script runnable under python3 http://hg.python.org/cpython/rev/73fba223c0a5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 21:20:59 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 11 Apr 2012 19:20:59 +0000 Subject: [issue14508] gprof2html is broken In-Reply-To: <1333630868.14.0.473747405241.issue14508@psf.upfronthosting.co.za> Message-ID: <1334172059.35.0.0979209988461.issue14508@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the patch. I don't think you ran the test though, since it didn't pass, and there was a mistake in your patch :) I had to change the test considerably, and only applied the test part on 3.3 since I used mock. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 22:27:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Apr 2012 20:27:41 +0000 Subject: [issue14548] garbage collection just after multiprocessing's fork causes exceptions In-Reply-To: <1334161952.16.0.996503370024.issue14548@psf.upfronthosting.co.za> Message-ID: <1334176061.34.0.532449046094.issue14548@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Shouldn't there be a try..finally, in case os.fork() fails? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 22:36:44 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Apr 2012 20:36:44 +0000 Subject: [issue14551] imp.load_source docs removed from python3 docs...is this correct? In-Reply-To: <1334168911.32.0.490760920072.issue14551@psf.upfronthosting.co.za> Message-ID: <1334176604.21.0.263464131015.issue14551@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hmm, yes, I don't remember exactly why, but it seems they were deprecated ("obsolete"), so it sounds reasonable to un-document them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 22:45:17 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 11 Apr 2012 20:45:17 +0000 Subject: [issue14444] Virtualenv not portable from Python 2.7.2 to 2.7.3 (os.urandom missing) In-Reply-To: <1333039292.27.0.93471346907.issue14444@psf.upfronthosting.co.za> Message-ID: <1334177117.06.0.428118518928.issue14444@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Closing, now that we've released finals. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 22:56:33 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 11 Apr 2012 20:56:33 +0000 Subject: [issue14551] imp.load_source docs removed from python3 docs...is this correct? In-Reply-To: <1334168911.32.0.490760920072.issue14551@psf.upfronthosting.co.za> Message-ID: <1334177793.27.0.633500286324.issue14551@psf.upfronthosting.co.za> R. David Murray added the comment: OK, the text at the start of the section, that I didn't notice in the 2.7 docs, says they are obsolete and replaced by find_module and import_module. But load_source is much more convenient, so I for one am not going to remove my use of it in the tests I just checked in. Someone who wants to actually remove load_source can fix them :) ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 23:18:57 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 11 Apr 2012 21:18:57 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1334158167.22.0.330276758065.issue14532@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Given that this issue has affected a lot of security-sensitive third-party code (keyczar, openid providers, almost every python web service that implements "secure cookies" [1] or other HMAC-based REST API signatures), I do like the idea of adding a warning in the relevant documentation as sbt proposed. This does sound reasonable, along with the addition of a comparison function immune to timing attacks to the hmac module (as noted, it's not specific to hmac, but it looks like a resonable place to add it). Would you like to submit a patch (new comparison function with documentation and test)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 23:23:30 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 11 Apr 2012 21:23:30 +0000 Subject: [issue8799] Hang in lib/test/test_threading.py In-Reply-To: <1334166268.98.0.183101440397.issue8799@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Ok, doc improved in 9d4109af8f3b. LGTM. Kristj?n, how about updating your patch to only fix the original problem you spotted (notify() called before wait()), then we can see the remaining parts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 23:25:11 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 11 Apr 2012 21:25:11 +0000 Subject: [issue14540] Crash in Modules/_ctypes/libffi/src/dlmalloc.c on ia64-hp-hpux11.31 In-Reply-To: <1334109435.63.0.129511427427.issue14540@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I think it's bundled with our copy of libffi. i'm not familiar - at all - with libffi. But does it really need a bundled malloc() implementation? > I'd be more than happy to use my own installation of libffi instead, but it seems the --with-system-ffi configure flag doesn't work. ?I've also opened a different bug for that. So, is the stack trace complete? Is it really generated by the python executable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 23:32:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Apr 2012 21:32:41 +0000 Subject: [issue14540] Crash in Modules/_ctypes/libffi/src/dlmalloc.c on ia64-hp-hpux11.31 In-Reply-To: Message-ID: <1334179916.3328.57.camel@localhost.localdomain> Antoine Pitrou added the comment: > > I think it's bundled with our copy of libffi. > > i'm not familiar - at all - with libffi. > But does it really need a bundled malloc() implementation? Well, the upstream libffi includes dlmalloc.c, so I guess it somehow needs it (perhaps only on certain platforms). Don't ask me why :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 23:35:55 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Wed, 11 Apr 2012 21:35:55 +0000 Subject: [issue14552] test module: remove repetition Message-ID: <1334180155.46.0.58029796452.issue14552@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- assignee: docs at python components: Documentation files: repetition.diff keywords: patch nosy: docs at python, tshepang priority: normal severity: normal status: open title: test module: remove repetition Added file: http://bugs.python.org/file25182/repetition.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 23:38:40 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Wed, 11 Apr 2012 21:38:40 +0000 Subject: [issue14553] http.server module: grammar fix Message-ID: <1334180320.01.0.771394900512.issue14553@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- assignee: docs at python components: Documentation files: grammar.diff keywords: patch nosy: docs at python, tshepang priority: normal severity: normal status: open title: http.server module: grammar fix versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25183/grammar.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 23:38:51 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 11 Apr 2012 21:38:51 +0000 Subject: [issue11501] distutils.archive_util should handle absence of zlib module In-Reply-To: <1300119578.93.0.647722087652.issue11501@psf.upfronthosting.co.za> Message-ID: <1334180331.73.0.987178759007.issue11501@psf.upfronthosting.co.za> ?ric Araujo added the comment: Reopening for 2.7.4. ---------- assignee: tarek -> eric.araujo resolution: fixed -> stage: committed/rejected -> commit review status: closed -> open versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 23:40:36 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 11 Apr 2012 21:40:36 +0000 Subject: [issue14548] garbage collection just after multiprocessing's fork causes exceptions In-Reply-To: <1334176061.34.0.532449046094.issue14548@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Hmm... I don't really like disabling GC, because it has a process-wide side effect, and hence isn't thread-safe: if another thread forks() or creates a subprocess right at the wrong time, it could end up with the GC disabled for good... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 11 23:46:47 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 11 Apr 2012 21:46:47 +0000 Subject: [issue14548] garbage collection just after multiprocessing's fork causes exceptions In-Reply-To: Message-ID: <1334180762.3328.58.camel@localhost.localdomain> Antoine Pitrou added the comment: > Hmm... > I don't really like disabling GC, because it has a process-wide side > effect, and hence isn't thread-safe: if another thread forks() or > creates a subprocess right at the wrong time, it could end up with the > GC disabled for good... That's a problem indeed. Perhaps we need a global "fork lock" shared between subprocess and multiprocessing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 00:02:35 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Wed, 11 Apr 2012 22:02:35 +0000 Subject: [issue14554] test module: correction Message-ID: <1334181755.32.0.776262768406.issue14554@psf.upfronthosting.co.za> New submission from Tshepang Lekhonkhobe : add missing '\n' ---------- assignee: docs at python components: Documentation messages: 158082 nosy: docs at python, tshepang priority: normal severity: normal status: open title: test module: correction versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 00:06:54 2012 From: report at bugs.python.org (Jon Oberheide) Date: Wed, 11 Apr 2012 22:06:54 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334182014.67.0.0883154509508.issue14532@psf.upfronthosting.co.za> Jon Oberheide added the comment: Will do! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 00:29:18 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 11 Apr 2012 22:29:18 +0000 Subject: [issue14555] clock_gettime/settime/getres: Add more clock identifiers Message-ID: <1334183358.11.0.0329195703165.issue14555@psf.upfronthosting.co.za> New submission from STINNER Victor : Python 3.3 supports the following clock identifiers: * CLOCK_REALTIME * CLOCK_MONOTONIC * CLOCK_MONOTONIC_RAW * CLOCK_HIGHRES * CLOCK_PROCESS_CPUTIME_ID * CLOCK_THREAD_CPUTIME_ID Linux has more clocks: * CLOCK_BOOTTIME * CLOCK_REALTIME_COARSE * CLOCK_MONOTONIC_COARSE * CLOCK_BOOTTIME_ALARM * CLOCK_REALTIME_ALARM FreeBSD has more clocks: * CLOCK_VIRTUAL * CLOCK_UPTIME, CLOCK_UPTIME_FAST, CLOCK_UPTIME_PRECISE * CLOCK_MONOTONIC_FAST, CLOCK_MONOTONIC_PRECISE * CLOCK_REALTIME_FAST, CLOCK_REALTIME_PRECISE * CLOCK_SECOND * CLOCK_PROF CLOCK_BOOTTIME is useful is you would like to handle system suspend for example. ---------- components: Library (Lib) messages: 158084 nosy: haypo priority: normal severity: normal status: open title: clock_gettime/settime/getres: Add more clock identifiers versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 00:30:46 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 11 Apr 2012 22:30:46 +0000 Subject: [issue14555] clock_gettime/settime/getres: Add more clock identifiers In-Reply-To: <1334183358.11.0.0329195703165.issue14555@psf.upfronthosting.co.za> Message-ID: <1334183446.65.0.25603196181.issue14555@psf.upfronthosting.co.za> STINNER Victor added the comment: Extract of FreeBSD manpage of clock_gettime: The clock_id argument can be one of the following values: CLOCK_REALTIME, CLOCK_REALTIME_PRECISE, CLOCK_REALTIME_FAST for time that increments as a wall clock should; CLOCK_MONOTONIC, CLOCK_MONOTONIC_PRECISE, CLOCK_MONOTONIC_FAST which increments in SI seconds; CLOCK_UPTIME, CLOCK_UPTIME_PRECISE, CLOCK_UPTIME_FAST which starts at zero when the kernel boots and increments monotonically in SI seconds while the machine is running; CLOCK_VIRTUAL for time that increments only when the CPU is running in user mode on behalf of the calling process; CLOCK_PROF for time that increments when the CPU is running in user or kernel mode; or CLOCK_SECOND which returns the current second without performing a full time counter query, using in-kernel cached value of current second. The clock IDs CLOCK_REALTIME_FAST, CLOCK_MONOTONIC_FAST, CLOCK_UPTIME_FAST are analogs of corresponding IDs without _FAST suffix but do not perform a full time counter query, so their accuracy is one timer tick. Similarly, CLOCK_REALTIME_PRECISE, CLOCK_MONOTONIC_PRECISE, CLOCK_UPTIME_PRECISE are used to get the most exact value as possible, at the expense of execution time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 00:44:30 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 11 Apr 2012 22:44:30 +0000 Subject: [issue14551] imp.load_source docs removed from python3 docs...is this correct? In-Reply-To: <1334168911.32.0.490760920072.issue14551@psf.upfronthosting.co.za> Message-ID: <1334184270.06.0.811473912037.issue14551@psf.upfronthosting.co.za> Brett Cannon added the comment: Once importlib bootstrapping lands and I expose the rest of the API you can replace imp.load_source() w/ importlib.SourceFileLoader(name, path).load_module(name) and get the same result. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 01:07:36 2012 From: report at bugs.python.org (sbt) Date: Wed, 11 Apr 2012 23:07:36 +0000 Subject: [issue14548] garbage collection just after multiprocessing's fork causes exceptions In-Reply-To: <1334161952.16.0.996503370024.issue14548@psf.upfronthosting.co.za> Message-ID: <1334185656.37.0.476304514318.issue14548@psf.upfronthosting.co.za> sbt added the comment: > That's a problem indeed. Perhaps we need a global "fork lock" shared > between subprocess and multiprocessing? I did an atfork patch which included a (recursive) fork lock. See http://bugs.python.org/review/6721/show The patch included changes to multiprocessing and subprocess. (Being able to acquire the lock when doing fd manipulation is quite useful. For instance, the creation of Process.sentinel currently has a race which can mean than another process inherits the write end of the pipe. That would cause Process.join() to wait till both processes terminate.) Actually, for Finalizers I think it would be easier to just record and check the pid. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 01:16:06 2012 From: report at bugs.python.org (Georg Brandl) Date: Wed, 11 Apr 2012 23:16:06 +0000 Subject: [issue14554] test module: correction In-Reply-To: <1334181755.32.0.776262768406.issue14554@psf.upfronthosting.co.za> Message-ID: <1334186166.63.0.475087340919.issue14554@psf.upfronthosting.co.za> Georg Brandl added the comment: I think a patch is missing :) ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 02:03:23 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 12 Apr 2012 00:03:23 +0000 Subject: [issue14555] clock_gettime/settime/getres: Add more clock identifiers In-Reply-To: <1334183358.11.0.0329195703165.issue14555@psf.upfronthosting.co.za> Message-ID: <1334189003.78.0.112320930202.issue14555@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 02:41:07 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 12 Apr 2012 00:41:07 +0000 Subject: [issue14553] http.server module: grammar fix Message-ID: New submission from Roundup Robot : New changeset ed5788424c34 by R David Murray in branch '3.2': #14553: fix word order. http://hg.python.org/cpython/rev/ed5788424c34 New changeset bd353f12c007 by R David Murray in branch 'default': Merge doc fixes #14553 and #14552. http://hg.python.org/cpython/rev/bd353f12c007 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 02:43:06 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 12 Apr 2012 00:43:06 +0000 Subject: [issue14553] http.server module: grammar fix In-Reply-To: Message-ID: <1334191386.23.0.426687314459.issue14553@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks. ---------- nosy: +r.david.murray resolution: -> fixed status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 02:44:48 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 12 Apr 2012 00:44:48 +0000 Subject: [issue14552] test module: remove repetition Message-ID: <1334191488.24.0.83173188602.issue14552@psf.upfronthosting.co.za> New submission from R. David Murray : 2.7 d60ef141e090 3.2 f25fb7e1d076 3.3 bd353f12c007 Thanks. ---------- nosy: +r.david.murray resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 03:03:58 2012 From: report at bugs.python.org (Paul A.) Date: Thu, 12 Apr 2012 01:03:58 +0000 Subject: [issue14540] Crash in Modules/_ctypes/libffi/src/dlmalloc.c on ia64-hp-hpux11.31 In-Reply-To: <1334023876.29.0.692126392594.issue14540@psf.upfronthosting.co.za> Message-ID: <1334192638.54.0.112139865349.issue14540@psf.upfronthosting.co.za> Paul A. added the comment: Yes indeed, sorry for not answering that question the first time. The trace is complete, and is from python... although most of it is really in the shared lib rather than the executable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 03:16:46 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 12 Apr 2012 01:16:46 +0000 Subject: [issue14399] zipfile and creat/update comment In-Reply-To: <1332606431.21.0.286905846716.issue14399@psf.upfronthosting.co.za> Message-ID: <1334193406.51.0.890623658336.issue14399@psf.upfronthosting.co.za> R. David Murray added the comment: Serhiy: this looks good. I get some test errors when I apply it on 2.7 though. Would you be interested in doing a 2.7 version as well? (Minor comment: the test method would be better as two test methods, and it would be nice to have a third test method that checked for the TypeError for non-binary comments...that won't apply to 2.7, obviously). ---------- stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 03:17:22 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 12 Apr 2012 01:17:22 +0000 Subject: [issue14399] zipfile and creat/update comment In-Reply-To: <1332606431.21.0.286905846716.issue14399@psf.upfronthosting.co.za> Message-ID: <1334193442.59.0.9217680792.issue14399@psf.upfronthosting.co.za> R. David Murray added the comment: Serhiy: this looks good. I get some test errors when I apply it on 2.7 though. Would you be interested in doing a 2.7 version as well? (Minor comment: the test method would be better as two test methods, and it would be nice to have a third test method that checked for the TypeError for non-binary comments...that won't apply to 2.7, obviously). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 03:17:50 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 12 Apr 2012 01:17:50 +0000 Subject: [issue14399] zipfile and creat/update comment In-Reply-To: <1332606431.21.0.286905846716.issue14399@psf.upfronthosting.co.za> Message-ID: <1334193470.9.0.146330042362.issue14399@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- Removed message: http://bugs.python.org/msg158095 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 03:20:17 2012 From: report at bugs.python.org (Joel Lovinger) Date: Thu, 12 Apr 2012 01:20:17 +0000 Subject: [issue14556] telnetlib Telnet.expect fails with timeout=0 Message-ID: <1334193617.55.0.736160184516.issue14556@psf.upfronthosting.co.za> New submission from Joel Lovinger : In Python 2.4.3 a Telnet.expect with timeout=0 would always make at least one call to Telnet.fill_rawq if a match couldn't be found and the connection was open. In Python 2.7.1/2.7.3 Telnet.expect with timeout=0 breaks before any call to Telnet.fill_rawq if a match isn't found in already read raw/cooked data. Expected behavior is that on timeout=0 at least one non-blocking attempt should be made to read from the connection when necessary to fulfill a match. >From code inspection (including Python 2.7.3) timeout behavior was modified to provide an overall elapsed timeout instead of passing unmodified timeout to each select resulting in the failure. Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from telnetlib import Telnet >>> import time >>> tn = Telnet("scn.org", 23) >>> time.sleep(5) # short wait for data to be available >>> tn.expect(['.{16}'], 0) (-1, None, '') >>> Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from telnetlib import Telnet >>> import time >>> tn = Telnet("scn.org", 23) >>> time.sleep(5) # short wait for data to be available >>> tn.expect(['.{16}'], 0) (0, <_sre.SRE_Match object at 0x01752410>, '\r\nSeattle Communit') >>> ---------- components: Library (Lib) messages: 158096 nosy: Joel.Lovinger priority: normal severity: normal status: open title: telnetlib Telnet.expect fails with timeout=0 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 03:31:16 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 12 Apr 2012 01:31:16 +0000 Subject: [issue14547] Python symlink to script behaves unexpectedly In-Reply-To: <1334155369.29.0.554259242167.issue14547@psf.upfronthosting.co.za> Message-ID: <1334194276.8.0.515224055782.issue14547@psf.upfronthosting.co.za> Nick Coghlan added the comment: Specifically, we end up calling os.realpath() (or the C level equivalent) when initialising __main__.__file__ and sys.path[0]. Agreed this behaviour should be documented (and tested!) explicitly. ---------- assignee: -> docs at python components: +Documentation, Tests nosy: +docs at python stage: -> needs patch type: -> enhancement versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 03:33:26 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 12 Apr 2012 01:33:26 +0000 Subject: [issue14556] telnetlib Telnet.expect fails with timeout=0 In-Reply-To: <1334193617.55.0.736160184516.issue14556@psf.upfronthosting.co.za> Message-ID: <1334194406.69.0.467454806479.issue14556@psf.upfronthosting.co.za> R. David Murray added the comment: Can you point to the changes you think are at issue? That might help us track down why the change was made. This isn't necessarily a bug, but even if it isn't, the behavior should probably be explicitly documented. ---------- nosy: +jackdied, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 03:45:34 2012 From: report at bugs.python.org (Adi Roiban) Date: Thu, 12 Apr 2012 01:45:34 +0000 Subject: [issue9175] ctypes doesn't build on hp-ux In-Reply-To: <1278407736.6.0.642117116261.issue9175@psf.upfronthosting.co.za> Message-ID: <1334195134.63.0.749194043246.issue9175@psf.upfronthosting.co.za> Changes by Adi Roiban : ---------- nosy: +adiroiban _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 04:07:29 2012 From: report at bugs.python.org (Adi Roiban) Date: Thu, 12 Apr 2012 02:07:29 +0000 Subject: [issue14557] HP-UX libraries not included Message-ID: <1334196449.83.0.830418461799.issue14557@psf.upfronthosting.co.za> New submission from Adi Roiban : Hi, I am trying to build Python on HP-UXiv3. HP-UX also keeps libs in /usr/lib/hpux64 and /usr/lib/hpux32. I have attached a patch for searching these folders. ---- The patch is against the latest version of cpython. I have tests the change on Python 2.5.6. Cheers, Adi ---------- files: hpux-libs.diff keywords: patch messages: 158099 nosy: adiroiban priority: normal severity: normal status: open title: HP-UX libraries not included Added file: http://bugs.python.org/file25184/hpux-libs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 04:08:15 2012 From: report at bugs.python.org (Adi Roiban) Date: Thu, 12 Apr 2012 02:08:15 +0000 Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za> Message-ID: <1334196495.85.0.429345202488.issue5113@psf.upfronthosting.co.za> Changes by Adi Roiban : ---------- nosy: +adiroiban _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 04:09:55 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 12 Apr 2012 02:09:55 +0000 Subject: [issue14515] tempfile.TemporaryDirectory documented as returning object but returns name In-Reply-To: <1333678068.19.0.790451967958.issue14515@psf.upfronthosting.co.za> Message-ID: <1334196595.93.0.670255266904.issue14515@psf.upfronthosting.co.za> Nick Coghlan added the comment: Change looks fine to me - go ahead and commit it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 04:46:11 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 12 Apr 2012 02:46:11 +0000 Subject: [issue14551] imp.load_source docs removed from python3 docs...is this correct? In-Reply-To: <1334168911.32.0.490760920072.issue14551@psf.upfronthosting.co.za> Message-ID: <1334198771.54.0.925906836179.issue14551@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 05:32:28 2012 From: report at bugs.python.org (Brian Thorne) Date: Thu, 12 Apr 2012 03:32:28 +0000 Subject: [issue12428] functools test coverage In-Reply-To: <1309255638.21.0.342456839611.issue12428@psf.upfronthosting.co.za> Message-ID: <1334201548.89.0.305011091437.issue12428@psf.upfronthosting.co.za> Brian Thorne added the comment: I've updated the patch to address the comments here and in the code review. I added more cross testing of the pure Python implementation of partial - as you pointed out inheritance wasn't supported so I changed from the simple closure to a class implementation. Instead of skipping repr tests for the pure Python implementation could we not just implement it? I did skip the pickle test for the Python implementation though. Nick, I wasn't sure how to decorate the partial object as a staticmethod so I don't think this patch addresses issue 11704. Also I didn't understand why Lock was being imported from _thread instead of thread. Since coverage went to 100% and the tests continue to all pass when I changed this. ---------- Added file: http://bugs.python.org/file25185/12428.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 05:37:06 2012 From: report at bugs.python.org (Joel Lovinger) Date: Thu, 12 Apr 2012 03:37:06 +0000 Subject: [issue14556] telnetlib Telnet.expect fails with timeout=0 In-Reply-To: <1334193617.55.0.736160184516.issue14556@psf.upfronthosting.co.za> Message-ID: <1334201826.31.0.280290626077.issue14556@psf.upfronthosting.co.za> Joel Lovinger added the comment: Quick response! Based on review of Telnet.expect in Python 2.4.3 and Python 2.7.1/2.7.3. In Python 2.4.3 the timeout is passed unmodified on each loop iteration to the underlying select to get more data for a potential match. Iteration only ends on EOF, select timeout with no rx, or match. A timeout=0 received data, without blocking, until no more data or a match was found. Unfortunately this implementation can extend the timeout indeterminately if the connection consistently has data for each select but no match is made. Imagine with timeout=10 and a byte coming in every 5 seconds. Select will always succeed and continue to iterate. Could even happen with timeout=0 if match processing takes long enough for each iteration (high system load, long input buffer, complicated reg ex, etc). Python 2.7.1 keeps track of overall elapsed time in Telnet.expect itself and explicitly drops out when it exceeds the timeout. Further passes (timeout-elapsed) as the timeout to select. Works to ensure an expect never exceeds its timeout, but breaks the case where timeout=0 can read non-blocking to find a match. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 05:56:24 2012 From: report at bugs.python.org (Adi Roiban) Date: Thu, 12 Apr 2012 03:56:24 +0000 Subject: [issue5895] socketmodule.c on HPUX ia64 without _XOPEN_SOURCE_EXTENDED compiles incorrectly In-Reply-To: <1241195874.94.0.470854501498.issue5895@psf.upfronthosting.co.za> Message-ID: <1334202984.13.0.00834563614218.issue5895@psf.upfronthosting.co.za> Changes by Adi Roiban : ---------- nosy: +adiroiban _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 06:44:03 2012 From: report at bugs.python.org (Jon Oberheide) Date: Thu, 12 Apr 2012 04:44:03 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334205843.96.0.506487045653.issue14532@psf.upfronthosting.co.za> Jon Oberheide added the comment: Here's a v1. Works with both str and bytes types for Python 3.x. Not sure I'm completely happy with the docs, but I'd appreciate any feedback on them! ---------- keywords: +patch Added file: http://bugs.python.org/file25186/hmac-time-independent-v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 07:26:15 2012 From: report at bugs.python.org (Jeffrey Finkelstein) Date: Thu, 12 Apr 2012 05:26:15 +0000 Subject: [issue14558] Documentation for unittest.main does not describe some keyword arguments. Message-ID: <1334208375.3.0.0230518732022.issue14558@psf.upfronthosting.co.za> New submission from Jeffrey Finkelstein : Documentation for unittest.main, at , does not describe the keyword arguments 'module', 'argv', or 'testLoader'. ---------- assignee: docs at python components: Documentation messages: 158104 nosy: docs at python, jfinkels priority: normal severity: normal status: open title: Documentation for unittest.main does not describe some keyword arguments. type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 07:52:49 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 12 Apr 2012 05:52:49 +0000 Subject: [issue14558] Documentation for unittest.main does not describe some keyword arguments. In-Reply-To: <1334208375.3.0.0230518732022.issue14558@psf.upfronthosting.co.za> Message-ID: <1334209969.34.0.956132828703.issue14558@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, michael.foord stage: -> needs patch versions: -Python 2.6, Python 3.1, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 08:41:12 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Apr 2012 06:41:12 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1334205843.96.0.506487045653.issue14532@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: +def time_independent_equals(a, b): + if len(a) != len(b): + return False This is not time independent. Is it an issue? + if type(a[0]) is int: It's better to write isinstance(a, bytes). You should raise a TypeError if a is not a bytes or str. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 08:47:39 2012 From: report at bugs.python.org (=?utf-8?b?T3R0byBLZWvDpGzDpGluZW4=?=) Date: Thu, 12 Apr 2012 06:47:39 +0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1334213259.89.0.217113131317.issue1859@psf.upfronthosting.co.za> Otto Kek?l?inen added the comment: As a note to comments msg60038-msg60040, for anybody like me who ended up here after Googling around on how to do wordwrap in Python: The function textwrap in Python is for single strings/paragraphs only, and it does not work as wordwrap normally works in text editors or other programming languages (eg. Wordwrap in Python). If you want to do wordwrap or a block of text, run something like this: new_msg = "" lines = msg.split("\n") for line in lines: if len(line) > 75: w = textwrap.TextWrapper(width=75, break_long_words=False) line = '\n'.join(w.wrap(line)) new_msg += line + "\n" An use case example for this would be, if you have a email message and you want to apply word wrapping to it, so that no line would be over 78 characters. ---------- nosy: +otto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 08:56:01 2012 From: report at bugs.python.org (=?utf-8?b?T3R0byBLZWvDpGzDpGluZW4=?=) Date: Thu, 12 Apr 2012 06:56:01 +0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1334213761.91.0.764216809137.issue1859@psf.upfronthosting.co.za> Otto Kek?l?inen added the comment: In previous comment: (eg. Wordwrap in Python) -> (wordwrap() in PHP) Some examples of how this function works on text blocks: Original text: -- *Maksaako riippuvuus yksitt?isest? ohjelmistoyritykst? Helsingille vuosittain 3,4 miljoonaa euroa?* Helsingin kaupungin raportti OpenOffice-pilottihankkeesta tuottaa kaupunkilaisille enemm?n kysymyksi? kuin vastauksia. Kaupunki kokeili avoimen l?hdekoodin hy?tyohjelmistopakettia kaupunginvaltuuston j?senten kannettavissa tietokoneissa kymmenen kuukauden ajan vuonna 2011. Ohjelmistopaketti sai k?ytt?jilt? laajan hyv?ksynn?n. Kokeilun p??tytty? kaupunki tuotti pilotista raportin, jonka mukaan OpenOfficen k?ytt??notto koko virkamieskunnalle tulisi hyvin kalliiksi. "Kaupungin raportti v?itt??, ett? maksaisi 3,4 miljoonaa euroa vuodessa k?ytt?? OpenOfficea. Luku vaikuttaa yll?tt?v?n isolta ja raportti ei selosta, miten lukuun on p??dytty," sanoo Otto Kek?l?inen, Euroopan vapaiden ohjelmien s??ti? (Free Software Foundation Europe, FSFE), Suomen paikalliskoordinaattori. "Ilman tarkkoja tietoja, luku vaikuttaa perusteettomalta." Ilmeisesti Helsingin hallinto ei raporttia laatiessaan edes ollut yhteydess? yleisiin OpenOffice-palveluiden tarjoajiin tiedustellaakseen hintoja. -- Applying msg.message_body = textwrap.fill(msg.message_body_unwrapped, 75) -- *Maksaako riippuvuus yksitt?isest? ohjelmistoyritykst? Helsingille vuosittain 3,4 miljoonaa euroa?* Helsingin kaupungin raportti OpenOffice- pilottihankkeesta tuottaa kaupunkilaisille enemm?n kysymyksi? kuin vastauksia. Kaupunki kokeili avoimen l?hdekoodin hy?tyohjelmistopakettia kaupunginvaltuuston j?senten kannettavissa tietokoneissa kymmenen kuukauden ajan vuonna 2011. Ohjelmistopaketti sai k?ytt?jilt? laajan hyv?ksynn?n. Kokeilun p??tytty? kaupunki tuotti pilotista raportin, jonka mukaan OpenOfficen k?ytt??notto koko virkamieskunnalle tulisi hyvin kalliiksi. "Kaupungin raportti v?itt??, ett? maksaisi 3,4 miljoonaa euroa vuodessa k?ytt?? OpenOfficea. Luku vaikuttaa yll?tt?v?n isolta ja raportti ei selosta, miten lukuun on p??dytty," sanoo Otto Kek?l?inen, Euroopan vapaiden ohjelmien s??ti? (Free Software Foundation Europe, FSFE), Suomen paikalliskoordinaattori. "Ilman tarkkoja tietoja, luku vaikuttaa perusteettomalta." Ilmeisesti Helsingin hallinto ei raporttia laatiessaan edes ollut yhteydess? yleisiin OpenOffice-palveluiden tarjoajiin tiedustellaakseen hintoja. -- Applying msg.message_body = textwrap.fill(msg.message_body_unwrapped, 75, break_long_words=False, replace_whitespace=False) -- *Maksaako riippuvuus yksitt?isest? ohjelmistoyritykst? Helsingille vuosittain 3,4 miljoonaa euroa?* Helsingin kaupungin raportti OpenOffice- pilottihankkeesta tuottaa kaupunkilaisille enemm?n kysymyksi? kuin vastauksia. Kaupunki kokeili avoimen l?hdekoodin hy?tyohjelmistopakettia kaupunginvaltuuston j?senten kannettavissa tietokoneissa kymmenen kuukauden ajan vuonna 2011. Ohjelmistopaketti sai k?ytt?jilt? laajan hyv?ksynn?n. Kokeilun p??tytty? kaupunki tuotti pilotista raportin, jonka mukaan OpenOfficen k?ytt??notto koko virkamieskunnalle tulisi hyvin kalliiksi. "Kaupungin raportti v?itt??, ett? maksaisi 3,4 miljoonaa euroa vuodessa k?ytt?? OpenOfficea. Luku vaikuttaa yll?tt?v?n isolta ja raportti ei selosta, miten lukuun on p??dytty," sanoo Otto Kek?l?inen, Euroopan vapaiden ohjelmien s??ti? (Free Software Foundation Europe, FSFE), Suomen paikalliskoordinaattori. "Ilman tarkkoja tietoja, luku vaikuttaa perusteettomalta." Ilmeisesti Helsingin hallinto ei raporttia laatiessaan edes ollut yhteydess? yleisiin OpenOffice-palveluiden tarjoajiin tiedustellaakseen hintoja. -- In case this bug report form wraps the text, you can also view the it at pastebin: http://pastebin.com/y6icAJC6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 09:03:51 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 12 Apr 2012 07:03:51 +0000 Subject: [issue14452] SysLogHandler sends invalid messages when using unicode In-Reply-To: <1333105941.84.0.159307303218.issue14452@psf.upfronthosting.co.za> Message-ID: <1334214231.8.0.982580570135.issue14452@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Your three step approach makes sense... But it _is_ still technically a new API though in that the UTF8BOM placeholder for LogRecord's is being introduced. What would the behavior be when run on an older version without support for that placeholder be? I'm okay with adding this but wouldn't be surprised if release managers are not. But I personally have no need for syslog logging from Python so it'd be better to have someone who needs this to work properly chime in. Perhaps just fixing it nicely in 3.3 is sufficient while documenting the misbehavior as a known issue for 2.7 and 3.2. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 09:22:31 2012 From: report at bugs.python.org (Georg Brandl) Date: Thu, 12 Apr 2012 07:22:31 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334215351.84.0.569022215226.issue14538@psf.upfronthosting.co.za> Georg Brandl added the comment: ISTM that "" is neither valid HTML nor valid XHTML. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 09:24:23 2012 From: report at bugs.python.org (Mitchell Blank Jr) Date: Thu, 12 Apr 2012 07:24:23 +0000 Subject: [issue14559] (2.7.3 Regression) PC\8.0 directory can no longer be used to build on windows Message-ID: <1334215463.37.0.843460683269.issue14559@psf.upfronthosting.co.za> New submission from Mitchell Blank Jr : In the diff between 2.7.2 and 2.7.3, we see: --- Python-2.7.2/PCbuild/pythoncore.vcproj 2011-06-11 08:46:27.000000000 -0700 +++ Python-2.7.3/PCbuild/pythoncore.vcproj 2012-04-09 16:07:35.000000000 -0700 @@ -1835,6 +1835,10 @@ > + + ...however there isn't any similar change to PC\VS8.0\pythoncore.vcproj , PC\VS7.1\pythoncore.vcproj, nor PC\VC6\pythoncore.dsp I don't know if any of those are deprecated, but the VS8.0 .vcproj's definitely worked in 2.7.2. In 2.7.3 the missing random.obj file causes python27.dll to fail to link and everything goes downhill from there. Hand-applying the same change to the PC\VS8.0 directory fixed the problem for me. ---------- components: Build messages: 158110 nosy: mitchblank priority: normal severity: normal status: open title: (2.7.3 Regression) PC\8.0 directory can no longer be used to build on windows type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 09:42:10 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Thu, 12 Apr 2012 07:42:10 +0000 Subject: [issue14554] test module: correction In-Reply-To: <1334181755.32.0.776262768406.issue14554@psf.upfronthosting.co.za> Message-ID: <1334216530.6.0.979311392353.issue14554@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- keywords: +patch Added file: http://bugs.python.org/file25187/correction.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 09:48:32 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 12 Apr 2012 07:48:32 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334216912.32.0.882996818798.issue14538@psf.upfronthosting.co.za> Ezio Melotti added the comment: Here's a patch. ---------- keywords: +patch stage: test needed -> patch review Added file: http://bugs.python.org/file25188/issue14538.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 09:53:12 2012 From: report at bugs.python.org (David Lam) Date: Thu, 12 Apr 2012 07:53:12 +0000 Subject: [issue12537] mailbox's _become_message is very fragile In-Reply-To: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za> Message-ID: <1334217192.42.0.153235614849.issue12537@psf.upfronthosting.co.za> David Lam added the comment: Wow, cool! Thanks for the update. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 10:01:00 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 12 Apr 2012 08:01:00 +0000 Subject: [issue14548] garbage collection just after multiprocessing's fork causes exceptions In-Reply-To: <1334185656.37.0.476304514318.issue14548@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: >> That's a problem indeed. Perhaps we need a global "fork lock" shared >> between subprocess and multiprocessing? > > I did an atfork patch which included a (recursive) fork lock. ?See > > ? ?http://bugs.python.org/review/6721/show > > The patch included changes to multiprocessing and subprocess. ?(Being able to acquire the lock when doing fd manipulation is quite useful. ?For instance, the creation of Process.sentinel currently has a race which can mean than another process inherits the write end of the pipe. ?That would cause Process.join() to wait till both processes terminate.) Indeed, I had a look and it looked good. I just had a couple minor comments, I'll try to get back to this later today, or by the end of the week. > Actually, for Finalizers I think it would be easier to just record and check the pid. I'd prefer this too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 10:11:59 2012 From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCg?=) Date: Thu, 12 Apr 2012 08:11:59 +0000 Subject: [issue14560] urllib2 cannot make POST with utf-8 content Message-ID: <1334218319.63.0.453561175662.issue14560@psf.upfronthosting.co.za> New submission from ?????? ? : Issue can be found only in 2.7, in 2.6.6 it works System: Linux strix 3.2.14-1-ARCH x86_64 Python information: Python 2.7.2 (default, Jan 31 2012, 13:19:49) [GCC 4.6.2 20120120 (prerelease)] on linux2 Snippet to reproduce error: # -*- encoding: utf-8 -*- import urllib2 request = urllib2.Request('http://google.com', u'???????', {'Content-Type': 'text/plain; charset=utf-8'}) urllib2.urlopen(request).read() Stacktrace: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen return _opener.open(url, data, timeout) File "/usr/lib/python2.7/urllib2.py", line 394, in open response = self._open(req, data) File "/usr/lib/python2.7/urllib2.py", line 412, in _open '_open', req) File "/usr/lib/python2.7/urllib2.py", line 372, in _call_chain result = func(*args) File "/usr/lib/python2.7/urllib2.py", line 1199, in http_open return self.do_open(httplib.HTTPConnection, req) File "/usr/lib/python2.7/urllib2.py", line 1168, in do_open h.request(req.get_method(), req.get_selector(), req.data, headers) File "/usr/lib/python2.7/httplib.py", line 955, in request self._send_request(method, url, body, headers) File "/usr/lib/python2.7/httplib.py", line 989, in _send_request self.endheaders(body) File "/usr/lib/python2.7/httplib.py", line 951, in endheaders self._send_output(message_body) File "/usr/lib/python2.7/httplib.py", line 815, in _send_output self.send(message_body) File "/usr/lib/python2.7/httplib.py", line 787, in send self.sock.sendall(data) File "/usr/lib/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args) ---------- components: Unicode messages: 158114 nosy: ezio.melotti, ??????.? priority: normal severity: normal status: open title: urllib2 cannot make POST with utf-8 content versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 10:16:04 2012 From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCg?=) Date: Thu, 12 Apr 2012 08:16:04 +0000 Subject: [issue14560] urllib2 cannot make POST with utf-8 content In-Reply-To: <1334218319.63.0.453561175662.issue14560@psf.upfronthosting.co.za> Message-ID: <1334218564.91.0.812348307031.issue14560@psf.upfronthosting.co.za> ?????? ? added the comment: # -*- encoding: utf-8 -*- import urllib2 request = urllib2.Request('http://google.com', u'???????'.encode("utf-8"), {'Content-Type': 'text/plain; charset=utf-8'}) urllib2.urlopen(request).read() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 10:27:40 2012 From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCg?=) Date: Thu, 12 Apr 2012 08:27:40 +0000 Subject: [issue14560] urllib2 cannot make POST with utf-8 content In-Reply-To: <1334218319.63.0.453561175662.issue14560@psf.upfronthosting.co.za> Message-ID: <1334219260.56.0.464504942461.issue14560@psf.upfronthosting.co.za> Changes by ?????? ? : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 10:27:52 2012 From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCg?=) Date: Thu, 12 Apr 2012 08:27:52 +0000 Subject: [issue14560] urllib2 cannot make POST with utf-8 content In-Reply-To: <1334218319.63.0.453561175662.issue14560@psf.upfronthosting.co.za> Message-ID: <1334219272.05.0.038992359974.issue14560@psf.upfronthosting.co.za> ?????? ? added the comment: Sorry. My fault ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 11:22:29 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 12 Apr 2012 09:22:29 +0000 Subject: [issue14452] SysLogHandler sends invalid messages when using unicode In-Reply-To: <1333105941.84.0.159307303218.issue14452@psf.upfronthosting.co.za> Message-ID: <1334222549.3.0.609108781288.issue14452@psf.upfronthosting.co.za> Vinay Sajip added the comment: > What would the behavior be when run on an older version without support for that placeholder be? Then it would fail when the format string contained e.g. %(UTF8BOM)s and there was no corresponding attribute in the LogRecord - but that's true of any feature which is introduced in newer Pythons. I get that it would be unexpected in a point release, and that's why I've posted about this on c.l.py (no feedback from there so far). > I'm okay with adding this but wouldn't be surprised if release managers are not. Hence the post to python-dev, but no release manager has expressed an opinion yet. > Perhaps just fixing it nicely in 3.3 is sufficient while documenting the misbehavior as a known issue for 2.7 and 3.2. This is doable at a user level, except for the fact that the BOM insertion is currently unconditional. If I just remove the BOM insertion in 2.7 and 3.2, then I don't need to do the UTF8BOM placeholder thing in the stdlib; I could just add a cookbook recipe telling users how to do it. I am thinking about a different solution for 3.3 anyway, i.e. adding one or more overridable methods to SysLogHandler. Since no one has objected on c.l.py about the proposed change (which implied that if there were no objections, the change would happen) Marko may be right that not many people are affected, or care. I'll wait a little while longer, and if no objections are forthcoming I'll remove the BOM insertion in 2.7 and 3.2, add a cookbook recipe for those who need a BOM and leave it at that for those versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 12:08:04 2012 From: report at bugs.python.org (Nick) Date: Thu, 12 Apr 2012 10:08:04 +0000 Subject: [issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za> Message-ID: <1334225284.25.0.296500997066.issue9377@psf.upfronthosting.co.za> Nick added the comment: I faced with the issue on my own PC. For a Russian version of WinOS default PC name is ????-?? (C8 C2 C0 CD 2D CF CA in hex) and it returns from gethostbyaddr (CRT) exactly in this form (encoded with system locale cp1251 not UTF8). So when the function PyUnicode_FromString is called, it expects that argument is utf8 encoded string and throws and error. A lot of 3rd party modules use gethostbyaddr or getfqdn (which uses gethostbyaddr) and I can't just use function that returns names as bytes. Surrogate names are also not acceptable because the name mentioned above becomes ????-?? ---------- nosy: +spaun2002 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 12:14:41 2012 From: report at bugs.python.org (Ian Delaney) Date: Thu, 12 Apr 2012 10:14:41 +0000 Subject: [issue14561] python-2.7.2-r3 suffers test failure at test_mhlib Message-ID: <1334225681.36.0.37712291947.issue14561@psf.upfronthosting.co.za> New submission from Ian Delaney : Testing test suite of pyth-2.7. Re-running failed tests in verbose mode Re-running test 'test_mhlib' in verbose mode test_basic (test.test_mhlib.MhlibTests) ... ok test_listfolders (test.test_mhlib.MhlibTests) ... FAIL It seems to be pinned down to this one line in test that failed. ok, it comes down to this. From test_mhlib.py def test_listfolders(self): mh = getMH() eq = self.assertEqual # tfolders.sort() \\ Line 184 # eq(folders, tfolders) \\ Line 185 Commenting them out removes the source of error. The lines that trips up include at least 185, 189, 193. The 'folders' are not equal. Bug filed in gentoo bugzilla; Bug 387967; 21-10-2011. The build log from that bug in Comment 2 https://bugs.gentoo.org/attachment.cgi?id=290409 ---------- components: Tests messages: 158119 nosy: idella5 priority: normal severity: normal status: open title: python-2.7.2-r3 suffers test failure at test_mhlib type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 13:15:39 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 12 Apr 2012 11:15:39 +0000 Subject: [issue14560] urllib2 cannot make POST with utf-8 content In-Reply-To: <1334218319.63.0.453561175662.issue14560@psf.upfronthosting.co.za> Message-ID: <1334229339.97.0.243585137551.issue14560@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 13:28:04 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 12 Apr 2012 11:28:04 +0000 Subject: [issue14557] HP-UX libraries not included In-Reply-To: <1334196449.83.0.830418461799.issue14557@psf.upfronthosting.co.za> Message-ID: <1334230084.71.0.907632507014.issue14557@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Hello Adi, Thanks for your patch. Just a detail: """ if platform == 'hp-ux11': lib_dirs += ['/usr/lib/hpux64', '/usr/lib/hpux32'] """ Wouldn't it be more robust as: """ if platform.startswith('hp-ux'): lib_dirs += ['/usr/lib/hpux64', '/usr/lib/hpux32'] """ So that it works with older and (potenttially) future HP-UX releases? ---------- nosy: +neologix stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 13:42:00 2012 From: report at bugs.python.org (Adi Roiban) Date: Thu, 12 Apr 2012 11:42:00 +0000 Subject: [issue14557] HP-UX libraries not included In-Reply-To: <1334196449.83.0.830418461799.issue14557@psf.upfronthosting.co.za> Message-ID: <1334230920.14.0.998285895801.issue14557@psf.upfronthosting.co.za> Adi Roiban added the comment: Hi, startswith('hp-ux') should also work as in real world it should be synonym with hp-ux11 ... see my reasoning below I used 'hp-ux11' since this was the system I have access to and can test and I was not brave enought to assume that the patch will work on future or past version. According to wikipedia HP-UX 11.00 was relesed in 1997... and I see a trend to change the minor version number . Latest is 11.31 released in 2007... HPUX 10 is from 1995 and I am not sure if Python will work at all on such a system. As a side node, i think that HPUX will slowly die and we will not see an HP-UX 12. Cheers, Adi ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 13:50:55 2012 From: report at bugs.python.org (Mendez) Date: Thu, 12 Apr 2012 11:50:55 +0000 Subject: [issue14412] Sqlite Integer Fields In-Reply-To: <1332759601.85.0.320524122366.issue14412@psf.upfronthosting.co.za> Message-ID: <1334231455.94.0.390255301906.issue14412@psf.upfronthosting.co.za> Mendez added the comment: I've tested the released 2.7.3 and this works fine so there must just have been some oddity with the packaging of sqlite in rc2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 14:07:37 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 12 Apr 2012 12:07:37 +0000 Subject: [issue14412] Sqlite Integer Fields In-Reply-To: <1332759601.85.0.320524122366.issue14412@psf.upfronthosting.co.za> Message-ID: <1334232457.21.0.1191400738.issue14412@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Great! ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 14:23:10 2012 From: report at bugs.python.org (Anrs Hu) Date: Thu, 12 Apr 2012 12:23:10 +0000 Subject: [issue14562] urllib2 maybe blocks too long Message-ID: <1334233390.52.0.591380103695.issue14562@psf.upfronthosting.co.za> New submission from Anrs Hu : If HTTP URL response's Transfer-Encoding is 'Chunked', then the urllib2.urlopen(URL).readline() will block until there're enough 8192 bytes, even though the first chunk is just a line. Every chunks should be processed as soon as posible, so the readline() behavior should read a line and return immediately, rather than read 8K data to buffer and look up a line from the buffer. ---------- components: Library (Lib) messages: 158124 nosy: Anrs.Hu priority: normal severity: normal status: open title: urllib2 maybe blocks too long type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 14:26:48 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 12 Apr 2012 12:26:48 +0000 Subject: [issue14562] urllib2 maybe blocks too long In-Reply-To: <1334233390.52.0.591380103695.issue14562@psf.upfronthosting.co.za> Message-ID: <1334233608.05.0.146504667586.issue14562@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I am trying to this test this to determine the fault. ---------- assignee: -> orsenthil nosy: +orsenthil versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 15:04:14 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 12 Apr 2012 13:04:14 +0000 Subject: [issue14556] telnetlib Telnet.expect fails with timeout=0 In-Reply-To: <1334193617.55.0.736160184516.issue14556@psf.upfronthosting.co.za> Message-ID: <1334235854.39.0.351374045422.issue14556@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, so there are actually two timeouts of interest. One is "time out if there is no more data for X seconds", and the other is "time out if there is no match for X seconds". It used to do the former, now it does the latter. I think you get the former by calling socket.settimeout() and then using a blocking call for the expect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 15:11:02 2012 From: report at bugs.python.org (aliles) Date: Thu, 12 Apr 2012 13:11:02 +0000 Subject: [issue14563] Segmentation fault on ctypes.Structure subclass with byte string field names Message-ID: <1334236262.62.0.0349212060005.issue14563@psf.upfronthosting.co.za> New submission from aliles : Python 3.2 will exit with a segmentation fault if a byte string is used as a field name in a subclass of ctypes.Structure. Python 3.2.2 (default, Dec 18 2011, 18:56:20) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> class Point(ctypes.Structure): ... _fields_ = ((b'x', ctypes.c_int), (b'y', ctypes.c_int)) ... Segmentation fault: 11 This also occurs if None or an int is used as the field name. I would expect that a TypeError exception would be raised if an attempt is made to use an invalid type for the field name. ---------- components: ctypes files: segfault.py messages: 158127 nosy: aliles priority: normal severity: normal status: open title: Segmentation fault on ctypes.Structure subclass with byte string field names type: crash versions: Python 3.2 Added file: http://bugs.python.org/file25189/segfault.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 15:44:53 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Apr 2012 13:44:53 +0000 Subject: [issue14399] zipfile and creat/update comment In-Reply-To: <1334193442.59.0.9217680792.issue14399@psf.upfronthosting.co.za> Message-ID: <1334238429.23605.14.camel@raxxla> Serhiy Storchaka added the comment: Thank you, the TypeError test helped me find the error. Here is the corrected patch. For 2.7 it was necessary to turn the ZipFile in the new-style class. ---------- Added file: http://bugs.python.org/file25190/fix_zipfile_comment_4.patch Added file: http://bugs.python.org/file25191/fix_zipfile_comment_4-2.7.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r bd353f12c007 Lib/test/test_zipfile.py --- a/Lib/test/test_zipfile.py Wed Apr 11 20:15:10 2012 -0400 +++ b/Lib/test/test_zipfile.py Thu Apr 12 10:44:42 2012 +0300 @@ -970,6 +970,30 @@ with zipfile.ZipFile(TESTFN, mode="r") as zipfr: self.assertEqual(zipfr.comment, comment2) + def test_unicode_comment(self): + def setcomment(zipf, comment): + zipf.comment = comment + with zipfile.ZipFile(TESTFN, "w", zipfile.ZIP_STORED) as zipf: + zipf.writestr("foo.txt", "O, for a Muse of Fire!") + self.assertRaises(TypeError, setcomment, zipf, + "this is a comment") + + def test_change_comment_in_empty_archive(self): + with zipfile.ZipFile(TESTFN, "a", zipfile.ZIP_STORED) as zipf: + self.assertFalse(zipf.filelist) + zipf.comment = b"this is a comment" + with zipfile.ZipFile(TESTFN, "r") as zipf: + self.assertEqual(zipf.comment, b"this is a comment") + + def test_change_comment_in_nonempty_archive(self): + with zipfile.ZipFile(TESTFN, "w", zipfile.ZIP_STORED) as zipf: + zipf.writestr("foo.txt", "O, for a Muse of Fire!") + with zipfile.ZipFile(TESTFN, "a", zipfile.ZIP_STORED) as zipf: + self.assertTrue(zipf.filelist) + zipf.comment = b"this is a comment" + with zipfile.ZipFile(TESTFN, "r") as zipf: + self.assertEqual(zipf.comment, b"this is a comment") + def check_testzip_with_bad_crc(self, compression): """Tests that files with bad CRCs return their name from testzip.""" zipdata = self.zips_with_bad_crc[compression] diff -r bd353f12c007 Lib/zipfile.py --- a/Lib/zipfile.py Wed Apr 11 20:15:10 2012 -0400 +++ b/Lib/zipfile.py Thu Apr 12 10:44:42 2012 +0300 @@ -698,7 +698,7 @@ self.compression = compression # Method of compression self.mode = key = mode.replace('b', '')[0] self.pwd = None - self.comment = b'' + self._comment = b'' # Check if we were passed a file-like object if isinstance(file, str): @@ -774,7 +774,7 @@ print(endrec) size_cd = endrec[_ECD_SIZE] # bytes in central directory offset_cd = endrec[_ECD_OFFSET] # offset of central directory - self.comment = endrec[_ECD_COMMENT] # archive comment + self._comment = endrec[_ECD_COMMENT] # archive comment # "concat" is zero, unless zip was concatenated to another file concat = endrec[_ECD_LOCATION] - size_cd - offset_cd @@ -886,6 +886,24 @@ else: self.pwd = None + @property + def comment(self): + """The comment text associated with the ZIP file.""" + return self._comment + + @comment.setter + def comment(self, comment): + if not isinstance(comment, bytes): + raise TypeError("comment: expected bytes, got %s" % type(comment)) + # check for valid comment length + if len(comment) >= ZIP_MAX_COMMENT: + if self.debug: + print('Archive comment is too long; truncating to %d bytes' + % ZIP_MAX_COMMENT) + comment = comment[:ZIP_MAX_COMMENT] + self._comment = comment + self._didModify = True + def read(self, name, pwd=None): """Return file bytes (as a string) for name.""" with self.open(name, "r", pwd) as fp: @@ -1287,18 +1305,11 @@ centDirSize = min(centDirSize, 0xFFFFFFFF) centDirOffset = min(centDirOffset, 0xFFFFFFFF) - # check for valid comment length - if len(self.comment) >= ZIP_MAX_COMMENT: - if self.debug > 0: - msg = 'Archive comment is too long; truncating to %d bytes' \ - % ZIP_MAX_COMMENT - self.comment = self.comment[:ZIP_MAX_COMMENT] - endrec = struct.pack(structEndArchive, stringEndArchive, 0, 0, centDirCount, centDirCount, - centDirSize, centDirOffset, len(self.comment)) + centDirSize, centDirOffset, len(self._comment)) self.fp.write(endrec) - self.fp.write(self.comment) + self.fp.write(self._comment) self.fp.flush() if not self._filePassed: -------------- next part -------------- diff -r d60ef141e090 Lib/test/test_zipfile.py --- a/Lib/test/test_zipfile.py Wed Apr 11 20:38:45 2012 -0400 +++ b/Lib/test/test_zipfile.py Thu Apr 12 16:27:55 2012 +0300 @@ -908,6 +908,30 @@ with zipfile.ZipFile(TESTFN, mode="r") as zipf: self.assertEqual(zipf.comment, comment2) + def test_unicode_comment(self): + def setcomment(zipf, comment): + zipf.comment = comment + with zipfile.ZipFile(TESTFN, "w", zipfile.ZIP_STORED) as zipf: + zipf.writestr("foo.txt", "O, for a Muse of Fire!") + self.assertRaises(TypeError, setcomment, zipf, + u"this is a comment") + + def test_change_comment_in_empty_archive(self): + with zipfile.ZipFile(TESTFN, "a", zipfile.ZIP_STORED) as zipf: + self.assertFalse(zipf.filelist) + zipf.comment = b"this is a comment" + with zipfile.ZipFile(TESTFN, "r") as zipf: + self.assertEqual(zipf.comment, b"this is a comment") + + def test_change_comment_in_nonempty_archive(self): + with zipfile.ZipFile(TESTFN, "w", zipfile.ZIP_STORED) as zipf: + zipf.writestr("foo.txt", "O, for a Muse of Fire!") + with zipfile.ZipFile(TESTFN, "a", zipfile.ZIP_STORED) as zipf: + self.assertTrue(zipf.filelist) + zipf.comment = b"this is a comment" + with zipfile.ZipFile(TESTFN, "r") as zipf: + self.assertEqual(zipf.comment, b"this is a comment") + def check_testzip_with_bad_crc(self, compression): """Tests that files with bad CRCs return their name from testzip.""" zipdata = self.zips_with_bad_crc[compression] diff -r d60ef141e090 Lib/zipfile.py --- a/Lib/zipfile.py Wed Apr 11 20:38:45 2012 -0400 +++ b/Lib/zipfile.py Thu Apr 12 16:27:55 2012 +0300 @@ -651,7 +651,7 @@ -class ZipFile: +class ZipFile(object): """ Class with methods to open, read, write, close, list zip files. z = ZipFile(file, mode="r", compression=ZIP_STORED, allowZip64=False) @@ -690,7 +690,7 @@ self.compression = compression # Method of compression self.mode = key = mode.replace('b', '')[0] self.pwd = None - self.comment = '' + self._comment = '' # Check if we were passed a file-like object if isinstance(file, basestring): @@ -765,7 +765,7 @@ print endrec size_cd = endrec[_ECD_SIZE] # bytes in central directory offset_cd = endrec[_ECD_OFFSET] # offset of central directory - self.comment = endrec[_ECD_COMMENT] # archive comment + self._comment = endrec[_ECD_COMMENT] # archive comment # "concat" is zero, unless zip was concatenated to another file concat = endrec[_ECD_LOCATION] - size_cd - offset_cd @@ -864,6 +864,24 @@ """Set default password for encrypted files.""" self.pwd = pwd + @property + def comment(self): + """The comment text associated with the ZIP file.""" + return self._comment + + @comment.setter + def comment(self, comment): + if not isinstance(comment, bytes): + raise TypeError("comment: expected bytes, got %s" % type(comment)) + # check for valid comment length + if len(comment) >= ZIP_MAX_COMMENT: + if self.debug: + print('Archive comment is too long; truncating to %d bytes' + % ZIP_MAX_COMMENT) + comment = comment[:ZIP_MAX_COMMENT] + self._comment = comment + self._didModify = True + def read(self, name, pwd=None): """Return file bytes (as a string) for name.""" return self.open(name, "r", pwd).read() @@ -1243,18 +1261,11 @@ centDirSize = min(centDirSize, 0xFFFFFFFF) centDirOffset = min(centDirOffset, 0xFFFFFFFF) - # check for valid comment length - if len(self.comment) >= ZIP_MAX_COMMENT: - if self.debug > 0: - msg = 'Archive comment is too long; truncating to %d bytes' \ - % ZIP_MAX_COMMENT - self.comment = self.comment[:ZIP_MAX_COMMENT] - endrec = struct.pack(structEndArchive, stringEndArchive, 0, 0, centDirCount, centDirCount, - centDirSize, centDirOffset, len(self.comment)) + centDirSize, centDirOffset, len(self._comment)) self.fp.write(endrec) - self.fp.write(self.comment) + self.fp.write(self._comment) self.fp.flush() if not self._filePassed: From report at bugs.python.org Thu Apr 12 15:59:59 2012 From: report at bugs.python.org (Jon Oberheide) Date: Thu, 12 Apr 2012 13:59:59 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334239199.12.0.829921984475.issue14532@psf.upfronthosting.co.za> Jon Oberheide added the comment: > This is not time independent. Is it an issue? You're correct, the length check does leak the length of the expected digest as a performance enhancement (otherwise, your comparison runtime is bounded by the length of the attackers input). Generally, exposing the length and thereby potentially the underlying cryptographic hash function (eg. 20 bytes -> hmac-sha1) is not considered a security risk for this type of scenario, whereas leaking key material certainly is. I considered including this nuance in the documentation and probably should. > It's better to write isinstance(a, bytes). You should raise a > TypeError if a is not a bytes or str. Ack, thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 16:03:57 2012 From: report at bugs.python.org (Jim Jewett) Date: Thu, 12 Apr 2012 14:03:57 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334239437.28.0.517270563575.issue14538@psf.upfronthosting.co.za> Jim Jewett added the comment: -1 on that particular patch. (with only whitespace between "/" and ">") strikes me as obviously intending to close the tag, and a reasonably common error. I can't think of any reason to support nested meta tags while not supporting sloppy self-closing tags. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 16:08:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 12 Apr 2012 14:08:35 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334239715.9.0.428897343246.issue14532@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You could rewrite: result |= x ^ y as: result |= (x != y) Of course, this assumes that the "!=" operator is constant-time for 1-element strings. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 16:09:12 2012 From: report at bugs.python.org (Jim Jewett) Date: Thu, 12 Apr 2012 14:09:12 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334239752.71.0.810124333617.issue14538@psf.upfronthosting.co.za> Jim Jewett added the comment: This issue is also marked for (bugfix-only) 2.7 and 3.2. Unless there is a specification somewhere (or at least an editor's draft), I can't really see any particular parse as a bugfix. Was the goal just to make the parse finish, as opposed to stopping part way through the text? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 16:18:10 2012 From: report at bugs.python.org (Jon Oberheide) Date: Thu, 12 Apr 2012 14:18:10 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334240290.42.0.954061772282.issue14532@psf.upfronthosting.co.za> Jon Oberheide added the comment: > You could rewrite: > > result |= x ^ y > > as: > > result |= (x != y) You could, but it's best not to introduce any conditional branching based if at all possible. For reference, see: http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/#comment-5783 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 16:20:07 2012 From: report at bugs.python.org (sbt) Date: Thu, 12 Apr 2012 14:20:07 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334240407.83.0.275390787859.issue14532@psf.upfronthosting.co.za> sbt added the comment: Why not just def time_independent_equals(a, b): return len(a) == len(b) and sum(x != y for x, y in zip(a, b)) == 0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 16:24:45 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 12 Apr 2012 14:24:45 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1334240685.77.0.659737930308.issue13405@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Removed file: http://bugs.python.org/file24281/5458412752d5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 16:24:58 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 12 Apr 2012 14:24:58 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1334240698.26.0.121364132571.issue13405@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Removed file: http://bugs.python.org/file24283/f86bb02fd8f4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 16:26:21 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 12 Apr 2012 14:26:21 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1334240781.56.0.36094192302.issue13405@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Added file: http://bugs.python.org/file25192/aa2dcffa267f.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 16:27:53 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 12 Apr 2012 14:27:53 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1334240873.81.0.225195048629.issue13405@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Added file: http://bugs.python.org/file25193/1e4d2c51b2d9.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 16:30:01 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Apr 2012 14:30:01 +0000 Subject: [issue1859] textwrap doesn't linebreak on "\n" In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za> Message-ID: <1334241001.84.0.447838829677.issue1859@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Cooking recipe for Otto: def wrap_paragraphs(text, width=70, **kwargs): return [line for para in text.splitlines() for line in textwrap.wrap(para, width, **kwargs)] ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 16:35:55 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 12 Apr 2012 14:35:55 +0000 Subject: [issue14399] zipfile and creat/update comment In-Reply-To: <1332606431.21.0.286905846716.issue14399@psf.upfronthosting.co.za> Message-ID: <1334241355.8.0.40280419715.issue14399@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks. We've had trouble in the past with a conversion to new style class breaking people's code. People are less likely to be subclassing ZipFile, though, so it is probably OK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 16:36:22 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 12 Apr 2012 14:36:22 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1334241382.19.0.430292749955.issue13405@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Published diff from stock 2.7.3. Cleanups and simplifications. Marc, could you possible compile under MacOS X both 2.7 and 3.3 branches, both in 32 and 64 bits?. The tags are: dtrace-issue13405 <- 3.3a2+ dtrace-issue13405_2.7 <- 2.7.3 Let me know how is going. Please, document your build environment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 16:49:10 2012 From: report at bugs.python.org (Tom Bachmann) Date: Thu, 12 Apr 2012 14:49:10 +0000 Subject: [issue1065986] Fix pydoc crashing on unicode strings Message-ID: <1334242150.09.0.0333675101509.issue1065986@psf.upfronthosting.co.za> Tom Bachmann added the comment: Hello, [this is my first bug report, so I'm sorry if I'm not adhering to some conventions] in what versions of python is this supposed to be fixed? Consider: % python Python 2.7.2+ (default, Nov 30 2011, 19:22:03) [GCC 4.6.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from pydoc import pager >>> from locale import getpreferredencoding >>> expr = u'\u211a' >>> pager(expr) # error >>> pager(expr.encode(getdefaultencoding())) # works The error is: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/pydoc.py", line 1318, in pager pager(text) File "/usr/lib/python2.7/pydoc.py", line 1332, in return lambda text: pipepager(text, os.environ['PAGER']) File "/usr/lib/python2.7/pydoc.py", line 1359, in pipepager pipe.write(text) UnicodeEncodeError: 'ascii' codec can't encode character u'\u211a' in position 0: ordinal not in range(128) Best, Tom ---------- nosy: +ness _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 16:51:21 2012 From: report at bugs.python.org (Philippe Devalkeneer) Date: Thu, 12 Apr 2012 14:51:21 +0000 Subject: [issue6717] Some problem with recursion handling In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za> Message-ID: <1334242281.79.0.149983384702.issue6717@psf.upfronthosting.co.za> Changes by Philippe Devalkeneer : ---------- nosy: +flupke _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 16:51:36 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 12 Apr 2012 14:51:36 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1334242296.76.0.736171071036.issue13405@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: PHP 5.4.0 added DTRACE support: http://fr2.php.net/ChangeLog-5.php The python window for 3.3 closes mid june. Let's do not miss it this time :-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 16:58:19 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Apr 2012 14:58:19 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334242699.65.0.169651168917.issue14538@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: To be consistent, this patch should remove the references to http://www.w3.org/TR/html5/tokenization.html#tag-open-state and http://www.w3.org/TR/html5/tokenization.html#tag-open-state as irrelevant. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 17:08:31 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 12 Apr 2012 15:08:31 +0000 Subject: [issue1065986] Fix pydoc crashing on unicode strings Message-ID: <1334243311.87.0.688380327646.issue1065986@psf.upfronthosting.co.za> R. David Murray added the comment: It is fixed in Python3. Apparently Raymond was wrong about it having been fixed earlier (or perhaps he was referring to the unicode being removed from the pydoc __credits__ string). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 17:08:59 2012 From: report at bugs.python.org (Tom Bachmann) Date: Thu, 12 Apr 2012 15:08:59 +0000 Subject: [issue1065986] Fix pydoc crashing on unicode strings In-Reply-To: <1334243311.87.0.688380327646.issue1065986@psf.upfronthosting.co.za> Message-ID: <4F86F009.502@web.de> Tom Bachmann added the comment: I see. Thank you. On 12.04.2012 16:08, R. David Murray wrote: > > R. David Murray added the comment: > > It is fixed in Python3. Apparently Raymond was wrong about it having been fixed earlier (or perhaps he was referring to the unicode being removed from the pydoc __credits__ string). > > ---------- > nosy: +r.david.murray > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 17:26:45 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 12 Apr 2012 15:26:45 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334244405.96.0.271121992173.issue14538@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, after considerable discussion those of working on this stuff decided that the goal should be that the parser be able to complete parsing, without error, anything the typical browsers can parse (which means, pretty much anything, though that says nothing about whether the result of the parse is useful in any way). In other words, we've been treating it as a bug when the parser throws an error, since one generally uses the library to parse web pages from the internet and having the parse fail leaves you SOL for doing anything useful with the bad pages one gets therefrom. (Note that if the parser was doing strict adherence to the older RFCs our decision would have been different...but it is not. It has always accepted *some* badly formed documents, and rejected others.) Also note that BeautifulSoup in Python2 used the sgml parser, which didn't throw errors, but that is gone in Python3. In Python3 BeautifulSoup uses the html parser...which is what started us down this road to begin with. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 17:47:27 2012 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 12 Apr 2012 15:47:27 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1334245647.42.0.574819225306.issue13903@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +Yury.Selivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 18:01:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 12 Apr 2012 16:01:54 +0000 Subject: [issue6717] Some problem with recursion handling In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za> Message-ID: <1334246514.82.0.304665020381.issue6717@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, this is all by design. The interpreter *has* to stop: either it stops in a controlled way (the fatal error) or the stack is blown and it crashes. If you think the fatal error (basically a C abort() call) should be replaced with another way of exiting, please suggest so. (actually, it's not the interpreter as a whole, only the current thread, but crashing a thread without affecting the others is probably impossible, due to reference leaks, resource cleanup, etc.) ---------- nosy: +loewis, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 18:06:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 12 Apr 2012 16:06:05 +0000 Subject: [issue14432] Bug in generator if the generator in created in a C thread In-Reply-To: <1332948868.24.0.309034348776.issue14432@psf.upfronthosting.co.za> Message-ID: <1334246765.4.0.568584938445.issue14432@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 18:12:11 2012 From: report at bugs.python.org (Dino Viehland) Date: Thu, 12 Apr 2012 16:12:11 +0000 Subject: [issue6717] Some problem with recursion handling In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za> Message-ID: <1334247131.7.0.125019546548.issue6717@psf.upfronthosting.co.za> Dino Viehland added the comment: Antoine: If you're looking at my test.py then my expectation is that this doesn't crash because a RuntimeError should be raised when the maximum recursion limit is hit, and then the trace handler should be uninstalled because it leaks an exception. And that's exactly what seems to happens on Python 2.x. We shouldn't ever hit the OS stack limit because Python's recursion limit should be enforced even in the face of a sys.settrace handler. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 18:17:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 12 Apr 2012 16:17:26 +0000 Subject: [issue6717] Some problem with recursion handling In-Reply-To: <1334247131.7.0.125019546548.issue6717@psf.upfronthosting.co.za> Message-ID: <1334247399.3343.7.camel@localhost.localdomain> Antoine Pitrou added the comment: > Antoine: If you're looking at my test.py then my expectation is that > this doesn't crash because a RuntimeError should be raised when the > maximum recursion limit is hit, and then the trace handler should be > uninstalled because it leaks an exception. I don't understand why you say that "the trace handler leaks an exception", since it silences it in the "try ... except" block. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 18:22:20 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 12 Apr 2012 16:22:20 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za> Message-ID: <1334247740.37.0.0662791251212.issue14082@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Ok, so I?ve added a function `copyxattr()` and `copy2()` tries to copy all possible namespaces. Tests pass on Linux and Mac OS X. ---------- keywords: +patch Added file: http://bugs.python.org/file25194/xattr.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 18:25:16 2012 From: report at bugs.python.org (Dino Viehland) Date: Thu, 12 Apr 2012 16:25:16 +0000 Subject: [issue6717] Some problem with recursion handling In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za> Message-ID: <1334247916.85.0.267497352776.issue6717@psf.upfronthosting.co.za> Dino Viehland added the comment: It's catching the exception when it invokes x, but the recursion enforcement should happen at a method prolog, including at the invocation of g. Therefore if we're at or beyond the recursion limit when invoking the trace handler the limits should still be enforced and that should be the same as the trace handler raising. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 18:31:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 12 Apr 2012 16:31:50 +0000 Subject: [issue6717] Some problem with recursion handling In-Reply-To: <1334247916.85.0.267497352776.issue6717@psf.upfronthosting.co.za> Message-ID: <1334248262.3343.12.camel@localhost.localdomain> Antoine Pitrou added the comment: > It's catching the exception when it invokes x, but the recursion > enforcement should happen at a method prolog, including at the > invocation of g. Therefore if we're at or beyond the recursion limit > when invoking the trace handler the limits should still be enforced > and that should be the same as the trace handler raising. That's where 3.x is different: 3.x temporarily bumps up the recursion limit a bit when it is first reached, in order to let various cleanup handlers run as intended. This is a nice thing in the general case, but means it can degenerate in more involved or desperate cases. (although here it's not clear to me why a second recursion error occurs after the first one) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 18:35:36 2012 From: report at bugs.python.org (Dino Viehland) Date: Thu, 12 Apr 2012 16:35:36 +0000 Subject: [issue6717] Some problem with recursion handling In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za> Message-ID: <1334248536.97.0.671394289993.issue6717@psf.upfronthosting.co.za> Dino Viehland added the comment: Maybe there just needs to be a max that it will bump it up? FYI this isn't actually causing any problems for me, I just ran into it while doing IronPython development and was surprised to be able to crash the interpreter w/ pure Python code, and my crash looked awfully similar to this bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 18:37:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 12 Apr 2012 16:37:42 +0000 Subject: [issue6717] Some problem with recursion handling In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za> Message-ID: <1334248662.32.0.539321674688.issue6717@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > FYI this isn't actually causing any problems for me, I just ran into it > while doing IronPython development and was surprised to be able to > crash the interpreter w/ pure Python code, and my crash looked awfully > similar to this bug. I agree that crashing isn't ideal, and there may be more graceful ways of crashing instead of abort(), so that people don't get that horrible message box under Windows. Suggestions welcome. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 18:45:29 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 12 Apr 2012 16:45:29 +0000 Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za> Message-ID: <1334249129.2.0.407250873047.issue5113@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Adi, since you have access to an HP-UX box, could you test the attached patch (chown_hpux.diff)? Also, if you're interested, you could search for other isues HP-UX-specific to see if you can help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 19:13:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 12 Apr 2012 17:13:51 +0000 Subject: [issue14557] HP-UX libraries not included In-Reply-To: <1334196449.83.0.830418461799.issue14557@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 807f331f973d by Charles-Fran?ois Natali in branch '3.2': Issue #14557: Fix extensions build on HP-UX. Patch by Adi Roiban. http://hg.python.org/cpython/rev/807f331f973d New changeset 9481e801ae7c by Charles-Fran?ois Natali in branch 'default': Issue #14557: Fix extensions build on HP-UX. Patch by Adi Roiban. http://hg.python.org/cpython/rev/9481e801ae7c New changeset cc2e3c6d2669 by Charles-Fran?ois Natali in branch '2.7': Issue #14557: Fix extensions build on HP-UX. Patch by Adi Roiban. http://hg.python.org/cpython/rev/cc2e3c6d2669 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 19:27:25 2012 From: report at bugs.python.org (Peng Yu) Date: Thu, 12 Apr 2012 17:27:25 +0000 Subject: [issue14564] Error running: ( echo 'import os'; echo 'help(os)'; )| python |head Message-ID: <1334251645.47.0.0743579426512.issue14564@psf.upfronthosting.co.za> New submission from Peng Yu : I get the following error when I run the following command. I think that help may use something that don't work well with pipe. Could anybody take a look? ~/linux/bin/xplat/src/pymisc/pyhelp/main$ ( echo 'import os'; echo 'help(os)'; )| python |head Help on module os: NAME os - OS routines for Mac, NT, or Posix depending on what system we're on. FILE /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py MODULE DOCS http://docs.python.org/library/os Traceback (most recent call last): File "", line 2, in File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 467, in __call__ return pydoc.help(*args, **kwds) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1727, in __call__ self.help(request) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1774, in help else: doc(request, 'Help on %s:') File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1511, in doc pager(render_doc(thing, title, forceload)) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1318, in pager pager(text) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1416, in plainpager sys.stdout.write(plain(text)) IOError: [Errno 32] Broken pipe ~/linux/bin/xplat/src/pymisc/pyhelp/main$ ( echo 'import os'; echo 'help(os)'; )| python Help on module os: NAME os - OS routines for Mac, NT, or Posix depending on what system we're on. FILE /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py MODULE DOCS http://docs.python.org/library/os DESCRIPTION ---------- messages: 158154 nosy: Peng.Yu priority: normal severity: normal status: open title: Error running: ( echo 'import os'; echo 'help(os)'; )| python |head versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 19:43:46 2012 From: report at bugs.python.org (Adi Roiban) Date: Thu, 12 Apr 2012 17:43:46 +0000 Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za> Message-ID: <1334252626.15.0.525051225252.issue5113@psf.upfronthosting.co.za> Adi Roiban added the comment: Hi, Not sure what codebase was used for the patch. I have manually patched the test on 2.5.6 and the test_posix tests passed. Thanks! Adi ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 19:58:48 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 12 Apr 2012 17:58:48 +0000 Subject: [issue14557] HP-UX libraries not included In-Reply-To: <1334196449.83.0.830418461799.issue14557@psf.upfronthosting.co.za> Message-ID: <1334253528.12.0.175006945511.issue14557@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Committed, thanks! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 20:14:24 2012 From: report at bugs.python.org (Dino Viehland) Date: Thu, 12 Apr 2012 18:14:24 +0000 Subject: [issue6717] Some problem with recursion handling In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za> Message-ID: <1334254464.14.0.261673510955.issue6717@psf.upfronthosting.co.za> Dino Viehland added the comment: One thought might be to do a recursion check (and maybe for multiple frames) when entering a try rather than incrementing the recursion limit to allow the handlers to run. That would cause the exception to be more likely taken before you run the code which needs some form of cleanup and then maybe the recursion limit could be a hard limit which can't be increased forever. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 20:21:06 2012 From: report at bugs.python.org (Glenn Linderman) Date: Thu, 12 Apr 2012 18:21:06 +0000 Subject: [issue14565] is_cgi doesn't function as documented for cgi_directories Message-ID: <1334254866.64.0.659489278184.issue14565@psf.upfronthosting.co.za> New submission from Glenn Linderman : I notice a deficiency in is_cgi: there is no documentation requiring cgi_directories to be a single part, only that the initial value happens to be a list of two directories, each of which have only a single part or level. The description of is_cgi, however, only requires that the strings in self.cgi_directories be prefixes of self.path, followed by "/" or end of string. While it is not at all clear that being followed by end of string would produce useful results, the description does allow for multiple parts in the directory, but the implementation does not. Consider a potential value in an overridden or augmented cgi_directories such as '/subdomain/cgi-bin'. The current is_cgi wouldn't handle that. Solution: replace the following is_cgi code (from current trunk): collapsed_path = _url_collapse_path(self.path) dir_sep = collapsed_path.find('/', 1) head, tail = collapsed_path[:dir_sep], collapsed_path[dir_sep+1:] if head in self.cgi_directories: self.cgi_info = head, tail return True return False with: cln = len( collapsed_path ) found = False for ix in self.cgi_directories: ln = len( ix ) print('is_cgi: %d %d - %s - %s' % ( ln, cln, ix, collapsed_path )) if ln == cln and ix == collapsed_path: self.cgi_info = ( ix, '') found = True break elif ( ln < cln and collapsed_path[ ln ] == '/' and collapsed_path.startswith( ix )): self.cgi_info = ( ix, collapsed_path[ ln+1: ]) found = True break return found ---------- messages: 158158 nosy: v+python priority: normal severity: normal status: open title: is_cgi doesn't function as documented for cgi_directories _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 20:22:36 2012 From: report at bugs.python.org (sbt) Date: Thu, 12 Apr 2012 18:22:36 +0000 Subject: [issue14548] garbage collection just after multiprocessing's fork causes exceptions In-Reply-To: <1334161952.16.0.996503370024.issue14548@psf.upfronthosting.co.za> Message-ID: <1334254956.88.0.334140047965.issue14548@psf.upfronthosting.co.za> sbt added the comment: Alternative patch which records pid when Finalize object is created. The callback does nothing if recorded pid does not match os.getpid(). ---------- Added file: http://bugs.python.org/file25195/mp_finalize_pid.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 20:23:14 2012 From: report at bugs.python.org (Glenn Linderman) Date: Thu, 12 Apr 2012 18:23:14 +0000 Subject: [issue14565] is_cgi doesn't function as documented for cgi_directories In-Reply-To: <1334254866.64.0.659489278184.issue14565@psf.upfronthosting.co.za> Message-ID: <1334254994.32.0.951868729341.issue14565@psf.upfronthosting.co.za> Changes by Glenn Linderman : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 20:50:39 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 12 Apr 2012 18:50:39 +0000 Subject: [issue14564] Error running: ( echo 'import os'; echo 'help(os)'; )| python |head In-Reply-To: <1334251645.47.0.0743579426512.issue14564@psf.upfronthosting.co.za> Message-ID: <1334256639.75.0.63572119391.issue14564@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Hello, this is not a forum to get help with Python, but to report bugs. In your case, the problem is simply that since help(os) prints more than 10 lines, head exits, and python gets EPIPE when writing to the pipe (which is normal when there's no reader). ---------- nosy: +neologix resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 20:55:30 2012 From: report at bugs.python.org (Joel Lovinger) Date: Thu, 12 Apr 2012 18:55:30 +0000 Subject: [issue14556] telnetlib Telnet.expect fails with timeout=0 In-Reply-To: <1334193617.55.0.736160184516.issue14556@psf.upfronthosting.co.za> Message-ID: <1334256930.53.0.352189299659.issue14556@psf.upfronthosting.co.za> Joel Lovinger added the comment: 2.4 behavior, "time out if there is no more data for X seconds", only worked as expected in the case of timeout=0. Any other timeout could result in indefinite extension and needed fixing. 2.7 behavior, "time out if there is no match for X seconds" fixes timeout!=0 cases while breaking for timeout=0. Can't get former behavior on timeout=0 in 2.7 using socket.settimeout(). Call to socket.recv() then throws a timeout exception which isn't caught by Telnet.expect. I think fixing timeout=0 will require a patch to Telnet.expect. The simplest would likely be to insert a "very eager" type read to grab all data without blocking before entering the match loop. Won't need to modify existing timeout logic and sidesteps any new corner cases on select/recv iteration. The only functional side effect (other than moving storage in some cases from the socket to the Telnet object) is on greedy RE that will have more data to match. Documentation already warns against greedy RE as non-deterministic so hopefully not an issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 21:01:11 2012 From: report at bugs.python.org (Glenn Linderman) Date: Thu, 12 Apr 2012 19:01:11 +0000 Subject: [issue14566] run_cgi reverts to using unnormalized path Message-ID: <1334257271.24.0.449019497726.issue14566@psf.upfronthosting.co.za> New submission from Glenn Linderman : While is_cgi carefully normalizes the path using _url_collapse_path, if it returns True, then run_cgi is called... which sort of starts out using the cgi_info created by is_cgi, but then compares and searches using the original self.path value instead. This effectively bypasses both the normalization done by _url_collapse_path and the bugs and potential security problems that the normalization was intended to fix! A simple cure is to replace the first two lines of run_cgi: path = self.path dir, rest = self.cgi_info with: dir, rest = self.cgi_info path = '/'.join([ dir, rest ]) While this works, one might wonder why is_cgi splits the normalized path into two pieces to start with, if it gets recombined, and generally, dir and rest, although initialized from cgi_info, often get recalculated in the loop which immediately follows in run_cgi... more often than you might expect, if an unnormalized path is in the original request, but if the path comes in normalized (or the above fix is applied), and the CGI program actually resides directly in one of the cgi_directories directories (rather than below it), then the dir and rest calculated by is_cgi are actually used, and the loop performs only one half iteration. ---------- components: Library (Lib) messages: 158162 nosy: orsenthil, v+python priority: normal severity: normal status: open title: run_cgi reverts to using unnormalized path type: security versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 21:02:58 2012 From: report at bugs.python.org (Glenn Linderman) Date: Thu, 12 Apr 2012 19:02:58 +0000 Subject: [issue14565] is_cgi doesn't function as documented for cgi_directories In-Reply-To: <1334254866.64.0.659489278184.issue14565@psf.upfronthosting.co.za> Message-ID: <1334257378.78.0.223127331035.issue14565@psf.upfronthosting.co.za> Glenn Linderman added the comment: Happily, this can be cured by overriding and replacing is_cgi, but it shouldn't be necessary to do so. ---------- components: +Library (Lib) type: -> behavior versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 21:15:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 12 Apr 2012 19:15:50 +0000 Subject: [issue14548] garbage collection just after multiprocessing's fork causes exceptions In-Reply-To: <1334161952.16.0.996503370024.issue14548@psf.upfronthosting.co.za> Message-ID: <1334258150.88.0.478552723168.issue14548@psf.upfronthosting.co.za> Antoine Pitrou added the comment: But what if Finalize is used to cleanup a resource that gets duplicated in children, like a file descriptor? See e.g. forking.py, line 137 (in Popen.__init__()) or heap.py, line 244 (BufferWrapper.__init__()). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 21:44:48 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 12 Apr 2012 19:44:48 +0000 Subject: [issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za> Message-ID: <1334259888.23.0.795346594266.issue9377@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Nick, which version of Python are you using? And which function are you running exactly? It seems that a4fd3dc74299 fixed the issue, this was included with 3.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 21:53:07 2012 From: report at bugs.python.org (Glenn Linderman) Date: Thu, 12 Apr 2012 19:53:07 +0000 Subject: [issue14567] http/server.py query string handling incorrect, inefficient Message-ID: <1334260387.16.0.632012029633.issue14567@psf.upfronthosting.co.za> New submission from Glenn Linderman : A URL potentially consists of four parts: path, PATH_INFO, anchor, QUERY_STRING. The syntax is roughly: /path/parts/cgi-script/path/info/parts#anchor?query-string where # and ? characters play key roles. is_cgi not-so-cleverly passes the whole request to _url_collapse_path for normalization, resulting in inappropriately normalizing the anchor and query-string as well as appropriately normalizing the path and path info parts. Consider that there is no syntax restrictions preventing a query string or anchor from containing / and characters. I contrived such strings, and observed that they were passed to _url_collapse_path and were inappropriately "normalized". Now for non-CGI usage, both the anchor and query-string are ignored by server.py (see translate_path which has code to chop them off). For non-CGI usage, translate_path is called just once, so this isn't particularly inefficient nor is it incorrect. However, for CGI usage it can be both. It is not clear to me why browsers even send the anchor to the server, but they do. Perhaps there are servers that process it, but this one doesn't, in any case I can find, and I'm unaware of semantics applied by any server. Therefore, parsing and ignoring it seems appropriate. Presently, inappropriate normalization of the query-string causes no correctness problem for CGI requests because of issue 14566 which reverts back to the original path. Should issue 14566 be fixed as recommended, certain query-strings will be mangled by the inappropriate normalization. However, even though there is not presently a correctness problem, there is an efficiency problem for CGI requests: the anchor and query-string are both needlessly processed by _url_collapse_path, and potentially repeatedly processed by translate_path in the loop at the top of run_cgi. In fact, it is not exactly clear whether anchors and query-strings containing cleverly crafted / and . and .. combinations might be able to confuse that loop... because translate_path chops them off, but the loop does not! It seems to me that the appropriate place to separate the anchor and query string would be in parse_request. Instead of creating self.command, self.path, self.request_version there, I think it would be better to divide the current content of self.path into three parts: self.path, self.anchor, and self.query_string. self.path, then, would unambiguously contain only path parts, and would be appropriately passed through _url_collapse_path... perhaps even right there in parse_request ... it seems appropriate to normalize the path for reqular files as well as CGI files for all the same reasons. Reasons: 1) no ability to access files outside the configured realm due to malicious use of .. as a path component -- although it seems translate_path prevents this anyway, in a complex manner. 2) proper application of unquote, to allow # and ? characters to exist in path parts, and may also legally be applied to other characters by browser code Neither of these actions are presently performed for regular files, only for CGI files. If the processing happens in parse_request, then other code would be affected: is_cgi would no longer need to call _url_collapse_path, as it would already be done translate_path would no longer need to parse off query strings or anchors, as it would already be done translate_path would no longer need to call urllib.parse.unquote, as it would already be done. run_cgi would no longer need to parse anchor or query, but instead could reference query as self.query_string ---------- components: Library (Lib) messages: 158166 nosy: orsenthil, v+python priority: normal severity: normal status: open title: http/server.py query string handling incorrect, inefficient type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 22:25:58 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Apr 2012 20:25:58 +0000 Subject: [issue14555] clock_gettime/settime/getres: Add more clock identifiers In-Reply-To: <1334183358.11.0.0329195703165.issue14555@psf.upfronthosting.co.za> Message-ID: <1334262358.44.0.776178648333.issue14555@psf.upfronthosting.co.za> STINNER Victor added the comment: more_clock_ids.patch: add more clock identifiers. Don't add the following clocks: CLOCK_BOOTTIME_ALARM, CLOCK_REALTIME_ALARM, CLOCK_UPTIME_FAST, CLOCK_UPTIME_PRECISE, CLOCK_MONOTONIC_PRECISE, CLOCK_REALTIME_PRECISE. The documentation should be improved :-/ ---------- keywords: +patch Added file: http://bugs.python.org/file25196/more_clock_ids.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 22:54:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 12 Apr 2012 20:54:10 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: <1334264050.3.0.471799417241.issue11750@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 23:03:53 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 12 Apr 2012 21:03:53 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334264633.35.0.939795348201.issue14538@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I apologize for misplaced sarcasm. After more careful reading of the source code, I found out that the patch really meets the specifications and the behavior of all tested me browsers. Despite its awkward appearance, the patch fixes a flaw of the original code for this corner case. But it allows the passage of an invalid code in strict mode. I think, this problem can be solved by a more direct way, perhaps even simplifying the original code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 23:04:13 2012 From: report at bugs.python.org (Robin Schreiber) Date: Thu, 12 Apr 2012 21:04:13 +0000 Subject: [issue9303] Migrate sqlite3 module to _v2 API to enhance performance In-Reply-To: <1279541286.68.0.824716490463.issue9303@psf.upfronthosting.co.za> Message-ID: <1334264653.0.0.271599322177.issue9303@psf.upfronthosting.co.za> Robin Schreiber added the comment: Apparently this issue has not been dealt with for quite some time now. As a prospective GSoC student, I still need to submit a patch to pass final screening and I thought, that the needed patch here would be quite suitable for a beginner. I plan to submit a patch, which simply replaces the deprecated method calls with the new ones. Maybe we can also remove some parts of the module code, because of the new semantics of prepare_v2(), however I would first like to hear Gerhards opinion on that :-) ---------- nosy: +Robin.Schreiber _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 23:23:42 2012 From: report at bugs.python.org (Jon Oberheide) Date: Thu, 12 Apr 2012 21:23:42 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334265822.38.0.525967298107.issue14532@psf.upfronthosting.co.za> Jon Oberheide added the comment: Here's a v2 patch. Changes include checking the input types via isinstance, test cases to exercise the type checking, and a note documenting the leak of the input length. ---------- Added file: http://bugs.python.org/file25197/hmac-time-independent-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 23:24:05 2012 From: report at bugs.python.org (Adi Roiban) Date: Thu, 12 Apr 2012 21:24:05 +0000 Subject: [issue14568] HP-UX local libraries not included Message-ID: <1334265845.44.0.154291439069.issue14568@psf.upfronthosting.co.za> New submission from Adi Roiban : Hi, Sorry for bothering you. In my initial report, I did not added /usr/local/lib paths , since I was thinking that Python should only work with the default library location. Now I see that /usr/local is added just at the beginning of module building. The default HPUX system comes with openssl, but for example there is no zlib. Now, on HPUX one can use the Connect archives from http://hpux.connect.org.uk/ They come with a nice tool for providing similar functionality like apt-get or yum. zlib is included in HPUX Connect archive. HPUX Connect packages are installed in /usr/local With the initial code I was able to build hashlib and other extensions using libraries from /usr/local To include /usr/local/lib/hpux* in the path, I also had to add them to self.compiler.library_dirs as otherwise they were not added in LD. I am not sure how it did work in the first place, since on HPUX openssl is in /usr/lib/hpux* and not in /usr/lib/ Here is the code # HP-UX keeps files in lib/hpux folders. if platform == 'hp-ux11': for hpux_path in [ '/usr/lib/hpux64', '/usr/lib/hpux32', '/usr/local/lib/hpux64', '/usr/local/lib/hpux32', ]: lib_dirs += hpux_path add_dir_to_list(self.compiler.library_dirs, hpux_path) With the following code I was able to also build the extensions using libraries from /usr/local on HPUX. I am new to python build system and I am not sure if this is the right way to do it. I am also new to 'hg'. I have pulled the latest changed for cpython but I can not see the previous changes in 'default' branch. I have attached a patch based on 76268:3df2f4a83816 Thanks! Adi ---------- components: Extension Modules files: hpux_local_lib.diff keywords: patch messages: 158171 nosy: adiroiban priority: normal severity: normal status: open title: HP-UX local libraries not included Added file: http://bugs.python.org/file25198/hpux_local_lib.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 23:27:14 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Apr 2012 21:27:14 +0000 Subject: [issue14568] HP-UX local libraries not included In-Reply-To: <1334265845.44.0.154291439069.issue14568@psf.upfronthosting.co.za> Message-ID: <1334266034.35.0.772341884237.issue14568@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 23:34:38 2012 From: report at bugs.python.org (Jason R. Coombs) Date: Thu, 12 Apr 2012 21:34:38 +0000 Subject: [issue14444] Virtualenv not portable from Python 2.7.2 to 2.7.3 (os.urandom missing) In-Reply-To: <1333039292.27.0.93471346907.issue14444@psf.upfronthosting.co.za> Message-ID: <1334266478.75.0.955749480995.issue14444@psf.upfronthosting.co.za> Jason R. Coombs added the comment: For posterity, here's the release notes that we had drafted on the pirate pad: Note: This patch release of Python may have compatibility implications for environments utilizing the third-party virtualenv. For more detail see XXX. [the note above is intended to be included as a line-item in the release notes, referencing the file below] Upgrade issues with virtualenv ====================== In order to enact a security fix in Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3, the implementation of os.urandom was updated. The implementation of urandom was moved from the os module (Python stdlib) to the posix module (built in to the Python executable binary). As a result, when upgrading a host to one of these new Python versions, virtual environments created with earlier versions of Python will now be missing os.urandom. This issue only exists for Unix hosts. This happens because the virtualenv bundles the older Python executable (which does not have an implementation of urandom), but then references the newer standard library (in which the os module also does not have an implementation of urandom). In environments where this error occurs, the error is most likely exhibited as an AttributeError: $ $ENV/bin/python -c "import os; os.urandom" Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'urandom' Workaround ========= The workaround is to remove the 'python' binary from $ENV/bin and re-run virtualenv for the required Python version or versions on that environment. For example: $ rm $ENV/bin/python $ virtualenv --python python2.7 $ENV It's necessary to remove the main python binary because virtualenv will not replace it if it already exists. If the virtualenv contained multiple Python versions, run virtualenv on it again with each Python. If the --distribute flag was used in the initial creation of the virtualenv, use it again here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 23:42:16 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 12 Apr 2012 21:42:16 +0000 Subject: [issue14563] Segmentation fault on ctypes.Structure subclass with byte string field names In-Reply-To: <1334236262.62.0.0349212060005.issue14563@psf.upfronthosting.co.za> Message-ID: <1334266936.31.0.824311972891.issue14563@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This is a duplicate of issue12764, which was already fixed for 3.2.2 (in September 2011) Which version of python are you using exactly? What does "import platform; platform.python_revision()" return? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 23:49:07 2012 From: report at bugs.python.org (Jim Jewett) Date: Thu, 12 Apr 2012 21:49:07 +0000 Subject: [issue14569] pystate.c #ifdef ordering problem Message-ID: <1334267347.56.0.554739208984.issue14569@psf.upfronthosting.co.za> New submission from Jim Jewett : The C linkage is guarded by WITH_THREAD. The 'extern "C" {' and '}' declarations should be in effect regardless of threading. Note that the bug can only be triggered by compiling without threads, but with a C++ compiler; this is obscure enough that I don't feel strongly about backporting. ---------- components: Interpreter Core keywords: easy messages: 158174 nosy: Jim.Jewett priority: normal severity: normal status: open title: pystate.c #ifdef ordering problem versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 23:52:14 2012 From: report at bugs.python.org (Nick) Date: Thu, 12 Apr 2012 21:52:14 +0000 Subject: [issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za> Message-ID: <1334267534.32.0.327031999875.issue9377@psf.upfronthosting.co.za> Nick added the comment: Originally I tried 3.2.2 (32bit), but I've just checked 3.2.3 and got the same. A code for reproduce is simple: from socket import gethostbyaddr a = gethostbyaddr('127.0.0.1') leads to: Traceback (most recent call last): File "C:\Users\user\test\test.py", line 13, in a = gethostbyaddr('127.0.0.1') UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcf in position 5: invalid continuation byte Or more complex sample: def main(): import http.server port = 80 handlerClass = http.server.SimpleHTTPRequestHandler srv = http.server.HTTPServer(("", port), handlerClass ) srv.serve_forever() if __name__ == "__main__": main() Attempt of connection to the server leads to: ---------------------------------------- Exception happened during processing of request from ('127.0.0.1', 1156) Traceback (most recent call last): File "C:\Python32\lib\socketserver.py", line 284, in _handle_request_noblock self.process_request(request, client_address) File "C:\Python32\lib\socketserver.py", line 310, in process_request self.finish_request(request, client_address) File "C:\Python32\lib\socketserver.py", line 323, in finish_request self.RequestHandlerClass(request, client_address, self) File "C:\Python32\lib\socketserver.py", line 637, in __init__ self.handle() File "C:\Python32\lib\http\server.py", line 396, in handle self.handle_one_request() File "C:\Python32\lib\http\server.py", line 384, in handle_one_request method() File "C:\Python32\lib\http\server.py", line 657, in do_GET f = self.send_head() File "C:\Python32\lib\http\server.py", line 701, in send_head self.send_response(200) File "C:\Python32\lib\http\server.py", line 438, in send_response self.log_request(code) File "C:\Python32\lib\http\server.py", line 483, in log_request self.requestline, str(code), str(size)) File "C:\Python32\lib\http\server.py", line 517, in log_message (self.address_string(), File "C:\Python32\lib\http\server.py", line 559, in address_string return socket.getfqdn(host) File "C:\Python32\lib\socket.py", line 355, in getfqdn hostname, aliases, ipaddrs = gethostbyaddr(name) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcf in position 5: invalid continuation byte ---------------------------------------- P.S. My PC name is "USER-??" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 23:52:42 2012 From: report at bugs.python.org (Jim Jewett) Date: Thu, 12 Apr 2012 21:52:42 +0000 Subject: [issue14569] pystate.c #ifdef ordering problem In-Reply-To: <1334267347.56.0.554739208984.issue14569@psf.upfronthosting.co.za> Message-ID: <1334267562.49.0.738256962855.issue14569@psf.upfronthosting.co.za> Jim Jewett added the comment: http://hg.python.org/cpython/file/0f114b855824/Python/pystate.c#l25 #ifdef WITH_THREAD #include "pythread.h" static PyThread_type_lock head_mutex = NULL; /* Protects interp->tstate_head */ #define HEAD_INIT() (void)(head_mutex || (head_mutex = PyThread_allocate_lock())) #define HEAD_LOCK() PyThread_acquire_lock(head_mutex, WAIT_LOCK) #define HEAD_UNLOCK() PyThread_release_lock(head_mutex) #ifdef __cplusplus extern "C" { #endif ---------- priority: normal -> low stage: -> needs patch type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 23:53:54 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 12 Apr 2012 21:53:54 +0000 Subject: [issue9960] test_structmembers fails on s390x (bigendian 64-bit): int/Py_ssize_t issue In-Reply-To: <1285600296.08.0.731959847047.issue9960@psf.upfronthosting.co.za> Message-ID: <1334267634.8.0.69560727969.issue9960@psf.upfronthosting.co.za> Dave Malcolm added the comment: The originally attached patch is no good for the the 2.* branch, as it appears that _testcapimodule.c will not become "ssize_t" safe in Python 2.*; see e.g.: http://hg.python.org/cpython/rev/3ecddf168f1f Am attaching a revised patch that I'm applying downstream in Fedora's builds of 2.7.3 ---------- Added file: http://bugs.python.org/file25199/fix-test_structmember-on-64bit-bigendian.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 23:55:14 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Apr 2012 21:55:14 +0000 Subject: [issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za> Message-ID: <1334267714.16.0.184842169212.issue9377@psf.upfronthosting.co.za> STINNER Victor added the comment: a4fd3dc74299 only fixed socket.gethostname(), not socket.gethostbyaddr(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 12 23:56:15 2012 From: report at bugs.python.org (Adi Roiban) Date: Thu, 12 Apr 2012 21:56:15 +0000 Subject: [issue12991] Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler In-Reply-To: <1316173380.25.0.744886006815.issue12991@psf.upfronthosting.co.za> Message-ID: <1334267775.57.0.53193216789.issue12991@psf.upfronthosting.co.za> Changes by Adi Roiban : ---------- nosy: +adiroiban _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 00:02:13 2012 From: report at bugs.python.org (Adi Roiban) Date: Thu, 12 Apr 2012 22:02:13 +0000 Subject: [issue9123] insecure os.urandom on VMS In-Reply-To: <1277869715.19.0.305414138773.issue9123@psf.upfronthosting.co.za> Message-ID: <1334268133.86.0.211859600857.issue9123@psf.upfronthosting.co.za> Changes by Adi Roiban : ---------- nosy: +adiroiban _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 00:03:09 2012 From: report at bugs.python.org (Adi Roiban) Date: Thu, 12 Apr 2012 22:03:09 +0000 Subject: [issue1572968] release GIL while doing I/O operations in the mmap module Message-ID: <1334268189.68.0.909804850698.issue1572968@psf.upfronthosting.co.za> Changes by Adi Roiban : ---------- nosy: +adiroiban _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 00:04:49 2012 From: report at bugs.python.org (Adi Roiban) Date: Thu, 12 Apr 2012 22:04:49 +0000 Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za> Message-ID: <1334268289.54.0.600369619468.issue5113@psf.upfronthosting.co.za> Adi Roiban added the comment: I am not sure how the search works, but for example I was not able to reach http://bugs.python.org/issue5895 while searching for hpux or hp-ux using the internal search. Also I was not able to find any aix or solaris bug. In case you bump over an hpux, aix, solaris bug, please add me to the noisy list and I will take a look. Thanks! Adi ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 00:30:10 2012 From: report at bugs.python.org (sbt) Date: Thu, 12 Apr 2012 22:30:10 +0000 Subject: [issue14548] garbage collection just after multiprocessing's fork causes exceptions In-Reply-To: <1334161952.16.0.996503370024.issue14548@psf.upfronthosting.co.za> Message-ID: <1334269810.74.0.569809857732.issue14548@psf.upfronthosting.co.za> sbt added the comment: > But what if Finalize is used to cleanup a resource that gets > duplicated in children, like a file descriptor? > See e.g. forking.py, line 137 (in Popen.__init__()) > or heap.py, line 244 (BufferWrapper.__init__()). This was how Finalize objects already acted (or were supposed to). In the case of BufferWrapper this is intended. BufferWrapper objects do not have reference counting semantics. Instead the memory is deallocated when the object is garbage collected in the process that created it. (Garbage collection in a child process should *not* invalidate memory owned by the parent process.) You can prevent the parent process from garbage collecting the object too early by following the advice below from the documentation: Explicitly pass resources to child processes On Unix a child process can make use of a shared resource created in a parent process using a global resource. However, it is better to pass the object as an argument to the constructor for the child process. Apart from making the code (potentially) compatible with Windows this also ensures that as long as the child process is still alive the object will not be garbage collected in the parent process. This might be important if some resource is freed when the object is garbage collected in the parent process. In the case of the sentinel in Popen.__init__(), it is harmless if this end of the pipe gets accidentally inherited by another process. Since Process does not have a closefds argument like subprocess.Popen unintended leaking happens all the time. And even without the pid check, I think this finalizer would very rarely be triggered in a child process. (A Process object can only be garbage collected after it has been joined, and it can only be joined by it parent process.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 00:31:46 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 12 Apr 2012 22:31:46 +0000 Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za> Message-ID: <1334269906.71.0.843343844769.issue5113@psf.upfronthosting.co.za> R. David Murray added the comment: Search is currently not returning all matching issues, unfortunately. You might get a few more hits by searching for hpux in the title field via advanced search. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 00:45:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 12 Apr 2012 22:45:20 +0000 Subject: [issue14399] zipfile and creat/update comment In-Reply-To: <1332606431.21.0.286905846716.issue14399@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset ac0ec1f31b0a by R David Murray in branch '2.7': #14399: zipfile now correctly handles comments added to empty zipfiles. http://hg.python.org/cpython/rev/ac0ec1f31b0a New changeset 4186f20d9fa4 by R David Murray in branch '3.2': #14399: zipfile now correctly handles comments added to empty zipfiles. http://hg.python.org/cpython/rev/4186f20d9fa4 New changeset e5b30d4b0647 by R David Murray in branch 'default': Merge #14399: zipfile now correctly handles comments added to empty zipfiles. http://hg.python.org/cpython/rev/e5b30d4b0647 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 00:47:16 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 12 Apr 2012 22:47:16 +0000 Subject: [issue14399] zipfile and creat/update comment In-Reply-To: <1332606431.21.0.286905846716.issue14399@psf.upfronthosting.co.za> Message-ID: <1334270836.35.0.891841137532.issue14399@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Serhiy. I made one small change, using 'with self.assertEqual' in the TypeError test. You might want to check that out, it is a useful technique. Oh, and I removed the type check from the 2.7 patch. You can use a unicode string as long as it doesn't contain non-ASCII (the reason we created python3!), so it would be a backward incompatible change to raise a TypeError there. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 00:54:44 2012 From: report at bugs.python.org (aliles) Date: Thu, 12 Apr 2012 22:54:44 +0000 Subject: [issue14563] Segmentation fault on ctypes.Structure subclass with byte string field names In-Reply-To: <1334236262.62.0.0349212060005.issue14563@psf.upfronthosting.co.za> Message-ID: <1334271284.66.0.470305193323.issue14563@psf.upfronthosting.co.za> aliles added the comment: Should I build a version from the tip of the 3.2 or default branch on hg.python.org? This version is Python 3.2.2 built using homebrew. The revision is being reported as an empty string. Python 3.2.2 (default, Dec 18 2011, 18:56:20) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import platform >>> platform.python_revision() '' >>> platform.python_version_tuple() ('3', '2', '2') >>> platform.python_build() ('default', 'Dec 18 2011 18:56:20') >>> platform.release() '11.3.0' >>> platform.version() 'Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64' Sorry, I did a search but didn't find issue12764. :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 01:26:37 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 12 Apr 2012 23:26:37 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334273197.95.0.798547085793.issue14538@psf.upfronthosting.co.za> Ezio Melotti added the comment: Attached a new patch with a few more tests and a simplification of the attrfind regex. > But it allows the passage of an invalid code in strict mode. HTMLParser is following the HTML5 specs, and doesn't do validation, so there's no strict mode (and the strict mode of Python 3 will be removed/deprecated soon). > I think, this problem can be solved by a more direct way, > perhaps even simplifying the original code. This might be true, but I'm quite happy with this patch for now. Maybe one day I'll rewrite it. > Unless there is a specification somewhere (or at least an editor's > draft), I can't really see any particular parse as a bugfix. If HTMLParser doesn't parse as the HTML5 specs say, then it's considered a bug. ---------- Added file: http://bugs.python.org/file25200/issue14538-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 01:39:50 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 12 Apr 2012 23:39:50 +0000 Subject: [issue1559549] ImportError needs attributes for module and file name Message-ID: <1334273990.53.0.765891105156.issue1559549@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: brian.curtin -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 01:43:55 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Apr 2012 23:43:55 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334274235.67.0.893323412756.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: Patch version 7: - Add time.perf_counter() and time.process_time() - Replace "accuracy" key with "precision" in time.get_clock_info() result ---------- Added file: http://bugs.python.org/file25201/pep418-7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 01:49:37 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 12 Apr 2012 23:49:37 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334274577.83.0.731550571507.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: perf_counter_process_time.patch: replace "time.clock if windows else time.time" with time.perf_counter, and getrusage/clock with time.process_time. pybench and timeit now use time.perf_counter() by default. profile uses time.proces_time() by default. pybench uses time.get_clock_info() to display the precision and the underlying C function (or the resolution if the precision is not available). Tools/pybench/systimes.py and Tools/pybench/clockres.py may be removed: these features are now available directly in the time module. ---------- Added file: http://bugs.python.org/file25202/perf_counter_process_time.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 02:25:14 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 13 Apr 2012 00:25:14 +0000 Subject: [issue1559549] ImportError needs attributes for module and file name Message-ID: Roundup Robot added the comment: New changeset 6825fd9b00ed by Brett Cannon in branch 'default': Issue #1559549: Add 'name' and 'path' attributes to ImportError. http://hg.python.org/cpython/rev/6825fd9b00ed ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 02:27:13 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 13 Apr 2012 00:27:13 +0000 Subject: [issue1559549] ImportError needs attributes for module and file name Message-ID: <1334276833.93.0.466002968503.issue1559549@psf.upfronthosting.co.za> Brett Cannon added the comment: Patch for the attributes is in (no use by import.c)! I'm going to do a separate commit for use by importlib and then fix pydoc in my bootstrap branch. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 02:32:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 13 Apr 2012 00:32:09 +0000 Subject: [issue14559] (2.7.3 Regression) PC\8.0 directory can no longer be used to build on windows In-Reply-To: <1334215463.37.0.843460683269.issue14559@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 9a6dc460ecb2 by Amaury Forgeot d'Arc in branch '2.7': Issue14559: Attempt to fix compilation with previous versions of the Microsoft Compiler. http://hg.python.org/cpython/rev/9a6dc460ecb2 New changeset 178acd78144b by Amaury Forgeot d'Arc in branch '3.2': Issue14559: Fix build files old Microft compilers. http://hg.python.org/cpython/rev/178acd78144b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 03:38:54 2012 From: report at bugs.python.org (Adi Roiban) Date: Fri, 13 Apr 2012 01:38:54 +0000 Subject: [issue14568] HP-UX local libraries not included In-Reply-To: <1334265845.44.0.154291439069.issue14568@psf.upfronthosting.co.za> Message-ID: <1334281134.4.0.973991197691.issue14568@psf.upfronthosting.co.za> Adi Roiban added the comment: Hi, There was an error in the patch. Instead of lib_dirs += hpux_path it should be: lib_dirs += [hpux_path] Cheers, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 03:49:13 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 13 Apr 2012 01:49:13 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1334281753.6.0.977477373112.issue13903@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Moving the "assigned to" to "nobody". I won't have a chance for a thorough review for another ten days. Hopefully, someone else will have a chance to review it before then. ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 04:31:02 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 13 Apr 2012 02:31:02 +0000 Subject: [issue14399] zipfile and creat/update comment In-Reply-To: <1332606431.21.0.286905846716.issue14399@psf.upfronthosting.co.za> Message-ID: <1334284262.96.0.391173840123.issue14399@psf.upfronthosting.co.za> R. David Murray added the comment: I mean "with self.assertRaises(TypeError):". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 04:42:27 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 13 Apr 2012 02:42:27 +0000 Subject: [issue14570] Document json "sort_keys" parameter properly Message-ID: <1334284947.71.0.88941407788.issue14570@psf.upfronthosting.co.za> New submission from Nick Coghlan : The json "sort_keys" parameter is actually supported as an argument to dump() and dumps() (and is used that way in the examples), but is only documented as an argument to the JSONEncoder constructor. ---------- assignee: docs at python components: Documentation keywords: easy messages: 158194 nosy: docs at python, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Document json "sort_keys" parameter properly type: enhancement versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 04:55:34 2012 From: report at bugs.python.org (Jim Jewett) Date: Fri, 13 Apr 2012 02:55:34 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334273197.95.0.798547085793.issue14538@psf.upfronthosting.co.za> Message-ID: Jim Jewett added the comment: On Thu, Apr 12, 2012 at 7:26 PM, Ezio Melotti wrote: > If HTMLParser doesn't parse as the HTML5 specs say, > then it's considered a bug. I had thought that was the goal of the html5lib, and that HTMLParser was explicitly aiming at a much reduced model in order to remain simple. (And also because the HTML5 spec is still changing fairly often, particularly compared to the lifecycle of a feature release of python.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 07:34:31 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Apr 2012 05:34:31 +0000 Subject: [issue14399] zipfile and creat/update comment In-Reply-To: <1334284262.96.0.391173840123.issue14399@psf.upfronthosting.co.za> Message-ID: <1334295415.2401.4.camel@raxxla> Serhiy Storchaka added the comment: > I mean "with self.assertRaises(TypeError):". Thank you, I did not know that the context managers may catch exceptions from the nested block. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 07:43:33 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 13 Apr 2012 05:43:33 +0000 Subject: [issue14399] zipfile and creat/update comment In-Reply-To: Message-ID: <1334295958.2401.13.camel@raxxla> Serhiy Storchaka added the comment: > #14399: zipfile now correctly handles comments added to empty zipfiles. This is a wrong description of the issue. On the contrary, the error occurred when adding or changing the comment in a *non-empty* zipfile without adding or changing files. Description in the Misc/NEWS also wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 08:20:33 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 13 Apr 2012 06:20:33 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334298033.56.0.684135759557.issue14538@psf.upfronthosting.co.za> Ezio Melotti added the comment: HTMLParser is still simpler than html5lib, but if/when possible we are following the HTML5 standard rather than taking arbitrary decisions (like we used to do before HTML5). HTMLParser doesn't claim to be a fully compliant HTML5 parser (and probably never will) -- its goal is rather being able to parse real world HTML in the same way browsers do. There are also a couple of corner cases that are not implemented in HTMLParser because it would make the code too complicated for a little gain. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 08:38:27 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 13 Apr 2012 06:38:27 +0000 Subject: [issue14570] Document json "sort_keys" parameter properly In-Reply-To: <1334284947.71.0.88941407788.issue14570@psf.upfronthosting.co.za> Message-ID: <1334299107.53.0.0478503482278.issue14570@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 10:02:47 2012 From: report at bugs.python.org (Glenn Linderman) Date: Fri, 13 Apr 2012 08:02:47 +0000 Subject: [issue14567] http/server.py query string handling incorrect, inefficient In-Reply-To: <1334260387.16.0.632012029633.issue14567@psf.upfronthosting.co.za> Message-ID: <1334304167.85.0.0823682408865.issue14567@psf.upfronthosting.co.za> Glenn Linderman added the comment: A bit of experimentation indicates that for regular file access, there probably is no security problem, but bad paths will look in weird places, and if they find a file of the right name, will return it. It would be much better to diagnose such paths. There is even a comment to that effect in translate_path. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 10:13:58 2012 From: report at bugs.python.org (Dirkjan Ochtman) Date: Fri, 13 Apr 2012 08:13:58 +0000 Subject: [issue1222585] C++ compilation support for distutils Message-ID: <1334304838.43.0.582021044417.issue1222585@psf.upfronthosting.co.za> Dirkjan Ochtman added the comment: Ping, again. I'm sorry, I didn't write any of these patches and would not be a great fit for writing tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 10:26:25 2012 From: report at bugs.python.org (Dirkjan Ochtman) Date: Fri, 13 Apr 2012 08:26:25 +0000 Subject: [issue1762561] unable to serialize Infinity or NaN on ARM using marshal Message-ID: <1334305585.37.0.204296916227.issue1762561@psf.upfronthosting.co.za> Dirkjan Ochtman added the comment: Could we reconsider ARM support at this time? Seems like ARM support has been surging over the past few years, and it's becoming more supported by Linux distributions. Seems like a pity to leave a patch like this out here. ---------- nosy: +djc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 10:58:25 2012 From: report at bugs.python.org (Glenn Linderman) Date: Fri, 13 Apr 2012 08:58:25 +0000 Subject: [issue14567] http/server.py query string handling incorrect, inefficient In-Reply-To: <1334260387.16.0.632012029633.issue14567@psf.upfronthosting.co.za> Message-ID: <1334307505.0.0.455149916981.issue14567@psf.upfronthosting.co.za> Glenn Linderman added the comment: I finally understand the purpose of the checks in translate path... Basically, translate path is concatenating the URL path to the current directory (because that is considered the root for Web service by this server). But along the way, it does normalization (redundantly compared to _url_collapse_path, but for a different code path, and sadly, using a different algorithm that gets different results), and os-specific checks. For the os-specific checks, it does a couple splits to see if each path component contains a drive letter or "character other than / that is used as a directory separator", or contains "." or ".." (os specific versions). It doesn't check for os-specific illegal filename characters (but of course they will not match existing files on the OS, so that eventually would cause a 404). Such checks are probably best done only on path components that are actually traversed, the only problem is that increasingly large subsets of the path are passed to translate_path by run_cgi so the net effect is an O(n-squared) performance characteristic: most actual paths do not get too long, happily, but it is still inefficient. Factoring out the checks into a function that could be called by translate path or run_cgi might be appropriate, and then run_cgi could call the new function piece by piece instead of calling translate_path at all. It would also be good to make translate path produce an error if "drive" or "head" are ever non-empty. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 11:43:25 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 13 Apr 2012 09:43:25 +0000 Subject: [issue9123] insecure os.urandom on VMS In-Reply-To: <1277869715.19.0.305414138773.issue9123@psf.upfronthosting.co.za> Message-ID: <1334310205.35.0.552513022735.issue9123@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo stage: -> patch review versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 11:58:31 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Apr 2012 09:58:31 +0000 Subject: [issue9123] insecure os.urandom on VMS In-Reply-To: <1277869715.19.0.305414138773.issue9123@psf.upfronthosting.co.za> Message-ID: <1334311111.61.0.0949501405666.issue9123@psf.upfronthosting.co.za> STINNER Victor added the comment: > This issue is a security vulnerability. I disagree, it's just an issue of a comment in the C code. The Python documentation doesn't guarantee that os.urandom() is cryptographic. Use ssl.RAND_bytes(), added to Python 3.3, if you need cryptographic random numbers. By the way, VMS is no more supported in Python 3.3, see the PEP 11: Name: VMS Unsupported in: Python 3.3 Code removed in: Python 3.4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 12:00:15 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Apr 2012 10:00:15 +0000 Subject: [issue9123] insecure os.urandom on VMS In-Reply-To: <1277869715.19.0.305414138773.issue9123@psf.upfronthosting.co.za> Message-ID: <1334311215.55.0.766622889998.issue9123@psf.upfronthosting.co.za> STINNER Victor added the comment: - if (RAND_pseudo_bytes((unsigned char*) + if (RAND_bytes((unsigned char*) This is not a good idea: RAND_bytes() is blocking, whereas os.urandom() doesn't block on other platforms. os.urandom() is similar to /dev/urandom (non blocking), whereas /dev/random is blocking. With this patch, Python may block at startup if there is not enough entropy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 12:19:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 13 Apr 2012 10:19:33 +0000 Subject: [issue14569] pystate.c #ifdef ordering problem In-Reply-To: <1334267347.56.0.554739208984.issue14569@psf.upfronthosting.co.za> Message-ID: <1334312373.76.0.210220439888.issue14569@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't think you need anyone's permission to commit such a fix :) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 13:05:02 2012 From: report at bugs.python.org (sbt) Date: Fri, 13 Apr 2012 11:05:02 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: <1334315102.35.0.66426420336.issue11750@psf.upfronthosting.co.za> sbt added the comment: I think there are some issues with the treatment of the DWORD type. (DWORD is a typedef for unsigned long.) _subprocess always treats them as signed, whereas _multiprocessing treats them (correctly) as unsigned. _windows does a mixture: functions from _subprocess parse DWORD arguments as signed ("i"), functions from _multiprocessing parse DWORD arguments as unsigned ("k"), and the constants are signed. So in _windows the constants GENERIC_READ, NMPWAIT_WAIT_FOREVER and INFINITE will be negative. I think this will potentially cause errors from PyArg_ParseTuple() when used as arguments to functions from _multiprocessing. I think it is also rather confusing that some functions (eg CreatePipe()) return handles using a wrapper type which closes on garbage collection, while others (eg CreateNamedPipe()) return handles as plain integers. (The code also needs updating because quite a few functions have since been added to _multiprocessing.win32.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 14:46:47 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 13 Apr 2012 12:46:47 +0000 Subject: [issue14157] time.strptime without a year fails on Feb 29 In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za> Message-ID: <1334321207.36.0.981701575629.issue14157@psf.upfronthosting.co.za> Hynek Schlawack added the comment: The point isn?t that time.strptime validates dates but that it uses datetime internally: julian = datetime_date(year, month, day).toordinal() - \ datetime_date(year, 1, 1).toordinal() + 1 Is it worth to reimplement this functionality? It strikes easier to me to just use a different year if year is undefined and date == Feb 29. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 14:47:31 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 13 Apr 2012 12:47:31 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1334321251.49.0.944856670777.issue13405@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Added file: http://bugs.python.org/file25203/4a072278b866.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 14:47:48 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 13 Apr 2012 12:47:48 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1334321268.64.0.747998723701.issue13405@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Removed file: http://bugs.python.org/file25193/1e4d2c51b2d9.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 15:25:29 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 13 Apr 2012 13:25:29 +0000 Subject: [issue14399] zipfile and creat/update comment In-Reply-To: <1332606431.21.0.286905846716.issue14399@psf.upfronthosting.co.za> Message-ID: <1334323529.15.0.450094904532.issue14399@psf.upfronthosting.co.za> R. David Murray added the comment: Ah. I based that on the fact that the third test passed without the change. I thought you were adding that test of changing the comment just as a double check. I should have asked instead of assuming. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 17:59:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 13 Apr 2012 15:59:58 +0000 Subject: [issue14569] pystate.c #ifdef ordering problem In-Reply-To: <1334267347.56.0.554739208984.issue14569@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 5cc359804d61 by Benjamin Peterson in branch '3.2': take linkage def outside of WITH_THREAD conditional (closes #14569) http://hg.python.org/cpython/rev/5cc359804d61 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 18:00:56 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 13 Apr 2012 16:00:56 +0000 Subject: [issue14569] pystate.c #ifdef ordering problem In-Reply-To: <1334267347.56.0.554739208984.issue14569@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 508ae5d27c2c by Benjamin Peterson in branch '2.7': take linkage def outside of WITH_THREAD conditional (closes #14569) http://hg.python.org/cpython/rev/508ae5d27c2c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:02:31 2012 From: report at bugs.python.org (s7v7nislands) Date: Fri, 13 Apr 2012 17:02:31 +0000 Subject: [issue14499] Extension module builds fail with Xcode 4.3 on OS X 10.7 due to SDK move In-Reply-To: <1333576900.91.0.0583021085072.issue14499@psf.upfronthosting.co.za> Message-ID: <1334336551.96.0.869764304201.issue14499@psf.upfronthosting.co.za> s7v7nislands added the comment: maybe you can use xcode-select to set the correct path xcode-select -print-path /Applications/Xcode.app/Contents/Developer Usage: xcode-select -print-path or: xcode-select -switch -switch Sets the path for the current Xcode for detail, you can man xcode-select ---------- nosy: +s7v7nislands _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:02:37 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 13 Apr 2012 17:02:37 +0000 Subject: [issue14519] In re's examples the example with scanf() contains wrong analog for %x, %X specifiers In-Reply-To: <1333757996.58.0.360922081437.issue14519@psf.upfronthosting.co.za> Message-ID: <1334336557.92.0.180780675871.issue14519@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I checked Standard C by Plauger & Brodie and as I read it, it agrees with py.user and his C compiler. For stdlib strtol() and strtoul(), the 0x/0X prefixes are accepted but optional for explicit base 16. If base is given as 0, they are accepted and set the base to 16 (which is otherwise 10). Except for %i, Xscanf functions apparently call either of the above with an explicit base, which is 16 for the %x specifiers. ---------- keywords: +easy, patch nosy: +terry.reedy stage: -> needs patch versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:07:14 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 13 Apr 2012 17:07:14 +0000 Subject: [issue14525] ia64-hp-hpux11.31 won't compile Python-2.6.8rc2 without -D_TERMIOS_INCLUDED In-Reply-To: <1333850075.77.0.408518012212.issue14525@psf.upfronthosting.co.za> Message-ID: <1334336834.02.0.383475271603.issue14525@psf.upfronthosting.co.za> Terry J. Reedy added the comment: patch should be for 2.7 or 3.2/3 as 2.6 only gets security fixes. ---------- nosy: +terry.reedy stage: -> needs patch versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:18:24 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 13 Apr 2012 17:18:24 +0000 Subject: [issue14544] Limit "global" keyword name conflicts in language spec to those enforced by CPython In-Reply-To: <1334119591.44.0.0449104949206.issue14544@psf.upfronthosting.co.za> Message-ID: <1334337504.91.0.113802673172.issue14544@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:22:03 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 13 Apr 2012 17:22:03 +0000 Subject: [issue14535] three code examples in docs are not syntax highlighted In-Reply-To: <1333981665.2.0.806826898617.issue14535@psf.upfronthosting.co.za> Message-ID: <1334337723.49.0.40177039796.issue14535@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:32:46 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 13 Apr 2012 17:32:46 +0000 Subject: [issue14542] reverse() doesn't reverse sort correctly In-Reply-To: <1334092948.92.0.355966941096.issue14542@psf.upfronthosting.co.za> Message-ID: <1334338366.65.0.227240291522.issue14542@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Bill, when you reply by email, please snip the signature and quoted message. They are just noise. (Exception: quote a line or two if you are specifically responding to such.) Signatures are inappropriate, and the message you are responding to is already present. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:34:02 2012 From: report at bugs.python.org (Jim Jewett) Date: Fri, 13 Apr 2012 17:34:02 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334338442.85.0.128304632835.issue14538@psf.upfronthosting.co.za> Jim Jewett added the comment: It sounds like this is a case where the docs should mention an external library; perhaps something like changing the intro of http://docs.python.org/dev/library/html.parser.html from: """ 19.2. html.parser ? Simple HTML and XHTML parser Source code: Lib/html/parser.py This module defines a class HTMLParser which serves as the basis for parsing text files formatted in HTML (HyperText Mark-up Language) and XHTML. """ to: """ 19.2. html.parser ? Simple HTML and XHTML parser Source code: Lib/html/parser.py This module defines a class HTMLParser which serves as the basis for parsing text files formatted in HTML (HyperText Mark-up Language) and XHTML. Note that mainstream web browsers also attempt to repair invalid markup; the algorithms for this can be quite complex, and are evolving too quickly for the Python release cycle. Applications handling arbitrary web pages should consider using 3rd-party modules. The python version of html5lib ( http://code.google.com/p/html5lib/ ) is being developed in parallel with the HTML standard itself, and serves as a reference implementation. """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:42:27 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 13 Apr 2012 17:42:27 +0000 Subject: [issue14535] three code examples in docs are not syntax highlighted In-Reply-To: <1333981665.2.0.806826898617.issue14535@psf.upfronthosting.co.za> Message-ID: <1334338947.07.0.037753074095.issue14535@psf.upfronthosting.co.za> Tshepang Lekhonkhobe added the comment: This is probably because Sphinx can't detect that those are Python sources, so my patch forces it to recognize it as such. ---------- keywords: +patch Added file: http://bugs.python.org/file25204/highlight-code.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:42:44 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 13 Apr 2012 17:42:44 +0000 Subject: [issue14567] http/server.py query string handling incorrect, inefficient In-Reply-To: <1334260387.16.0.632012029633.issue14567@psf.upfronthosting.co.za> Message-ID: <1334338964.91.0.0297749808334.issue14567@psf.upfronthosting.co.za> ?ric Araujo added the comment: > /path/parts/cgi-script/path/info/parts#anchor?query-string This should be: /path/parts/cgi-script/path/info/parts?query-string#anchor ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:43:00 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 13 Apr 2012 17:43:00 +0000 Subject: [issue14567] http.server query string handling incorrect and inefficient In-Reply-To: <1334260387.16.0.632012029633.issue14567@psf.upfronthosting.co.za> Message-ID: <1334338980.91.0.583595801896.issue14567@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- title: http/server.py query string handling incorrect, inefficient -> http.server query string handling incorrect and inefficient versions: -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:44:05 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 13 Apr 2012 17:44:05 +0000 Subject: [issue14554] test module: correction In-Reply-To: <1334181755.32.0.776262768406.issue14554@psf.upfronthosting.co.za> Message-ID: <1334339045.09.0.984836602645.issue14554@psf.upfronthosting.co.za> ?ric Araujo added the comment: LGTM ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:44:53 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 13 Apr 2012 17:44:53 +0000 Subject: [issue14547] Python symlink to script behaves unexpectedly In-Reply-To: <1334155369.29.0.554259242167.issue14547@psf.upfronthosting.co.za> Message-ID: <1334339093.81.0.375257450708.issue14547@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:48:33 2012 From: report at bugs.python.org (Rik Poggi) Date: Fri, 13 Apr 2012 17:48:33 +0000 Subject: [issue11218] pattern=None when following documentation for load_tests and unittest.main() In-Reply-To: <1297758807.39.0.713611114484.issue11218@psf.upfronthosting.co.za> Message-ID: <1334339313.11.0.961395328685.issue11218@psf.upfronthosting.co.za> Rik Poggi added the comment: I wasn't trying to make any argument, just thinking that such particular signature was intentional. Also notice that there might be code that doesn't pass the pattern argument, and fall back on the default value. So a signature change will break their code. I think that the best solution would be to provide a better documentation. I don't know what's the rational behind all that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:50:31 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 13 Apr 2012 17:50:31 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334339431.69.0.239146448859.issue14538@psf.upfronthosting.co.za> ?ric Araujo added the comment: Sure, the docs should explain better that html.parser tries its best to parse stuff, is not a validating parser, and is actively developed, contrary to the popular belief that standard library modules never get improved. I?m less sure about links, there is more than one popular library (html5lib, lxml, BeautifulSoup). Another bug needs to be opened, we?re off-topic for this one ? but thanks for the remark and proposed patch. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:52:02 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 13 Apr 2012 17:52:02 +0000 Subject: [issue14535] three code examples in docs are not syntax highlighted In-Reply-To: <1333981665.2.0.806826898617.issue14535@psf.upfronthosting.co.za> Message-ID: <1334339522.56.0.459026707125.issue14535@psf.upfronthosting.co.za> ?ric Araujo added the comment: LGTM ---------- nosy: +eric.araujo stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:54:09 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 13 Apr 2012 17:54:09 +0000 Subject: [issue14534] Add method to mark unittest.TestCases as "do not run". In-Reply-To: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za> Message-ID: <1334339649.62.0.339765674673.issue14534@psf.upfronthosting.co.za> ?ric Araujo added the comment: FWIW I use the mixin approach too and find it simple and clean. I don?t have a problem with a method in the mixin class calling methods from TestCase. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:54:25 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 13 Apr 2012 17:54:25 +0000 Subject: [issue14530] distutils's build_wininst command fails to correctly interpret the data_files argument In-Reply-To: <1333907900.33.0.191070589139.issue14530@psf.upfronthosting.co.za> Message-ID: <1334339665.57.0.655545776575.issue14530@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 19:54:35 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 13 Apr 2012 17:54:35 +0000 Subject: [issue14529] distutils's build_msi command ignores the data_files argument In-Reply-To: <1333907359.21.0.0116056941941.issue14529@psf.upfronthosting.co.za> Message-ID: <1334339675.19.0.102313155225.issue14529@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 20:00:01 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 13 Apr 2012 18:00:01 +0000 Subject: [issue1222585] C++ compilation support for distutils Message-ID: <1334340001.48.0.30356127093.issue1222585@psf.upfronthosting.co.za> ?ric Araujo added the comment: I should be able to port the patch and add tests for detect_language, but I know very little about C++ and may not be able to write a full test that really compiles and checks a C++ program. We?re having a sprint on the 21, I?ll see if I can work with another participant to do this. A sample short C++ source file would help (just use some Python/C function and print something). ---------- keywords: +easy -patch stage: patch review -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 20:05:11 2012 From: report at bugs.python.org (anatoly techtonik) Date: Fri, 13 Apr 2012 18:05:11 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1334340311.19.0.0317226258874.issue13405@psf.upfronthosting.co.za> Changes by anatoly techtonik : ---------- nosy: -techtonik _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 20:23:07 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 13 Apr 2012 18:23:07 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1334274577.83.0.731550571507.issue14428@psf.upfronthosting.co.za> Message-ID: <4F886F02.9000607@egenix.com> Marc-Andre Lemburg added the comment: STINNER Victor wrote: > > STINNER Victor added the comment: > > perf_counter_process_time.patch: replace "time.clock if windows else time.time" with time.perf_counter, and getrusage/clock with time.process_time. > > pybench and timeit now use time.perf_counter() by default. profile uses time.proces_time() by default. > > pybench uses time.get_clock_info() to display the precision and the underlying C function (or the resolution if the precision is not available). > > Tools/pybench/systimes.py and Tools/pybench/clockres.py may be removed: these features are now available directly in the time module. No changes to the pybench defaults, please. It has to stay backwards compatible with older releases. Adding optional new timers is fine, though. Thanks, -- Marc-Andre Lemburg eGenix.com ________________________________________________________________________ 2012-04-28: PythonCamp 2012, Cologne, Germany 15 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 21:06:41 2012 From: report at bugs.python.org (Jim Jewett) Date: Fri, 13 Apr 2012 19:06:41 +0000 Subject: [issue14562] urllib2 maybe blocks too long In-Reply-To: <1334233390.52.0.591380103695.issue14562@psf.upfronthosting.co.za> Message-ID: <1334344001.35.0.672595889597.issue14562@psf.upfronthosting.co.za> Jim Jewett added the comment: It would be helpful to have a testcase, so that it will stay fixed. ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 21:07:36 2012 From: report at bugs.python.org (Jim Jewett) Date: Fri, 13 Apr 2012 19:07:36 +0000 Subject: [issue14562] urllib2 maybe blocks too long with small chunks In-Reply-To: <1334233390.52.0.591380103695.issue14562@psf.upfronthosting.co.za> Message-ID: <1334344056.76.0.000964722511044.issue14562@psf.upfronthosting.co.za> Changes by Jim Jewett : ---------- title: urllib2 maybe blocks too long -> urllib2 maybe blocks too long with small chunks _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 21:13:13 2012 From: report at bugs.python.org (Alex Leach) Date: Fri, 13 Apr 2012 19:13:13 +0000 Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za> Message-ID: <1334344393.74.0.351319744146.issue4130@psf.upfronthosting.co.za> Alex Leach added the comment: Patch included for Modules/_ctyles/libffi/src/x86/ffi64.c. I've added some include guards around anything necessary to compile with the Intel compiler. This patch is needed to compile the _ctypes module with icc on current Python releases (just successfully compiled 2.7.3, with patch).. ---------- keywords: +patch nosy: +Alex.Leach Added file: http://bugs.python.org/file25205/ffi64.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 21:15:49 2012 From: report at bugs.python.org (Jim Jewett) Date: Fri, 13 Apr 2012 19:15:49 +0000 Subject: [issue14555] clock_gettime/settime/getres: Add more clock identifiers In-Reply-To: <1334183358.11.0.0329195703165.issue14555@psf.upfronthosting.co.za> Message-ID: <1334344549.84.0.341675472934.issue14555@psf.upfronthosting.co.za> Jim Jewett added the comment: Any particular reason not to add those? ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 21:20:40 2012 From: report at bugs.python.org (Jim Jewett) Date: Fri, 13 Apr 2012 19:20:40 +0000 Subject: [issue9303] Migrate sqlite3 module to _v2 API to enhance performance In-Reply-To: <1279541286.68.0.824716490463.issue9303@psf.upfronthosting.co.za> Message-ID: <1334344840.2.0.398601662486.issue9303@psf.upfronthosting.co.za> Jim Jewett added the comment: I can't speak for GSoC or Gerhard, but it strikes me as a reasonable first step. An alternatives woube be writing it with fallbacks (so older sqlite can still be used, though less efficiently). It would also be nice to clean up at least one call with compatibility cruft. That said, don't hesitate to submit a patch that does *something*, and then replace it with more comprehensive patches later. ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 21:49:08 2012 From: report at bugs.python.org (Jonathan Finlay) Date: Fri, 13 Apr 2012 19:49:08 +0000 Subject: [issue14571] float argument required, not NoneType Message-ID: <1334346548.9.0.537593280574.issue14571@psf.upfronthosting.co.za> New submission from Jonathan Finlay : File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/main.py", line 1194, in _sig_remove_book res = page.sig_close() File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/form.py", line 492, in sig_close dialog.destroy() File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/win_form.py", line 396, in destroy self.screen.switch_view(view_type=self.prev_view.view_type) File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/screen/screen.py", line 320, in switch_view self.display() File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/screen/screen.py", line 657, in display view.display() File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/view/form.py", line 126, in display record[field].get(record, check_load=False) File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/model/record.py", line 124, in __getitem__ self.set(value, signal=False) File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/model/record.py", line 421, in set self.group.fields[fieldname].set(self, value, modified=False) File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/model/field.py", line 757, in set group.destroy() File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/model/group.py", line 390, in destroy self.clear() File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/model/group.py", line 107, in clear self.signal('group-list-changed', ('record-removed', record)) File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/signal_event.py", line 14, in signal fnct(self, signal_data, *data) File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/screen/screen.py", line 219, in _group_list_changed view.group_list_changed(group, signal) File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/view/list.py", line 627, in group_list_changed self.display() File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/view/list.py", line 747, in display self.update_children() File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/view/list.py", line 783, in update_children True) File "/usr/lib/python2.6/locale.py", line 182, in format formatted = percent % value ---------- components: Library (Lib) files: locale.patch keywords: patch messages: 158229 nosy: jonathanf priority: normal severity: normal status: open title: float argument required, not NoneType type: compile error versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file25206/locale.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 21:49:54 2012 From: report at bugs.python.org (Jonathan Finlay) Date: Fri, 13 Apr 2012 19:49:54 +0000 Subject: [issue14571] float argument required, not NoneType In-Reply-To: <1334346548.9.0.537593280574.issue14571@psf.upfronthosting.co.za> Message-ID: <1334346594.54.0.116955193806.issue14571@psf.upfronthosting.co.za> Jonathan Finlay added the comment: This is the patch for the issue ---------- resolution: -> fixed Added file: http://bugs.python.org/file25207/locale.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 22:24:52 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 13 Apr 2012 20:24:52 +0000 Subject: [issue14571] float argument required, not NoneType In-Reply-To: <1334346548.9.0.537593280574.issue14571@psf.upfronthosting.co.za> Message-ID: <1334348692.63.0.881088193824.issue14571@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: It's a problem in tryton, which incorrectly passes a None value instead of a float. The issue was actually fixed 10 hours ago (!) in tryton: http://hg.tryton.org/tryton/rev/58a615b60cbd Please update to the last version! ---------- nosy: +amaury.forgeotdarc resolution: fixed -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 22:56:28 2012 From: report at bugs.python.org (Martin von Gagern) Date: Fri, 13 Apr 2012 20:56:28 +0000 Subject: [issue11218] pattern=None when following documentation for load_tests and unittest.main() In-Reply-To: <1297758807.39.0.713611114484.issue11218@psf.upfronthosting.co.za> Message-ID: <1334350588.48.0.989532401478.issue11218@psf.upfronthosting.co.za> Martin von Gagern added the comment: I'm attaching a patch to better explain what I'm suggesting. As you can see, this patch doesn't change the signature of discover, nor does it change the semantics for any code that doesn't pass pattern, or that passes some pattern other than None. The only change is that now, passing pattern=None is the same as not passing pattern at all. As a result, load_tests might now pass pattern=pattern as the documentation suggests, and still be called with pattern=None without raising an exception. ---------- keywords: +patch Added file: http://bugs.python.org/file25208/issue11218_patternNone.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 23:01:12 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Apr 2012 21:01:12 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334350872.97.0.770555525596.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: Patch version 8: time.process_time() uses times() if available. Rename also "function" key of time.get_clock_info() with "implementation". ---------- Added file: http://bugs.python.org/file25209/pep418-8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 23:05:14 2012 From: report at bugs.python.org (Michael Foord) Date: Fri, 13 Apr 2012 21:05:14 +0000 Subject: [issue11218] pattern=None when following documentation for load_tests and unittest.main() In-Reply-To: <1297758807.39.0.713611114484.issue11218@psf.upfronthosting.co.za> Message-ID: <1334351114.23.0.832976993048.issue11218@psf.upfronthosting.co.za> Michael Foord added the comment: So the logic of the "pattern" argument to "load_tests" is that it should not be None when test discovery is loading the __init__.py module of a test package. However, because most patterns will actually *prevent* __init__.py from being loaded by test discovery - this turns out to not be very useful and in all practical cases this argument will be None. I don't think there are any backward compatibility issues with the real pattern being passed in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 23:06:13 2012 From: report at bugs.python.org (Michael Foord) Date: Fri, 13 Apr 2012 21:06:13 +0000 Subject: [issue11218] pattern=None when following documentation for load_tests and unittest.main() In-Reply-To: <1297758807.39.0.713611114484.issue11218@psf.upfronthosting.co.za> Message-ID: <1334351173.27.0.888852168199.issue11218@psf.upfronthosting.co.za> Michael Foord added the comment: Also the patch to allow the pattern to be None (and revert to the default pattern in this case) looks good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 23:23:39 2012 From: report at bugs.python.org (Martin von Gagern) Date: Fri, 13 Apr 2012 21:23:39 +0000 Subject: [issue11218] pattern=None when following documentation for load_tests and unittest.main() In-Reply-To: <1297758807.39.0.713611114484.issue11218@psf.upfronthosting.co.za> Message-ID: <1334352219.6.0.147174308092.issue11218@psf.upfronthosting.co.za> Martin von Gagern added the comment: Michael wrote: "[?] the real pattern being passed in". I wonder, what would be "the real pattern"? In the code I originally pasted, the load_tests function would be invoked by loadTestsFromModule (for module __main__). There is nothing file-based about this, so although you could pass a default pattern, it wouldn't be any more or less "real" than passing None. It might be more useful, though. "most patterns will actually *prevent* __init__.py from being loaded by test discovery - this turns out to not be very useful and in all practical cases this argument will be None." Not sure I follow there. For the root of the test suite, yes, it will always be None. But for child packages it will be the pattern that led to the discovery of the __init__.py of that package. In all practical cases this will be a string different from both None and the default of 'test*.py', as it has to match the directory name. Most likely it will be what the load_tests function of the parent package passed to its invocation of discover. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 23:41:11 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 13 Apr 2012 21:41:11 +0000 Subject: [issue1762561] unable to serialize Infinity or NaN on ARM using marshal Message-ID: <1334353271.57.0.458113455788.issue1762561@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 13 23:41:58 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Apr 2012 21:41:58 +0000 Subject: [issue14555] clock_gettime/settime/getres: Add more clock identifiers In-Reply-To: <1334183358.11.0.0329195703165.issue14555@psf.upfronthosting.co.za> Message-ID: <1334353318.74.0.859089914693.issue14555@psf.upfronthosting.co.za> STINNER Victor added the comment: > Any particular reason not to add those? I didn't find yet documentation of: CLOCK_BOOTTIME_ALARM, CLOCK_REALTIME_ALARM For CLOCK_UPTIME_PRECISE, CLOCK_MONOTONIC_PRECISE, CLOCK_REALTIME_PRECISE: I don't know if there are useful. Are they different than the clocks without _PRECISE suffix? For CLOCK_UPTIME_FAST, it's just that I forgot to add it :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 00:09:12 2012 From: report at bugs.python.org (Joakim Sernbrant) Date: Fri, 13 Apr 2012 22:09:12 +0000 Subject: [issue14572] 2.7.3: sqlite module does not build on centos 5 Message-ID: <1334354952.88.0.487562486207.issue14572@psf.upfronthosting.co.za> New submission from Joakim Sernbrant : Python-2.7.3/Modules/_sqlite/connection.c: In function ?_pysqlite_set_result?: Python-2.7.3/Modules/_sqlite/connection.c:552: error: ?sqlite3_int64? undeclared (first use in this function) The centos 5 version of sqlite3 (sqlite-devel-3.3.6-5) does not export the type sqlite3_int64. 2.7.0 did build without problems. Newer versions declare both sqlite3_int64 and sqlite_int64: http://www.sqlite.org/c3ref/int64.html Patch: diff --git a/Modules/_sqlite/connection.c b/Modules/_sqlite/connection.c index 26678c7..a646513 100644 --- a/Modules/_sqlite/connection.c +++ b/Modules/_sqlite/connection.c @@ -549,7 +549,7 @@ void _pysqlite_set_result(sqlite3_context* context, PyObject* py_val) } else if (py_val == Py_None) { sqlite3_result_null(context); } else if (PyInt_Check(py_val)) { - sqlite3_result_int64(context, (sqlite3_int64)PyInt_AsLong(py_val)); + sqlite3_result_int64(context, (sqlite_int64)PyInt_AsLong(py_val)); } else if (PyLong_Check(py_val)) { sqlite3_result_int64(context, PyLong_AsLongLong(py_val)); } else if (PyFloat_Check(py_val)) { @@ -580,7 +580,7 @@ PyObject* _pysqlite_build_py_params(sqlite3_context *context, int argc, sqlite3_ sqlite3_value* cur_value; PyObject* cur_py_value; const char* val_str; - sqlite3_int64 val_int; + sqlite_int64 val_int; Py_ssize_t buflen; void* raw_buffer; ---------- components: Build messages: 158238 nosy: Joakim.Sernbrant priority: normal severity: normal status: open title: 2.7.3: sqlite module does not build on centos 5 type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 00:10:33 2012 From: report at bugs.python.org (Aaron Staley) Date: Fri, 13 Apr 2012 22:10:33 +0000 Subject: [issue14573] json iterencode can not handle general iterators Message-ID: <1334355033.57.0.314676653112.issue14573@psf.upfronthosting.co.za> New submission from Aaron Staley : The json library's encoder includes a function called 'iterencode'. iterencode allows for encoding to be streamed; as tokens are produced they are yielded. This allows for the encoded object to be streamed to a file, over a socket, etc. without being placed all into memory. Unfortunately, iterencode cannot encode general iterators. This significantly limits the usefulness of the function. For my use case I wish to convert a large stream (iterator) of objects into json. Unfortunately, I currently have to: A. Bring all the objects into memory by encasing the iterator in a list() B. Make a hack where I subclass list and making that object's __iter__ function return my desired iterator. The problem is that the json library explicitly checks for something being a list: if isinstance(value, (list, tuple)): chunks = _iterencode_list(value, _current_indent_level) It would work just as well (and be more pythonic) to see if the value supports the iterator protocol: if isinstance(value, collections.Iterable): chunks = _iterencode_list(value, _current_indent_level) Erroring example: >>> import json >>> e = json.JSONEncoder() >>> r = xrange(20) >>> gen = e.iterencode(r) >>> next(gen) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.2/json/encoder.py", line 419, in _iterencode o = _default(o) File "/usr/lib/python3.2/json/encoder.py", line 170, in default raise TypeError(repr(o) + " is not JSON serializable") TypeError: xrange(0, 20) is not JSON serializable ---------- components: Library (Lib) messages: 158239 nosy: Aaron.Staley priority: normal severity: normal status: open title: json iterencode can not handle general iterators versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 01:07:42 2012 From: report at bugs.python.org (Vlad) Date: Fri, 13 Apr 2012 23:07:42 +0000 Subject: [issue14574] SocketServer doesn't handle client disconnects properly Message-ID: <1334358462.67.0.980544384901.issue14574@psf.upfronthosting.co.za> New submission from Vlad : When dealing with a new connection, SocketServer.BaseRequestHandler.__init__ first calls the request handler (self.handle below) and then calls cleanup code which closes the connection (self.finish below). class BaseRequestHandler: def __init__(self, request, client_address, server): < ... snip ... > try: self.handle() finally: self.finish() The issue arises when a client disconnects suddenly during the self.handle() call. The handler may attempt to write data to the disconnected socket. This will cause an exception (which is correct), but somehow data will still be added to the connection's buffer and self.wfile.closed will be False! As a result, BaseRequestHandler.finish() will attempt to flush the connection's buffer and this will raise another exception which can't be handled without modifying the library code. ---------------------------------------- Exception happened during processing of request from ('127.0.0.1', 62718) Traceback (most recent call last): File "C:\Python27\lib\SocketServer.py", line 284, in _handle_request_noblock self.process_request(request, client_address) File "C:\Python27\lib\SocketServer.py", line 310, in process_request self.finish_request(request, client_address) File "C:\Python27\lib\SocketServer.py", line 323, in finish_request self.RequestHandlerClass(request, client_address, self) File "C:\Python27\lib\SocketServer.py", line 641, in __init__ self.finish() File "C:\Python27\lib\SocketServer.py", line 694, in finish self.wfile.flush() File "C:\Python27\lib\socket.py", line 303, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) error: [Errno 10053] An established connection was aborted by the software in your host machine ---------------------------------------- I've provided a toy server below, you can reproduce the issue by submitting a request to it with curl and then immediately killing curl: curl -d "test" http://127.0.0.1:8000/ Toy server code: =========================== import BaseHTTPServer import SocketServer import time class ThreadedHTTPServer(BaseHTTPServer.HTTPServer): pass class RequestHandler(BaseHTTPServer.BaseHTTPRequestHandler): def do_POST(self): try: length = int(self.headers["Content-Length"]) request = self.rfile.read(length) print "Sleeping. Kill the 'curl' command now." time.sleep(10) print "Woke up. You should see a stack trace from the problematic exception below." print "Received POST: " + request self.send_response(200) # <------- This somehow adds to the connection's buffer! self.end_headers() except Exception as e: print "Exception: " + str(e) # <----- This exception is expected httpd = ThreadedHTTPServer(("127.0.0.1", 8000), RequestHandler) httpd.serve_forever() httpd.server_close() ---------- components: Library (Lib) messages: 158240 nosy: vdjeric priority: normal severity: normal status: open title: SocketServer doesn't handle client disconnects properly versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 01:16:23 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Apr 2012 23:16:23 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334358983.72.0.519770223968.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: Patch version 9: fixes for Windows (fix compilation and fix to code checking if GetTickCount64 is present). ---------- Added file: http://bugs.python.org/file25210/pep418-9.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 01:16:47 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Apr 2012 23:16:47 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334359007.81.0.0757273676031.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25126/pep418-6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 01:16:48 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Apr 2012 23:16:48 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334359008.93.0.0552678012676.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25201/pep418-7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 01:16:50 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Apr 2012 23:16:50 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334359010.24.0.905789846227.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25209/pep418-8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 01:26:41 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 13 Apr 2012 23:26:41 +0000 Subject: [issue14573] json iterencode can not handle general iterators In-Reply-To: <1334355033.57.0.314676653112.issue14573@psf.upfronthosting.co.za> Message-ID: <1334359601.44.0.679769227885.issue14573@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, rhettinger stage: -> test needed type: -> behavior versions: +Python 3.3 -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 02:54:03 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 14 Apr 2012 00:54:03 +0000 Subject: [issue6380] Deadlock during the "import" in the fork()'ed child process if fork() happened while import_lock was held In-Reply-To: <1246315934.51.0.706424064381.issue6380@psf.upfronthosting.co.za> Message-ID: <1334364843.1.0.208939687504.issue6380@psf.upfronthosting.co.za> Gregory P. Smith added the comment: What is the status of this in 2.7? Brett - what about in 3.3 after you get importlib in? ---------- versions: +Python 3.3 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 02:57:25 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 14 Apr 2012 00:57:25 +0000 Subject: [issue6380] Deadlock during the "import" in the fork()'ed child process if fork() happened while import_lock was held In-Reply-To: <1246315934.51.0.706424064381.issue6380@psf.upfronthosting.co.za> Message-ID: <1334365045.95.0.482655155628.issue6380@psf.upfronthosting.co.za> Gregory P. Smith added the comment: btw, a potentially related (or duplicate?) issue was already fixed - http://bugs.python.org/issue1590864 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 03:27:46 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Apr 2012 01:27:46 +0000 Subject: [issue14399] zipfile and creat/update comment In-Reply-To: <1332606431.21.0.286905846716.issue14399@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b3b7f9dd7ce4 by R David Murray in branch '3.2': #14399: corrected news item http://hg.python.org/cpython/rev/b3b7f9dd7ce4 New changeset 225126c9d4b5 by R David Murray in branch '2.7': #14399: corrected news item http://hg.python.org/cpython/rev/225126c9d4b5 New changeset 160245735299 by R David Murray in branch 'default': Merge #14399: corrected news item http://hg.python.org/cpython/rev/160245735299 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 03:28:42 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 14 Apr 2012 01:28:42 +0000 Subject: [issue14399] zipfile and creat/update comment In-Reply-To: <1332606431.21.0.286905846716.issue14399@psf.upfronthosting.co.za> Message-ID: <1334366922.98.0.61103759204.issue14399@psf.upfronthosting.co.za> R. David Murray added the comment: I must have been seeing what I expected to see. The test that failed was the non-empty test. News item fixed, thanks for the correction. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 03:38:15 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 14 Apr 2012 01:38:15 +0000 Subject: [issue14477] Rietveld test issue In-Reply-To: <1333382689.52.0.891466185612.issue14477@psf.upfronthosting.co.za> Message-ID: <1334367495.7.0.768785600709.issue14477@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 03:55:38 2012 From: report at bugs.python.org (Anrs Hu) Date: Sat, 14 Apr 2012 01:55:38 +0000 Subject: [issue14562] urllib2 maybe blocks too long with small chunks In-Reply-To: <1334233390.52.0.591380103695.issue14562@psf.upfronthosting.co.za> Message-ID: <1334368538.92.0.324306327958.issue14562@psf.upfronthosting.co.za> Anrs Hu added the comment: Okay, there's a test case of web.py: Server codes are following: import web class index(object): def GET(self): yield 'hello\n' yield 'world\n' time.sleep(60) client is Python interpreter >>> resp = urllib.urlopen(URL) >>> resp.readline() # will be 'hello' >>> resp.readline() # will be 'world' >>> resp.readline() # huh, it's blocked, and we to agree with it. >>> # but to use urllib2 will another behavor. >>> urllib2.urlopen(URL).readline() # huh, it's blocked even if 'hello' and 'world' returned yet. Because urllib2 uses a 8KiB buffer on socket._fileobjece within urllib2.py, it read 8K data to buffer first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 04:52:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Apr 2012 02:52:43 +0000 Subject: [issue14535] three code examples in docs are not syntax highlighted In-Reply-To: <1333981665.2.0.806826898617.issue14535@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 635966f6d3de by Ezio Melotti in branch '3.2': #14535: fix code highlight in multiprocessing examples. Patch by Tshepang Lekhonkhobe. http://hg.python.org/cpython/rev/635966f6d3de New changeset 957e2c71beef by Ezio Melotti in branch 'default': #14535: merge with 3.2. http://hg.python.org/cpython/rev/957e2c71beef ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 04:56:04 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 14 Apr 2012 02:56:04 +0000 Subject: [issue14535] three code examples in docs are not syntax highlighted In-Reply-To: <1333981665.2.0.806826898617.issue14535@psf.upfronthosting.co.za> Message-ID: <1334372164.17.0.668884056455.issue14535@psf.upfronthosting.co.za> Ezio Melotti added the comment: I tried the attached patch but it didn't work for me. Using "python3" instead of "python" seemed to fix the problem. I also updated another "python" to use "python3". Thanks for the report and the patch! ---------- assignee: docs at python -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 06:10:34 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 14 Apr 2012 04:10:34 +0000 Subject: [issue14554] test module: correction In-Reply-To: <1334181755.32.0.776262768406.issue14554@psf.upfronthosting.co.za> Message-ID: <1334376634.04.0.719908071173.issue14554@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> commit review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 06:15:16 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 14 Apr 2012 04:15:16 +0000 Subject: [issue12428] functools test coverage In-Reply-To: <1309255638.21.0.342456839611.issue12428@psf.upfronthosting.co.za> Message-ID: <1334376916.53.0.0387810264355.issue12428@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 06:18:20 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 14 Apr 2012 04:18:20 +0000 Subject: [issue14507] Segfault with starmap and izip combo In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1334377100.29.0.100958016951.issue14507@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 06:26:43 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 14 Apr 2012 04:26:43 +0000 Subject: [issue14408] Support ./python -m unittest in the stdlib tests In-Reply-To: <1332735237.61.0.855199980132.issue14408@psf.upfronthosting.co.za> Message-ID: <1334377603.68.0.553895905214.issue14408@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 06:28:50 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 14 Apr 2012 04:28:50 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1331932171.45.0.56771909125.issue14339@psf.upfronthosting.co.za> Message-ID: <1334377730.2.0.385007207205.issue14339@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 06:31:06 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 14 Apr 2012 04:31:06 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1334377866.27.0.0966066284824.issue14304@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 06:34:52 2012 From: report at bugs.python.org (Hugh Gibbons) Date: Sat, 14 Apr 2012 04:34:52 +0000 Subject: [issue14575] IDLE crashes after file open in OS X Message-ID: <1334378092.39.0.081519751274.issue14575@psf.upfronthosting.co.za> New submission from Hugh Gibbons : IDLE crashes shortly after I open a any file with IDLE, using the file browser. If I open a file from the File->Recent Files list, it does not crash. OS X version 10.6.8. ---------- components: IDLE messages: 158249 nosy: hgibbons priority: normal severity: normal status: open title: IDLE crashes after file open in OS X type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 06:34:59 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 14 Apr 2012 04:34:59 +0000 Subject: [issue14393] Incorporate Guide to Magic Methods? In-Reply-To: <1332493295.71.0.816804721304.issue14393@psf.upfronthosting.co.za> Message-ID: <1334378099.89.0.832652843227.issue14393@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 07:54:05 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 14 Apr 2012 05:54:05 +0000 Subject: [issue6380] Deadlock during the "import" in the fork()'ed child process if fork() happened while import_lock was held In-Reply-To: <1246315934.51.0.706424064381.issue6380@psf.upfronthosting.co.za> Message-ID: <1334382845.41.0.45810018376.issue6380@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 07:54:28 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 14 Apr 2012 05:54:28 +0000 Subject: [issue1590864] Function-level import in os triggering an threaded import deadlock Message-ID: <1334382868.97.0.97899122632.issue1590864@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 08:40:06 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 14 Apr 2012 06:40:06 +0000 Subject: [issue14535] three code examples in docs are not syntax highlighted In-Reply-To: <1333981665.2.0.806826898617.issue14535@psf.upfronthosting.co.za> Message-ID: <1334385606.68.0.622606588036.issue14535@psf.upfronthosting.co.za> Georg Brandl added the comment: Ezio: That's a "bug" in Sphinx; even when the language is selected explicitly as "python", it will try to parse the code. It is fixed in a later Sphinx version. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 11:16:13 2012 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 14 Apr 2012 09:16:13 +0000 Subject: [issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate In-Reply-To: <1327767887.13.0.0676848614688.issue13897@psf.upfronthosting.co.za> Message-ID: <1334394973.01.0.455594697105.issue13897@psf.upfronthosting.co.za> Stefan Behnel added the comment: >> As long as there is a way to access these fields directly from the >> struct (with the usual preprocessor conditional), I don't think Cython >> will actually start to use the PyErr_[GS]etExcInfo() functions in >> CPython - simply for performance reasons. > > Isn't this premature optimization? Do you have any workload where you > measured a performance degradation? To be honest - I don't know if it makes a measurable difference. However, the code is there, it's required for all currently released CPython versions (i.e. those still being supported for years to come), and it is used in seriously performance critical places, such as each generator/coroutine iteration - twice. Why should we add overhead to those without need? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 12:09:31 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 14 Apr 2012 10:09:31 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: <1334398171.53.0.867283975837.issue11750@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- nosy: +kristjan.jonsson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 12:10:50 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 14 Apr 2012 10:10:50 +0000 Subject: [issue14574] SocketServer doesn't handle client disconnects properly In-Reply-To: <1334358462.67.0.980544384901.issue14574@psf.upfronthosting.co.za> Message-ID: <1334398250.35.0.572530342811.issue14574@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- nosy: +kristjan.jonsson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 12:34:02 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 14 Apr 2012 10:34:02 +0000 Subject: [issue14534] Add method to mark unittest.TestCases as "do not run". In-Reply-To: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za> Message-ID: <1334399642.08.0.250171000325.issue14534@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: +1, we already have such decorators for individual test cases. Code should be obvious, particularly testing code and mixins often aren't. Magic such as identifying classes to run by their type should be over rideable. All magic should. ---------- nosy: +kristjan.jonsson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 12:41:06 2012 From: report at bugs.python.org (clikkeb) Date: Sat, 14 Apr 2012 10:41:06 +0000 Subject: [issue14576] IDLE cannot connect to subprocess - New solution Message-ID: <1334400065.92.0.605072928338.issue14576@psf.upfronthosting.co.za> New submission from clikkeb : It's a common issue that IDLE cannot start on Windows because "IDLE's subprocess didn't make connection.Either IDLE can't start a subprocess or personal firewall software is blocking the connection." Everyone claim that the user should set the firewal so that IDLE can connect to subprocess via loopback. I found, instead, that this issue is often caused by an incorrect or missing setting of one the following variables: HOME, USERPROFILE or the combination of HOMEPATH and HOMEDRIVE; if these variables don't represent an existent and writable directory, the error occurs. Try setting HOMEPATH to an unexistent or unwritable directory just before launching idle.bat script. Check IdleConf.GetUserCfgDir() in module configHandler.py, where the function os.path.expanduser is called to get the user home directory. You might also temporarly patch GetUserCfgDir, setting the userDir variable to an unexistent path just after it has been initialized via os.path.expanduser (line 202). Should be considered a check on expanduser behaviour? OS: Windows XP Python version: 3.2.2 clikkeb ---------- components: IDLE messages: 158253 nosy: clikkeb priority: normal severity: normal status: open title: IDLE cannot connect to subprocess - New solution versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 13:16:54 2012 From: report at bugs.python.org (Michael Foord) Date: Sat, 14 Apr 2012 11:16:54 +0000 Subject: [issue14577] pickling uses __class__ so you can't pickle proxy/mock objects that pretend to be other objects Message-ID: <1334402214.26.0.28776275463.issue14577@psf.upfronthosting.co.za> New submission from Michael Foord : Pickling uses __class__ instead of type(obj) to determine the type to pickle. This means that objects which pretend to be other objects (like proxy and mock objects) can't be pickled correctly: >>> class Foo(object): ... __class__ = property(lambda *a, **k: int) ... ... >>> from pickle import dumps >>> dumps(Foo()) b'\x80\x03cbuiltins\nint\nq\x00)\x81q\x01}q\x02b.' Here Foo() is pickled as an int. In Python 2 using type(obj) wouldn't work for old style classes, but I don't see a reason not to use type(obj) in Python 3. Note that also, the pickle protocol methods like __getstate__ etc are looked up on the object instance (using getattr) rather than on the object type. This means that __getattr__ is invoked to look them up - requiring special casing in objects that provide __getattr__ to avoid them (raise an AttributeError if they don't provide these methods). This affects three object types in the unittest.mock namespace (_Call, sentinel and the Mock variants). ---------- messages: 158254 nosy: michael.foord priority: normal severity: normal status: open title: pickling uses __class__ so you can't pickle proxy/mock objects that pretend to be other objects _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 13:20:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 14 Apr 2012 11:20:26 +0000 Subject: [issue14577] pickling uses __class__ so you can't pickle proxy/mock objects that pretend to be other objects In-Reply-To: <1334402214.26.0.28776275463.issue14577@psf.upfronthosting.co.za> Message-ID: <1334402426.05.0.00448463416105.issue14577@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Have you tried making a change and see if any tests fail? This is a behaviour change and I wonder if the original behaviour is by design or accident. ---------- components: +Library (Lib) nosy: +alexandre.vassalotti, pitrou type: -> enhancement versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 13:24:32 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 14 Apr 2012 11:24:32 +0000 Subject: [issue6380] Deadlock during the "import" in the fork()'ed child process if fork() happened while import_lock was held In-Reply-To: <1246315934.51.0.706424064381.issue6380@psf.upfronthosting.co.za> Message-ID: <1334402672.71.0.543274974686.issue6380@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This was fixed long ago in 724bbd489ad4. Dmitriy's example works fine with 2.7. ---------- nosy: +pitrou resolution: -> out of date stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 13:25:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 14 Apr 2012 11:25:20 +0000 Subject: [issue14574] SocketServer doesn't handle client disconnects properly In-Reply-To: <1334358462.67.0.980544384901.issue14574@psf.upfronthosting.co.za> Message-ID: <1334402720.34.0.185433204563.issue14574@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 13:28:27 2012 From: report at bugs.python.org (Michael Foord) Date: Sat, 14 Apr 2012 11:28:27 +0000 Subject: [issue14577] pickling uses __class__ so you can't pickle proxy/mock objects that pretend to be other objects In-Reply-To: <1334402214.26.0.28776275463.issue14577@psf.upfronthosting.co.za> Message-ID: <1334402907.76.0.119360990832.issue14577@psf.upfronthosting.co.za> Michael Foord added the comment: So, changing copyreg.py to use type(self) instead of self.__class__ isn't sufficient. _pickle accesses __class__ as well it seems. However I'm running all tests with this change in place to see if it breaks intended behaviour: Python 3.3.0a1+ (default:51016ff7f8c9, Mar 26 2012, 13:15:33) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import pickle as p [70240 refs] >>> class Foo(object): ... __class__ = property(lambda s: int) ... [70290 refs] >>> Foo().__class__ [70294 refs] >>> p.dumps(Foo()) Traceback (most recent call last): File "", line 1, in _pickle.PicklingError: args[0] from __newobj__ args has the wrong class ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 13:40:07 2012 From: report at bugs.python.org (Michael Foord) Date: Sat, 14 Apr 2012 11:40:07 +0000 Subject: [issue14577] pickling uses __class__ so you can't pickle proxy/mock objects that pretend to be other objects In-Reply-To: <1334402214.26.0.28776275463.issue14577@psf.upfronthosting.co.za> Message-ID: <1334403607.5.0.740076852524.issue14577@psf.upfronthosting.co.za> Michael Foord added the comment: test_pickle still passes with only copyreg.py modified. With one additional change in pickle.py (line 405 to use type(obj) instead of obj.__class__) the pickling works as I would hope (I would need assistance to fix _pickle): >>> import sys [65446 refs] >>> sys.modules['_pickle'] = None [65448 refs] >>> import pickle as p [70090 refs] >>> class Foo: ... __class__ = property(lambda s: int) ... [70140 refs] >>> p.dumps(Foo()) b'\x80\x03c__main__\nFoo\nq\x00)\x81q\x01.' [70156 refs] >>> d = p.dumps(Foo()) [70158 refs] >>> p.loads(d) <__main__.Foo object at 0x101410a00> [70216 refs] >>> f = p.loads(d) [70219 refs] >>> f.__class__ However, as you suspect Antoine, it is apparently deliberate that proxies should be pickled as the original: ====================================================================== ERROR: test_newobj_proxies (test.test_pickle.DumpPickle_CLoadPickle) ---------------------------------------------------------------------- Traceback (most recent call last): File "/compile/py3k-cpython/Lib/test/pickletester.py", line 903, in test_newobj_proxies s = self.dumps(p, proto) File "/compile/py3k-cpython/Lib/test/test_pickle.py", line 33, in dumps p.dump(arg) File "/compile/py3k-cpython/Lib/pickle.py", line 235, in dump self.save(obj) File "/compile/py3k-cpython/Lib/pickle.py", line 342, in save self.save_reduce(obj=obj, *rv) File "/compile/py3k-cpython/Lib/pickle.py", line 405, in save_reduce "args[0] from __newobj__ args has the wrong class") _pickle.PicklingError: args[0] from __newobj__ args has the wrong class ---------------------------------------------------------------------- Line 891 from pickletester.py: def test_newobj_proxies(self): # NEWOBJ should use the __class__ rather than the raw type I wonder what the use case for that is? If you serialize a proxy object, why would the deserialization code not want a proxy back too? I guess I can look at implementing copyreg functions for my objects instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 13:42:57 2012 From: report at bugs.python.org (Michael Foord) Date: Sat, 14 Apr 2012 11:42:57 +0000 Subject: [issue14577] pickling uses __class__ so you can't pickle proxy/mock objects that pretend to be other objects In-Reply-To: <1334402214.26.0.28776275463.issue14577@psf.upfronthosting.co.za> Message-ID: <1334403777.8.0.329686508906.issue14577@psf.upfronthosting.co.za> Changes by Michael Foord : ---------- resolution: -> wont fix stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 13:48:59 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 14 Apr 2012 11:48:59 +0000 Subject: [issue14577] pickling uses __class__ so you can't pickle proxy/mock objects that pretend to be other objects In-Reply-To: <1334402214.26.0.28776275463.issue14577@psf.upfronthosting.co.za> Message-ID: <1334404139.5.0.0525689308052.issue14577@psf.upfronthosting.co.za> Nick Coghlan added the comment: Some additional thoughts for anyone else that comes across this issue. Consider the case of a weakref proxy (the only proxy type in the stdlib): for that, you never want to serialise the proxy, you want to serialise the original object. To correctly serialise a proxy object, you have to somehow ensure: - the proxy gets serialised - the target gets serialised - the two get hooked up again at the far end Now consider what happens if you have *two* proxies both pointing at the same target: how do you ensure that, when deserialised, both proxies still share a target? In the general case, you can't - so pickle doesn't even try. Instead, serialising a proxy serialises the original object - if you want to do something else, you need to decide for yourself how to recreate the cross-references correctly on deserialisation. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 13:52:58 2012 From: report at bugs.python.org (Michael Foord) Date: Sat, 14 Apr 2012 11:52:58 +0000 Subject: [issue14577] pickling uses __class__ so you can't pickle proxy/mock objects that pretend to be other objects In-Reply-To: <1334402214.26.0.28776275463.issue14577@psf.upfronthosting.co.za> Message-ID: <1334404378.98.0.831734072894.issue14577@psf.upfronthosting.co.za> Michael Foord added the comment: Nick - in general proxy objects have a *reference* to their target (weakref being somewhat of a special case), and pickle can already handle multiple references to the same target when deserializing an object graph. So I don't see that argument holding water for the general case. I also challenge the assertion that for a weakref proxy "you never want to serialise the proxy, you want to serialise the original object". Why? If the weakref proxy could be serialized and deserialized including the target, why would you *not* want a weakref proxy back (on its own there isn't much use for that but as part of an object graph having serialization turn a weakref into a strong reference sounds like an anti-feature). However, it looks like implementing __reduce__ is sufficient for my use case. Although the special-method-lookup-on-instance is still a nuisance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 14:14:38 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sat, 14 Apr 2012 12:14:38 +0000 Subject: [issue9303] Migrate sqlite3 module to _v2 API to enhance performance In-Reply-To: <1279541286.68.0.824716490463.issue9303@psf.upfronthosting.co.za> Message-ID: <1334405678.28.0.836548663496.issue9303@psf.upfronthosting.co.za> Robin Schreiber added the comment: I have now submitted a patch, which swapped out all the necessary calls. Tests are all running as expected. I will now try to remove some backwards compatibility code. ---------- keywords: +patch Added file: http://bugs.python.org/file25211/sqlite.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 14:16:32 2012 From: report at bugs.python.org (Simonas Kazlauskas) Date: Sat, 14 Apr 2012 12:16:32 +0000 Subject: [issue13700] imaplib.IMAP4.authenticate authobject fails with PLAIN mechanism In-Reply-To: <1325553089.14.0.504978991098.issue13700@psf.upfronthosting.co.za> Message-ID: <1334405792.01.0.244541715942.issue13700@psf.upfronthosting.co.za> Simonas Kazlauskas added the comment: Exactly same thing happens with `XOAUTH` mechanism too, so this bug report should be made more general. (Py3.2.2) ---------- nosy: +nagisa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 14:24:30 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 14 Apr 2012 12:24:30 +0000 Subject: [issue13700] imaplib.IMAP4.authenticate authobject does not work correctly in python3 In-Reply-To: <1325553089.14.0.504978991098.issue13700@psf.upfronthosting.co.za> Message-ID: <1334406270.82.0.0982219795561.issue13700@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: imaplib.IMAP4.authenticate authobject fails with PLAIN mechanism -> imaplib.IMAP4.authenticate authobject does not work correctly in python3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 15:39:42 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 14 Apr 2012 13:39:42 +0000 Subject: [issue14574] SocketServer doesn't handle client disconnects properly In-Reply-To: <1334358462.67.0.980544384901.issue14574@psf.upfronthosting.co.za> Message-ID: <1334410782.71.0.832978914667.issue14574@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Thanks for the report. Several things are going on here: 1. Even though socketserver's StreamRequestHandler uses unbuffered wfile for the socket """ class StreamRequestHandler(BaseRequestHandler): [...] rbufsize = -1 wbufsize = 0 # A timeout to apply to the request socket, if not None. timeout = None # Disable nagle algorithm for this socket, if True. # Use only when wbufsize != 0, to avoid small packets. disable_nagle_algorithm = False def setup(self): self.connection = self.request if self.timeout is not None: self.connection.settimeout(self.timeout) if self.disable_nagle_algorithm: self.connection.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, True) self.rfile = self.connection.makefile('rb', self.rbufsize) self.wfile = self.connection.makefile('wb', self.wbufsize) """ data is internally buffered by socket._fileobject: """ def write(self, data): data = str(data) # XXX Should really reject non-string non-buffers if not data: return self._wbuf.append(data) self._wbuf_len += len(data) if (self._wbufsize == 0 or self._wbufsize == 1 and '\n' in data or self._wbuf_len >= self._wbufsize): self.flush() """ Usually it doesn't turn out to be a problem because if the object is unbuffered the buffer is flushed right away, but in this specific case, it's a problem because a subsequent call to flush() will try to drain the data buffered temporarily, which triggers the second EPIPE from the StreamRequestHandler.finish() Note that Python 3.3 doesn't have this problem. While this is arguably a bad behavior, I don't feel comfortable changing this in 2.7 (either by changing the write() and flush() method or by just checking that the _fileobject is indeed buffered before flushing it). Moreover, this wouldn't solve the problem at hand in case the user chose to use a buffered connection (StreamRequestHandler.wbufsize > 0). 2. I think the root cause of the problem is that the handler's finish() method is called even when an exception occured during the handler, in which case nothing can be assumed about the state of the connection: """ class BaseRequestHandler: [...] self.setup() try: self.handle() finally: self.finish() """ Which is funny, because it doesn't match the documentation: """ .. method:: RequestHandler.finish() Called after the :meth:`handle` method to perform any clean-up actions required. The default implementation does nothing. If :meth:`setup` or :meth:`handle` raise an exception, this function will not be called. """ So the obvious solution would be to change the code to match the documentation, and not call finish when an exception was raised. But that would be a behavior change, and could introduce resource leaks. For example, here's StreamRequestHandler finish() method: """ def finish(self): if not self.wfile.closed: self.wfile.flush() self.wfile.close() self.rfile.close() """ While in this specific case if wouldn't lead to a FD leak (because the underlying socket is closed by the server code), one could imagine a case where it could have a negative impact, so I'm not sure about changing this. Finally, you could get rid of this error by overriding StreamRequestHandler.finish() method or catching the first exception in the handle() method and close the connection explicitely. So I'd like to know what others think about this :-) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 17:39:38 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sat, 14 Apr 2012 15:39:38 +0000 Subject: [issue9303] Migrate sqlite3 module to _v2 API to enhance performance In-Reply-To: <1279541286.68.0.824716490463.issue9303@psf.upfronthosting.co.za> Message-ID: <1334417978.21.0.242567530401.issue9303@psf.upfronthosting.co.za> Changes by Robin Schreiber : Removed file: http://bugs.python.org/file25211/sqlite.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 17:40:02 2012 From: report at bugs.python.org (Robin Schreiber) Date: Sat, 14 Apr 2012 15:40:02 +0000 Subject: [issue9303] Migrate sqlite3 module to _v2 API to enhance performance In-Reply-To: <1279541286.68.0.824716490463.issue9303@psf.upfronthosting.co.za> Message-ID: <1334418002.71.0.25596608655.issue9303@psf.upfronthosting.co.za> Changes by Robin Schreiber : Added file: http://bugs.python.org/file25212/sqlite.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 18:39:42 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 14 Apr 2012 16:39:42 +0000 Subject: [issue6380] Deadlock during the "import" in the fork()'ed child process if fork() happened while import_lock was held In-Reply-To: <1246315934.51.0.706424064381.issue6380@psf.upfronthosting.co.za> Message-ID: <1334421582.83.0.143870732904.issue6380@psf.upfronthosting.co.za> Brett Cannon added the comment: Just to answer Greg's question, importlib uses a context manager to manage the import lock so as long as that surfaces the right thing in a fork then things will be fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 19:07:07 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 14 Apr 2012 17:07:07 +0000 Subject: [issue14578] importlib doesn't check Windows registry for paths Message-ID: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za> New submission from Brett Cannon : Because I don't have access to Windows, importlib doesn't check the Windows registry for paths to search (see the use of _PyWin_FindRegisteredModule() in Python/import.c and its definition in PC/import_nt.c). I am considering this a release blocker as once importlib is bootstrapped in this will be a regression that Windows users may not be happy with. ---------- components: Windows messages: 158265 nosy: brett.cannon priority: release blocker severity: normal stage: test needed status: open title: importlib doesn't check Windows registry for paths type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 19:18:05 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 14 Apr 2012 17:18:05 +0000 Subject: [issue14578] importlib doesn't check Windows registry for paths In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za> Message-ID: <1334423885.79.0.0299714316512.issue14578@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 19:32:54 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 14 Apr 2012 17:32:54 +0000 Subject: [issue14578] importlib doesn't check Windows registry for paths In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za> Message-ID: <1334424774.22.0.402915818035.issue14578@psf.upfronthosting.co.za> Eric Snow added the comment: Yeah, that's one part of imp.find_module that I kind of set aside too (the #ifdef MS_COREDLL sections in Python/import.c). For now would it be sufficient to expose _PyWin_FindRegisteredModule() privately with a wrapper in the imp module? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 20:11:11 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 14 Apr 2012 18:11:11 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2dd046be2c88 by Brett Cannon in branch 'default': Issue #2377: Make importlib the implementation of __import__(). http://hg.python.org/cpython/rev/2dd046be2c88 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 20:26:51 2012 From: report at bugs.python.org (Brian Curtin) Date: Sat, 14 Apr 2012 18:26:51 +0000 Subject: [issue14578] importlib doesn't check Windows registry for paths In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za> Message-ID: <1334428011.97.0.77020465795.issue14578@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 20:27:52 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 14 Apr 2012 18:27:52 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1334428072.35.0.26157466798.issue2377@psf.upfronthosting.co.za> Brett Cannon added the comment: While the code has been committed, I'm leaving the issue open until I have checked that the language spec is up-to-date and I have written the "What's New" entry. I am holding off on both, though, unti any tweaks I make to the import process is in for Python 3.3. ---------- resolution: -> fixed stage: needs patch -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 20:28:00 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 14 Apr 2012 18:28:00 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1334428080.96.0.638445644372.issue2377@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 20:29:43 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 14 Apr 2012 18:29:43 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1334428183.92.0.0592615688512.issue13959@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think this should be a blocker for 3.3. ---------- nosy: +pitrou priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 20:40:12 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 14 Apr 2012 18:40:12 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1334428812.22.0.139586956554.issue2377@psf.upfronthosting.co.za> Brett Cannon added the comment: Notes on what to mention: importlib.invalidate_caches() doctests and ImportError now spitting out the full module name ImportError's new attributes ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 20:41:35 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 14 Apr 2012 18:41:35 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1334428895.64.0.97224877093.issue2377@psf.upfronthosting.co.za> Brett Cannon added the comment: More notes: 5% startup loss according to normal_startup; within realm of compiler optimizations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 20:46:03 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Apr 2012 18:46:03 +0000 Subject: [issue14579] Possible vulnerability in the utf-16 decoder after error handling Message-ID: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : In the utf-16 decoder after calling unicode_decode_call_errorhandler aligned_end is not updated. This may potentially cause data leaks, memory damage, and crash. The bug introduced by implementation of the issue #4868. In a similar situation in the utf-8 decoder aligned_end is updated. ---------- files: utf16_update_after_error.patch keywords: patch messages: 158272 nosy: storchaka priority: normal severity: normal status: open title: Possible vulnerability in the utf-16 decoder after error handling type: security versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25213/utf16_update_after_error.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 20:47:26 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 14 Apr 2012 18:47:26 +0000 Subject: [issue14579] Possible vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1334429246.68.0.903617654436.issue14579@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, pitrou stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 20:54:16 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 14 Apr 2012 18:54:16 +0000 Subject: [issue14579] Possible vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1334429656.24.0.968963276679.issue14579@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file25214/utf16_update_after_error-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 20:55:43 2012 From: report at bugs.python.org (Paul Ollis) Date: Sat, 14 Apr 2012 18:55:43 +0000 Subject: [issue14580] imp.reload can fail for sub-modules Message-ID: <1334429743.69.0.840922249937.issue14580@psf.upfronthosting.co.za> New submission from Paul Ollis : Code like this:: import collections.abc imp.reload(collections.abc) Raises the following exception: SystemError: Negative size passed to PyUnicode_New This occurs on the latest mercurial checkout (76302). ---------- components: Interpreter Core messages: 158273 nosy: paul_ollis priority: normal severity: normal status: open title: imp.reload can fail for sub-modules type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 20:57:55 2012 From: report at bugs.python.org (Paul Ollis) Date: Sat, 14 Apr 2012 18:57:55 +0000 Subject: [issue14580] imp.reload can fail for sub-modules In-Reply-To: <1334429743.69.0.840922249937.issue14580@psf.upfronthosting.co.za> Message-ID: <1334429875.73.0.588921323627.issue14580@psf.upfronthosting.co.za> Paul Ollis added the comment: Patch adding a test to reproduce the issue. ---------- keywords: +patch Added file: http://bugs.python.org/file25215/patch01-tests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 21:04:18 2012 From: report at bugs.python.org (Paul Ollis) Date: Sat, 14 Apr 2012 19:04:18 +0000 Subject: [issue14580] imp.reload can fail for sub-modules In-Reply-To: <1334429743.69.0.840922249937.issue14580@psf.upfronthosting.co.za> Message-ID: <1334430258.38.0.28417738696.issue14580@psf.upfronthosting.co.za> Paul Ollis added the comment: Patch that fixes the issue. ---------- Added file: http://bugs.python.org/file25216/patch01-code.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 21:20:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 14 Apr 2012 19:20:06 +0000 Subject: [issue14580] imp.reload can fail for sub-modules In-Reply-To: <1334429743.69.0.840922249937.issue14580@psf.upfronthosting.co.za> Message-ID: <1334431206.98.0.357223264193.issue14580@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brett.cannon priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 21:30:07 2012 From: report at bugs.python.org (sbt) Date: Sat, 14 Apr 2012 19:30:07 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: <1334431807.71.0.900071381726.issue11750@psf.upfronthosting.co.za> sbt added the comment: Attached is an up to date patch. * code has been moved to Modules/_windows.c * DWORD is uniformly treated as unsigned * _subprocess's handle wrapper type has been removed (although subprocess.py still uses a Python implemented handle wrapper type) I'm not familiar with Visual Studio. I ended up copying _socket.vcproj to _windows.vcproj and editing it by hand. I also edited _multiprocessing.vcproj and pythoncore.vcproj by hand. ---------- Added file: http://bugs.python.org/file25217/windows_module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 21:37:45 2012 From: report at bugs.python.org (Brian Curtin) Date: Sat, 14 Apr 2012 19:37:45 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: <1334432265.77.0.596504482237.issue11750@psf.upfronthosting.co.za> Brian Curtin added the comment: I don't think we need the vcproj file, unless I missed something. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 21:57:13 2012 From: report at bugs.python.org (sbt) Date: Sat, 14 Apr 2012 19:57:13 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: <1334433433.5.0.41864471117.issue11750@psf.upfronthosting.co.za> sbt added the comment: > I don't think we need the vcproj file, unless I missed something. _multiprocessing.win32 currently wraps closesocket(), send() and recv() so it needs to link against ws2_32.lib. I don't know how to make _windows link against ws2_32.lib without adding a vcproj file for _windows unless we make pythoncore depend on ws2_32.lib. I presume this is why _socket and _select have their own vcproj files. Maybe the socket functions could be moved directly to the top level of _multiprocessing instead since they are not really win32 functions. (And I suppose if that does not happen then _multiprocessing should also stop linking against ws2_32.lib.) BTW why does _select link against wsock32.lib instead of ws2_32.lib? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 22:10:21 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 14 Apr 2012 20:10:21 +0000 Subject: [issue14581] Support case-insensitive file extensions on Windows in importlib Message-ID: <1334434221.26.0.706558952592.issue14581@psf.upfronthosting.co.za> New submission from Brett Cannon : Importlib doesn't cover case-insensitivity on file extensions under Windows (see test.test_import.test_import: http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/41/steps/test/logs/stdio). Should add a test to test_importlib and then fix (but only for Windows; apparently this isn't honoured under OS X even though it is case-insensitive). ---------- components: Windows messages: 158279 nosy: brett.cannon priority: release blocker severity: normal stage: needs patch status: open title: Support case-insensitive file extensions on Windows in importlib type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 22:31:41 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 14 Apr 2012 20:31:41 +0000 Subject: [issue14582] Have importlib use return value from a loader's load_module() Message-ID: <1334435501.08.0.930274319662.issue14582@psf.upfronthosting.co.za> New submission from Brett Cannon : Right now importlib doesn't use what loader.load_module() returns as that was what import.c did. But PEP 302 explicitly states that load_module() is expected to return the module that was loaded. So to save a dict lookup I want to rely on the return value of load_module(). ---------- assignee: brett.cannon components: Interpreter Core messages: 158280 nosy: brett.cannon priority: low severity: normal stage: test needed status: open title: Have importlib use return value from a loader's load_module() type: performance versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 22:45:31 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 14 Apr 2012 20:45:31 +0000 Subject: [issue14583] try/except import fails --without-threads Message-ID: <1334436331.01.0.461185960127.issue14583@psf.upfronthosting.co.za> New submission from Stefan Krah : In the build --without-threads, catching an ImportError in support.py fails. Fedora buildbot: http://www.python.org/dev/buildbot/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/1986/steps/test/logs/stdio ./python ./Tools/scripts/run_tests.py -j 1 -u all -W --timeout=3600 Traceback (most recent call last): File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/runpy.py", line 160, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/runpy.py", line 73, in _run_code exec(code, run_globals) File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/__main__.py", line 1, in from test import regrtest, support File "", line 1038, in _handle_fromlist File "", line 977, in _find_and_load File "", line 561, in load_module File "", line 218, in module_for_loader_wrapper File "", line 446, in _load_module File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/regrtest.py", line 243, in from test import support File "", line 1038, in _handle_fromlist File "", line 977, in _find_and_load File "", line 561, in load_module File "", line 218, in module_for_loader_wrapper File "", line 446, in _load_module File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/support.py", line 34, in import multiprocessing.process SystemError: NULL result without error in PyObject_Call [110893 refs] make: *** [buildbottest] Error 255 ---------- components: Tests messages: 158281 nosy: brett.cannon, skrah priority: normal severity: normal stage: needs patch status: open title: try/except import fails --without-threads type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 22:48:16 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 14 Apr 2012 20:48:16 +0000 Subject: [issue14584] Add gzip support the XMLRPC Server Message-ID: <1334436496.76.0.995633405639.issue14584@psf.upfronthosting.co.za> New submission from Raymond Hettinger : The xmlrpclib client already supports gzipped data and say so in the HTTP header: "Accept-Encoding: gzip". Our XMLRPC Server ignores this header and always sends uncompressed data. ---------- messages: 158282 nosy: rhettinger priority: normal severity: normal status: open title: Add gzip support the XMLRPC Server type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 23:15:38 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 14 Apr 2012 21:15:38 +0000 Subject: [issue14581] Support case-insensitive file extensions on Windows in importlib In-Reply-To: <1334434221.26.0.706558952592.issue14581@psf.upfronthosting.co.za> Message-ID: <1334438138.03.0.415677926106.issue14581@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 23:17:09 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 14 Apr 2012 21:17:09 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: <1334438229.28.0.974939676184.issue11750@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: It shouldn't. I noticed this and fixed this at CCP a while back but I wasn't in Python Committer mode at the time. _select needs fixing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 23:21:21 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 14 Apr 2012 21:21:21 +0000 Subject: [issue14582] Have importlib use return value from a loader's load_module() In-Reply-To: <1334435501.08.0.930274319662.issue14582@psf.upfronthosting.co.za> Message-ID: <1334438481.71.0.707548610364.issue14582@psf.upfronthosting.co.za> Eric Snow added the comment: big +1! I went quite a while before realizing that loader.load_module() was supposed to return the module, due to this specific issue. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 23:22:35 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 14 Apr 2012 21:22:35 +0000 Subject: [issue14580] imp.reload can fail for sub-modules In-Reply-To: <1334429743.69.0.840922249937.issue14580@psf.upfronthosting.co.za> Message-ID: <1334438555.51.0.784426545067.issue14580@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 23:23:35 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 14 Apr 2012 21:23:35 +0000 Subject: [issue14583] try/except import fails --without-threads In-Reply-To: <1334436331.01.0.461185960127.issue14583@psf.upfronthosting.co.za> Message-ID: <1334438615.24.0.0762356944761.issue14583@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 23:30:28 2012 From: report at bugs.python.org (Roger Serwy) Date: Sat, 14 Apr 2012 21:30:28 +0000 Subject: [issue14575] IDLE crashes after file open in OS X In-Reply-To: <1334378092.39.0.081519751274.issue14575@psf.upfronthosting.co.za> Message-ID: <1334439028.52.0.411774438491.issue14575@psf.upfronthosting.co.za> Roger Serwy added the comment: Hugh, Can you launch IDLE from the terminal and report the error message you receive? From a regular Terminal, enter: python -m idlelib.idle FILE_TO_OPEN.py ---------- nosy: +serwy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 23:37:25 2012 From: report at bugs.python.org (Vladan Djeric) Date: Sat, 14 Apr 2012 21:37:25 +0000 Subject: [issue14574] SocketServer doesn't handle client disconnects properly In-Reply-To: <1334358462.67.0.980544384901.issue14574@psf.upfronthosting.co.za> Message-ID: <1334439445.27.0.556773865165.issue14574@psf.upfronthosting.co.za> Vladan Djeric added the comment: Thank you for taking a look Charles-Fran?ois. I should note that catching the first exception in the request handler and then calling self.wfile.close() wouldn't fully solve the issue. The self.wfile.close() call would throw another broken pipe exception (which is ok & can be caught), but the BaseHTTPServer code would also throw an exception when it tries to flush the (now closed) wfile after returing from the do_POST request handler. ---------------------------------------- Exception happened during processing of request from ('127.0.0.1', 50611) Traceback (most recent call last): File "C:\Python27\lib\SocketServer.py", line 284, in _handle_request_noblock self.process_request(request, client_address) File "C:\Python27\lib\SocketServer.py", line 310, in process_request self.finish_request(request, client_address) File "C:\Python27\lib\SocketServer.py", line 323, in finish_request self.RequestHandlerClass(request, client_address, self) File "C:\Python27\lib\SocketServer.py", line 638, in __init__ self.handle() File "C:\Python27\lib\BaseHTTPServer.py", line 340, in handle self.handle_one_request() File "C:\Python27\lib\BaseHTTPServer.py", line 329, in handle_one_request self.wfile.flush() #actually send the response if not already done. File "C:\Python27\lib\socket.py", line 303, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) AttributeError: 'NoneType' object has no attribute 'sendall' ---------------------------------------- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 23:39:50 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 14 Apr 2012 21:39:50 +0000 Subject: [issue14575] IDLE crashes after file open in OS X In-Reply-To: <1334378092.39.0.081519751274.issue14575@psf.upfronthosting.co.za> Message-ID: <1334439590.05.0.93431296047.issue14575@psf.upfronthosting.co.za> Ned Deily added the comment: This is almost certainly due to using the Apple-supplied Tcl/Tk 8.5 in Mac OS X 10.6. The Apple-suppied version of Tcl/Tk is buggy to the point of being unusable with Tkinter applications, in particular IDLE. There are many duplicate issues on similar problems, for instance, Issue12269. One solution is to use a current 64-bit/32-bit python.org installer (at the moment, 2.7.3 is the latest for Python 2) *and* install the latest ActiveState Tcl/Tk 8.5. See http://www.python.org/download/mac/tcltk/ for more details. ---------- nosy: +ned.deily resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 23:54:57 2012 From: report at bugs.python.org (Roger Serwy) Date: Sat, 14 Apr 2012 21:54:57 +0000 Subject: [issue14576] IDLE cannot connect to subprocess - New solution In-Reply-To: <1334400065.92.0.605072928338.issue14576@psf.upfronthosting.co.za> Message-ID: <1334440497.28.0.703903513781.issue14576@psf.upfronthosting.co.za> Roger Serwy added the comment: I can confirm that setting HOMEPATH to a non-existent directory will prevent IDLE from starting when using idle.bat. If you modify idle.bat such that python.exe is called instead of pythonw.exe, then IDLE starts normally, but with this console message: Warning: os.path.expanduser("~") points to C:\Users\doesnotexist but the path does not exist. Normally, the message is written to sys.stderr, which is None when using pythonw. See issue13582 for more information. ---------- nosy: +asvetlov, serwy, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 14 23:57:35 2012 From: report at bugs.python.org (Roger Serwy) Date: Sat, 14 Apr 2012 21:57:35 +0000 Subject: [issue8900] IDLE crashes if Preference set to At Startup -> Open Edit Window In-Reply-To: <1275695898.02.0.763223364629.issue8900@psf.upfronthosting.co.za> Message-ID: <1334440655.59.0.0997764938104.issue8900@psf.upfronthosting.co.za> Changes by Roger Serwy : ---------- nosy: +asvetlov, terry.reedy type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 00:06:38 2012 From: report at bugs.python.org (Roger Serwy) Date: Sat, 14 Apr 2012 22:06:38 +0000 Subject: [issue9925] Idle doesn't launch In-Reply-To: <1285249574.15.0.491090079116.issue9925@psf.upfronthosting.co.za> Message-ID: <1334441198.05.0.827433775837.issue9925@psf.upfronthosting.co.za> Roger Serwy added the comment: Is this still a valid issue? ---------- status: open -> pending type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 00:08:45 2012 From: report at bugs.python.org (Roger Serwy) Date: Sat, 14 Apr 2012 22:08:45 +0000 Subject: [issue8820] IDLE not launching correctly In-Reply-To: <1274842084.45.0.257196773636.issue8820@psf.upfronthosting.co.za> Message-ID: <1334441325.76.0.397281044886.issue8820@psf.upfronthosting.co.za> Roger Serwy added the comment: Joseph, Jeff, Is this still a valid issue with the latest release of IDLE? ---------- status: open -> pending type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 00:10:06 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 14 Apr 2012 22:10:06 +0000 Subject: [issue14006] Improve the documentation of xml.etree.ElementTree In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za> Message-ID: <1334441406.83.0.631724366382.issue14006@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 00:12:45 2012 From: report at bugs.python.org (Roger Serwy) Date: Sat, 14 Apr 2012 22:12:45 +0000 Subject: [issue9150] IDLE should not save trailing whitespace after strip trailing whitespace has been used In-Reply-To: <1278179945.62.0.903425904075.issue9150@psf.upfronthosting.co.za> Message-ID: <1334441565.1.0.491412039243.issue9150@psf.upfronthosting.co.za> Roger Serwy added the comment: Ryan, is this still an issue? ---------- status: open -> pending versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 00:17:25 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 14 Apr 2012 22:17:25 +0000 Subject: [issue14578] importlib doesn't check Windows registry for paths In-Reply-To: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za> Message-ID: <1334441845.8.0.848250592235.issue14578@psf.upfronthosting.co.za> Brett Cannon added the comment: You could just expose it, but on Windows I believe all extension modules are builtins, so you should be able to properly use _winreg to get at the registry and thus not require keeping the C code around. But that's just a guess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 00:28:38 2012 From: report at bugs.python.org (Roger Serwy) Date: Sat, 14 Apr 2012 22:28:38 +0000 Subject: [issue9803] IDLE closes with save while breakpoint open In-Reply-To: <1283974949.4.0.785258120567.issue9803@psf.upfronthosting.co.za> Message-ID: <1334442518.18.0.476719996981.issue9803@psf.upfronthosting.co.za> Roger Serwy added the comment: This is a duplicate of #6257. ---------- nosy: +serwy resolution: -> duplicate status: open -> closed superseder: -> Idle terminates on source save while debugging _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 00:41:22 2012 From: report at bugs.python.org (Roger Serwy) Date: Sat, 14 Apr 2012 22:41:22 +0000 Subject: [issue3493] No Backslash (\) in IDLE 1.2.2 In-Reply-To: <1217703828.28.0.450562077127.issue3493@psf.upfronthosting.co.za> Message-ID: <1334443282.79.0.59991935623.issue3493@psf.upfronthosting.co.za> Roger Serwy added the comment: Is this still an issue with the latest version of IDLE? ---------- nosy: +serwy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 00:47:31 2012 From: report at bugs.python.org (Roger Serwy) Date: Sat, 14 Apr 2012 22:47:31 +0000 Subject: [issue6649] idlelib/rpc.py missing exit status on exithook In-Reply-To: <1249489269.49.0.307291234061.issue6649@psf.upfronthosting.co.za> Message-ID: <1334443651.12.0.0797559672329.issue6649@psf.upfronthosting.co.za> Roger Serwy added the comment: The existing code will raise an error since os._exit requires an argument. http://docs.python.org/library/os.html#os._exit The patch looks good to me. ---------- nosy: +serwy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 01:05:32 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 14 Apr 2012 23:05:32 +0000 Subject: [issue14581] Support case-insensitive file extensions on Windows in importlib In-Reply-To: <1334434221.26.0.706558952592.issue14581@psf.upfronthosting.co.za> Message-ID: <1334444732.94.0.769566440791.issue14581@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, is supporting this really necessary? It's a special case on Windows only; even OS X which is also case-insensitive doesn't support this. But if it does need to be supported, then does someone know if this extends to all module types or only .py and .pyw files (e.g. do .pyc files need this along with extension modules)? If there is no special-casing to that extent then _PathFinder.find_module() will need to cache all files with lowercase file extensions no matter what PYTHONCASEOK says on Windows. That way the performance is only costly at cache building time and there is no expensive checking for all other OSs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 01:08:39 2012 From: report at bugs.python.org (Roger Serwy) Date: Sat, 14 Apr 2012 23:08:39 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1334444919.9.0.505356187139.issue2377@psf.upfronthosting.co.za> Roger Serwy added the comment: Brett, your latest commit breaks IDLE. Here's the error message: Failed to import extension: FormatParagraph Failed to load extension 'FormatParagraph' Traceback (most recent call last): File "./idlelib/EditorWindow.py", line 998, in load_standard_extensions self.load_extension(name) File "./idlelib/EditorWindow.py", line 1008, in load_extension mod = __import__(name, globals(), locals(), []) File "", line 974, in _find_and_load ImportError: No module named 'FormatParagraph' Same error occurs for ZoomHeight, ScriptBinding, CallTips, ParenMatch, and AutoComplete. I reverted to e730da0cd489, recompiled, and these errors went away. Just to be sure, I updated to tip, recompiled, and the errors reappeared. ---------- nosy: +serwy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 01:15:30 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 14 Apr 2012 23:15:30 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1334445330.06.0.979768933564.issue2377@psf.upfronthosting.co.za> Brett Cannon added the comment: Another thing to note: index does not default to -1 anymore but to 0; bug that should have gone away in Python 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 01:20:13 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 14 Apr 2012 23:20:13 +0000 Subject: [issue3493] No Backslash (\) in IDLE 1.2.2 In-Reply-To: <1217703828.28.0.450562077127.issue3493@psf.upfronthosting.co.za> Message-ID: <1334445613.92.0.591215779687.issue3493@psf.upfronthosting.co.za> Ned Deily added the comment: The problem of not honoring alternate input methods should no longer be a problem when using a current ActiveState Tcl/Tk 8.5.x on Mac OS X and a Python that is built to link with it, such as the current Python 2.7.x and 3.2.x installers from python.org. At the moment, there are no released Apple-supplied Tcl/Tks (and Pythons) that have all the necessary fixes. See http://www.python.org/download/mac/tcltk/ for more details about recommended Python and Tcl/Tk versions on OS X. ---------- assignee: ronaldoussoren -> ned.deily nosy: +ned.deily resolution: -> out of date stage: -> committed/rejected status: open -> closed versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 01:22:45 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 14 Apr 2012 23:22:45 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1334445765.24.0.352778877323.issue2377@psf.upfronthosting.co.za> Brett Cannon added the comment: So IDLE broke because it was relying on buggy behaviour accidentally left in Python 2.7 and carried forward (plus it was not updated to use best practices like importlib.import_module()). Roger, can you try the patch I have uploaded and see if that fixes things? ---------- Added file: http://bugs.python.org/file25218/update_idle.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 01:38:57 2012 From: report at bugs.python.org (Roger Serwy) Date: Sat, 14 Apr 2012 23:38:57 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1334446737.59.0.623443833405.issue2377@psf.upfronthosting.co.za> Roger Serwy added the comment: I tested update_idle.diff and it corrects the issue. While IDLE's use of __import__ may be "buggy", I don't see anything in the documentation about deprecation or other warnings about this usage. This is a backwards-incompatible change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 02:01:48 2012 From: report at bugs.python.org (Roger Serwy) Date: Sun, 15 Apr 2012 00:01:48 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1334448108.2.0.936134034231.issue2377@psf.upfronthosting.co.za> Roger Serwy added the comment: I caused a segmentation fault with the following (on Linux): $ mkdir crash $ touch crash/mod.py $ echo "__import__('mod', globals(), locals(), [], 1)" > crash/__init__.py $ ./python3 -m crash ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 02:18:43 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 15 Apr 2012 00:18:43 +0000 Subject: [issue12436] Missing items in installation/setup instructions In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za> Message-ID: <1334449123.74.0.649955269669.issue12436@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 02:19:19 2012 From: report at bugs.python.org (Roger Serwy) Date: Sun, 15 Apr 2012 00:19:19 +0000 Subject: [issue12387] IDLE save keyboard shortcut problem In-Reply-To: <1308765598.77.0.79184481064.issue12387@psf.upfronthosting.co.za> Message-ID: <1334449159.99.0.822328931072.issue12387@psf.upfronthosting.co.za> Roger Serwy added the comment: I can confirm this issue on Linux. This issue is caused by not explicitly binding to <> in config-keys.def (and in configHandler.py's GetCoreKeys.) Presently, only binds to <>. Should all the lowercase bindings without uppercase bindings be changed, or should only a few be changed? ---------- keywords: +easy nosy: +serwy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 02:53:24 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 15 Apr 2012 00:53:24 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1334451204.73.0.794958712811.issue2377@psf.upfronthosting.co.za> Brett Cannon added the comment: I committed the fix. Thanks for testing, Roger. As for the change in semantics, I'm fully aware it is not backwards-compatible. Unfortunately the incorrect usage was not even discovered until I started my bootstrap work because the import statement does the right thing but __import__() itself was never updated so it is only noticeable if you never updated your code to use importlib.import_module() which has been the preferred way to programmatically import code since Python 2.7/3.1. Plus the correct semantics are documented in PEP 328 (http://python.org/dev/peps/pep-0328/) and referenced in the language spec (http://docs.python.org/py3k/reference/simple_stmts.html#the-import-statement) so I'm not going to change it back since this brings the function more in line with expectations. And since the fix is as simple as a try/except and two import calls then it falls within the realm of having to fix code for any new Python release. And as for the crash, I will have a look. ---------- resolution: fixed -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 03:25:08 2012 From: report at bugs.python.org (Roger Serwy) Date: Sun, 15 Apr 2012 01:25:08 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1334453108.68.0.634385905192.issue2377@psf.upfronthosting.co.za> Roger Serwy added the comment: Brett, I see your point. The docs for __import__ should be updated to include your two-import fix as well as reference PEP328. http://docs.python.org/dev/library/functions.html?highlight=__import__#__import__ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 03:27:25 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 15 Apr 2012 01:27:25 +0000 Subject: [issue14585] Have test_import run more importlib tests Message-ID: <1334453245.9.0.0799360762368.issue14585@psf.upfronthosting.co.za> New submission from Brett Cannon : As it stands, test_import runs importlib.test.import_.test_relative_imports. It would probably be better to have test_import run all importlib tests using __import__(), especially since it is already coded up in importlib.test.__main__ to do so. In all honesty I'm willing to bet there is some duplication in test_import that can just go away if someone put the time in to try to prune the file down. ---------- messages: 158306 nosy: brett.cannon priority: normal severity: normal status: open title: Have test_import run more importlib tests _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 03:27:43 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 15 Apr 2012 01:27:43 +0000 Subject: [issue14585] Have test_import run more importlib tests In-Reply-To: <1334453245.9.0.0799360762368.issue14585@psf.upfronthosting.co.za> Message-ID: <1334453263.02.0.190313792652.issue14585@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- components: +Tests stage: -> needs patch versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 03:27:46 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 15 Apr 2012 01:27:46 +0000 Subject: [issue14585] Have test_import run more importlib tests In-Reply-To: <1334453245.9.0.0799360762368.issue14585@psf.upfronthosting.co.za> Message-ID: <1334453266.8.0.353256627355.issue14585@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 03:36:34 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 15 Apr 2012 01:36:34 +0000 Subject: [issue14585] Have test_import run more importlib tests In-Reply-To: <1334453245.9.0.0799360762368.issue14585@psf.upfronthosting.co.za> Message-ID: <1334453794.32.0.146524016219.issue14585@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 03:52:38 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 15 Apr 2012 01:52:38 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1334454758.31.0.976107911379.issue2377@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, crasher is fixed (as is importlib as it failed on the test case as well thanks to the slicing of [:-0] returning the empty string instead of the entire string). And I will update the docs to be a bit more clear about things (at least those docs have the right default value for level). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 04:04:33 2012 From: report at bugs.python.org (Guy Taylor) Date: Sun, 15 Apr 2012 02:04:33 +0000 Subject: [issue14586] TypeError: truncate() takes no keyword arguments Message-ID: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za> New submission from Guy Taylor : The Python docs suggest that io.IOBase.truncate' should take a keyword argument of 'size'. However this causes a 'TypeError': TypeError: truncate() takes no keyword arguments Suggest that the docs are changed to 'truncate(size)' or CPython is changed to allow the keyword. http://docs.python.org/py3k/library/io.html?highlight=truncate#io.IOBase.truncate http://docs.python.org/library/io.html?highlight=truncate#io.IOBase.truncate ---------- assignee: docs at python components: Documentation, Interpreter Core files: test.py messages: 158308 nosy: TheBiggerGuy, docs at python priority: normal severity: normal status: open title: TypeError: truncate() takes no keyword arguments type: behavior versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file25219/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 04:05:26 2012 From: report at bugs.python.org (Andrew Regner) Date: Sun, 15 Apr 2012 02:05:26 +0000 Subject: [issue14102] argparse: add ability to create a man page In-Reply-To: <1330031760.56.0.8938390885.issue14102@psf.upfronthosting.co.za> Message-ID: <1334455526.09.0.593271790415.issue14102@psf.upfronthosting.co.za> Changes by Andrew Regner : ---------- nosy: +adregner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 05:46:31 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Apr 2012 03:46:31 +0000 Subject: [issue12387] IDLE save keyboard shortcut problem In-Reply-To: <1308765598.77.0.79184481064.issue12387@psf.upfronthosting.co.za> Message-ID: <1334461591.28.0.614442837182.issue12387@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I would like to see them all changed. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 05:58:31 2012 From: report at bugs.python.org (py.user) Date: Sun, 15 Apr 2012 03:58:31 +0000 Subject: [issue14519] In re's examples the example with scanf() contains wrong analog for %x, %X specifiers In-Reply-To: <1333757996.58.0.360922081437.issue14519@psf.upfronthosting.co.za> Message-ID: <1334462311.71.0.967949320169.issue14519@psf.upfronthosting.co.za> py.user added the comment: the same problem in the %o analog valid strings for the %x specifier of scanf(): "+0xabc" "-0xabc" "+abc" "-abc" valid strings for the %o specifier of scanf(): "+0123" "-0123" "+123" "-123" how to patch the %x specifier: 0[xX][\dA-Fa-f]+ -> [-+]?(0[xX])?[\dA-Fa-f]+ the %o specifier: 0[0-7]* -> [-+]?[0-7]+ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 06:50:11 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 15 Apr 2012 04:50:11 +0000 Subject: [issue8900] IDLE crashes if Preference set to At Startup -> Open Edit Window In-Reply-To: <1275695898.02.0.763223364629.issue8900@psf.upfronthosting.co.za> Message-ID: <1334465411.9.0.33851838985.issue8900@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Brett C. just today pushed http://hg.python.org/cpython/rev/556b9bafdee8 changeset: 76310:556b9bafdee8 user: Brett Cannon date: Sat Apr 14 20:44:23 2012 -0400 summary: IDLE was relying on implicit relative imports which have gone away in Python 3.3 thanks to importlib finishing the work in PEP 328 that accidently got carried forward. I don't know if this patch will have any affect on this issue, but implicit relative imports are (were;-) a possible cause of intermittent problems. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 06:53:39 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 15 Apr 2012 04:53:39 +0000 Subject: [issue12387] IDLE save keyboard shortcut problem In-Reply-To: <1308765598.77.0.79184481064.issue12387@psf.upfronthosting.co.za> Message-ID: <1334465619.69.0.306570239803.issue12387@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree; lets be consistently lenient. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 08:52:43 2012 From: report at bugs.python.org (Martin Panter) Date: Sun, 15 Apr 2012 06:52:43 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1334472763.89.0.262215195691.issue3982@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 08:53:20 2012 From: report at bugs.python.org (Ross Lagerwall) Date: Sun, 15 Apr 2012 06:53:20 +0000 Subject: [issue12081] Remove distributed copy of libffi In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za> Message-ID: <1334472800.6.0.400954239.issue12081@psf.upfronthosting.co.za> Ross Lagerwall added the comment: In any case, it should be OK to remove libffi_arm_wince? Is WinCE supported? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 09:07:02 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Apr 2012 07:07:02 +0000 Subject: [issue1508475] transparent gzip compression in urllib Message-ID: <1334473622.93.0.956043324282.issue1508475@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 11:25:32 2012 From: report at bugs.python.org (Peter Nielsen) Date: Sun, 15 Apr 2012 09:25:32 +0000 Subject: [issue3493] No Backslash (\) in IDLE 1.2.2 In-Reply-To: <1334443282.79.0.59991935623.issue3493@psf.upfronthosting.co.za> Message-ID: Peter Nielsen added the comment: Hello there Yes, I am afraid the problem persists. I have downloaded version 3.2.3 of python 32 bit. In terminal in OSX 10.7.3, you can use the keys ALT + SHIFT and 7 to get the \ but in the Idle application there is no way to do that. Kind Regards / Med venlig hilsen Peter Nielsen On Sun, Apr 15, 2012 at 12:41 AM, Roger Serwy wrote: > > Roger Serwy added the comment: > > Is this still an issue with the latest version of IDLE? > > ---------- > nosy: +serwy > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 11:51:32 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Apr 2012 09:51:32 +0000 Subject: [issue1508475] transparent gzip compression in urllib Message-ID: <1334483492.4.0.124242355754.issue1508475@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What if the gzip module is not available? I think, with transparent decompression should delete headers Content-Encoding (to free the user from re-decompression) and Content-Length (which is wrong). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 12:03:23 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 15 Apr 2012 10:03:23 +0000 Subject: [issue3493] No Backslash (\) in IDLE 1.2.2 In-Reply-To: <1217703828.28.0.450562077127.issue3493@psf.upfronthosting.co.za> Message-ID: <1334484203.21.0.535748876708.issue3493@psf.upfronthosting.co.za> Ned Deily added the comment: Peter: I'm sorry that I didn't make it clearer in my reply that you need to use the 64-bit/32-bit python.org installers (available for OS X 10.6 and above), not the 32-bit-only installers. The 32-bit-only-installers are linked with Tcl/Tk 8.4 since there is no version of Apple- or ActiveState- Tcl/Tk 8.5 available for all platforms supported by the 32-bit-only installers (10.3+, Intel and PPC). The input method support is only in the Cocoa Tcl/Tk 8.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 12:42:47 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 15 Apr 2012 10:42:47 +0000 Subject: [issue14507] Segfault with starmap and izip combo In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1334486567.21.0.0658807288151.issue14507@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: You are creating a 100000 level nested structure of iterators. It is no wonder that you exhaust the stack space of the interpreter. You would get the same with any iterator combination, nothing special with zip and starmap here. I can't see that anything can be done about this, unless we can create some sort of non-recursive iternext slot, which returns an evaluation context, rather than an item, similar to what stackless does. ---------- nosy: +kristjan.jonsson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 13:21:48 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 15 Apr 2012 11:21:48 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: <1334488908.78.0.0103899647434.issue11750@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: (fixed wsock32.lib in revision ab0aff639cfb) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 13:26:07 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 15 Apr 2012 11:26:07 +0000 Subject: [issue14574] SocketServer doesn't handle client disconnects properly In-Reply-To: <1334358462.67.0.980544384901.issue14574@psf.upfronthosting.co.za> Message-ID: <1334489167.35.0.884169164902.issue14574@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: I think this needs serious consideration. There needs to be an "socket error" case cleanup path that releases resources but ignores further socket errors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 13:42:22 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 15 Apr 2012 11:42:22 +0000 Subject: [issue10576] Add a progress callback to gcmodule In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 88f8ef5785d7 by Kristj?n Valur J?nsson in branch 'default': Issue #10576: Add a progress callback to gcmodule http://hg.python.org/cpython/rev/88f8ef5785d7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 13:43:36 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 15 Apr 2012 11:43:36 +0000 Subject: [issue10576] Add a progress callback to gcmodule In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za> Message-ID: <1334490216.9.0.47482674647.issue10576@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 13:58:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Apr 2012 11:58:19 +0000 Subject: [issue14507] Segfault with starmap and izip combo In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1334491099.09.0.00556553298492.issue14507@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Kristj?n, we already have provisions to avoid stack overflows, instead bailing out with a RuntimeError. So this is a bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 14:03:27 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 15 Apr 2012 12:03:27 +0000 Subject: [issue13889] str(float) and round(float) issues with FPU precision In-Reply-To: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za> Message-ID: <1334491407.25.0.75822673999.issue13889@psf.upfronthosting.co.za> Mark Dickinson added the comment: Slightly reworked patch. I plan to apply this shortly. - Use ~(_MCW_PC | _MCW_RC) rather than (_MCW_DN | ...), since this seems more future proof: there's a possibility that more flags could be added later. - Put the usual do { ... } while (0) around the _Py_SET_53BIT_PRECISION_END - Make it clear that we don't care about the return value of the second two __control87_2 patches. - Minor style fixes (e.g., spaces around a "bitwise and" ampersand to help distinguish it from an "address of" ampersand). I'm not too worried about the fenv_access pragma: it seems that the main thing it would guard against is compile-time folding and evaluation of expressions, where the compiler isn't taking the possibility of control word changes into account. As far as I can tell, we shouldn't really care about this, since at the time that Python itself is compiled, the control word is likely to be what we want. ---------- Added file: http://bugs.python.org/file25220/issue13889_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 14:14:28 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 15 Apr 2012 12:14:28 +0000 Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za> Message-ID: <1334492068.06.0.821842239183.issue4130@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you please re-upload this as a unified diff? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 14:27:52 2012 From: report at bugs.python.org (Alex Leach) Date: Sun, 15 Apr 2012 12:27:52 +0000 Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za> Message-ID: <1334492872.94.0.930477861208.issue4130@psf.upfronthosting.co.za> Changes by Alex Leach : Added file: http://bugs.python.org/file25221/ffi64.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 14:31:09 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 15 Apr 2012 12:31:09 +0000 Subject: [issue8212] A tp_dealloc of a subclassed class cannot resurrect an object In-Reply-To: <1269350912.78.0.210466349131.issue8212@psf.upfronthosting.co.za> Message-ID: <1334493069.87.0.200450487444.issue8212@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Here is a patch that rectifies this situation, albeit in a somewhat 'hacky' manner. It works by injecting a monitoring 'tp_free' call into the type during the basedealloc call, which sets a flag if it was called with the object, i.e. if actual deletion took place. This value is then returned, and a decision to decref the object's "type" is made on this result. ---------- keywords: +patch versions: +Python 3.3 -Python 3.2 Added file: http://bugs.python.org/file25222/basedealloc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 14:33:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Apr 2012 12:33:08 +0000 Subject: [issue9303] Migrate sqlite3 module to _v2 API to enhance performance In-Reply-To: <1279541286.68.0.824716490463.issue9303@psf.upfronthosting.co.za> Message-ID: <1334493188.34.0.895771494706.issue9303@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: needs patch -> patch review versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 14:35:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Apr 2012 12:35:18 +0000 Subject: [issue12081] Remove distributed copy of libffi In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za> Message-ID: <1334493318.4.0.787991212775.issue12081@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 14:45:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Apr 2012 12:45:26 +0000 Subject: [issue12081] Remove distributed copy of libffi In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za> Message-ID: <1334493926.15.0.653300208603.issue12081@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't think we have ever "supported" WinCE (which is apparently named "Windows Embedded Compact 7" nowadays). It only provides a subset of the Win32 API so the current tree may not even compile. ---------- nosy: +brian.curtin, loewis, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 15:14:20 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Apr 2012 13:14:20 +0000 Subject: [issue14507] Segfault with deeply nested starmap calls In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1334495660.29.0.71154021853.issue14507@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The "RuntimeError: maximum recursion depth exceeded" message is normally only triggered by pure Python recursion, so I would not have expected it here, but there should be some sort of graceful MemoryError or somesuch rather than a segfault. The following code narrows it down to some issue in starmap(): def gstarmap(func, iterable): for tup in iterable: yield func(*tup) def mylist(iterable): return [x for x in iterable] a = b = [1] for i in xrange(100000): # Things that trigger a segfault: #a = starmap(add, izip(a, b)) #a = starmap(add, iter( (a, b) )) a = starmap(add, (a, b) ) # Things that exit cleanly with a RuntimeError #a = gstarmap(add, iter( (a, b) )) #a = (x+y for x, y in iter( (a, b) )) mylist(a) One possibility may be that starmap.next needs to clear StopIteration exceptions in the same way as PyIter_Next(): if (result == NULL && PyErr_Occurred() && PyErr_ExceptionMatches(PyExc_StopIteration)) PyErr_Clear(); ---------- priority: normal -> low title: Segfault with starmap and izip combo -> Segfault with deeply nested starmap calls _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 15:34:00 2012 From: report at bugs.python.org (sbt) Date: Sun, 15 Apr 2012 13:34:00 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: <1334496840.38.0.0797117663983.issue11750@psf.upfronthosting.co.za> sbt added the comment: New patch. Compared to the previous one: * socket functions have been moved from _windows to _multiprocessing * _windows.vcpoj has been removed (so _windows is part of pythoncore.vcproj) * no changes to pcbuild.sln needed * removed reference to 'win32_functions.c' in setup.py (I am not sure whether/how setup.py is used on Windows.) Lib/multiprocessing/connection.py | 124 +- Lib/multiprocessing/forking.py | 31 +- Lib/multiprocessing/heap.py | 6 +- Lib/multiprocessing/reduction.py | 6 +- Lib/subprocess.py | 104 +- Lib/test/test_multiprocessing.py | 2 +- Modules/_multiprocessing/multiprocessing.c | 83 +- Modules/_multiprocessing/win32_functions.c | 823 ---------------- Modules/_windows.c | 1337 +++++++++++++++++++++++++++ PC/_subprocess.c | 697 -------------- PC/config.c | 6 +- PCbuild/_multiprocessing.vcproj | 4 - PCbuild/pythoncore.vcproj | 8 +- setup.py | 1 - 14 files changed, 1568 insertions(+), 1664 deletions(-) ---------- Added file: http://bugs.python.org/file25223/windows_module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 16:12:52 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 15 Apr 2012 14:12:52 +0000 Subject: [issue8212] A tp_dealloc of a subclassed class cannot resurrect an object In-Reply-To: <1269350912.78.0.210466349131.issue8212@psf.upfronthosting.co.za> Message-ID: <1334499172.75.0.479925006706.issue8212@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Another, less hacky but more intrusive, way would be to change the signature of tp_dealloc in a backwards compatible way: typedef void (*destructor)(PyObject *, int *destroyed); The destructor can then set the flag pointed to by 'destroyed' to 1 or 0, depending on whether actual destruction took place. The caller will set the flag to '1' by default. We could then change all internal destructors to conform, and know that external destructors will continue to work in the old way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 16:14:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Apr 2012 14:14:20 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1334496840.38.0.0797117663983.issue11750@psf.upfronthosting.co.za> Message-ID: <1334499205.3414.2.camel@localhost.localdomain> Antoine Pitrou added the comment: > New patch. Compared to the previous one: > > * socket functions have been moved from _windows to _multiprocessing > * _windows.vcpoj has been removed (so _windows is part of pythoncore.vcproj) > * no changes to pcbuild.sln needed > * removed reference to 'win32_functions.c' in setup.py I think the module would be better named _win32, since that's the name of the API (like POSIX under Unix). Also, it seems there are a couple of naming inconsistencies renaming (e.g. the overlapped wrapper is named "_multiprocessing.win32.Overlapped") Otherwise, I guess it's ok. > (I am not sure whether/how setup.py is used on Windows.) Neither do I. It may be used under mingw or cygwin, but we don't officially support these. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 16:14:44 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 15 Apr 2012 14:14:44 +0000 Subject: [issue13889] str(float) and round(float) issues with FPU precision In-Reply-To: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset dfc9a98a5fef by Mark Dickinson in branch '3.2': Issue #13889: On MSVC builds, set FPU control word at runtime for all string <-> float conversions. Patch by Samuel Iseli and Stefan Krah. http://hg.python.org/cpython/rev/dfc9a98a5fef New changeset 7eca620feb10 by Mark Dickinson in branch 'default': Issue #13889: Merge fix from 3.2. http://hg.python.org/cpython/rev/7eca620feb10 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 16:14:46 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Apr 2012 14:14:46 +0000 Subject: [issue14507] Segfault with deeply nested starmap calls In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1334499286.55.0.20346645911.issue14507@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Hmm, substituting PyIter_Next() didn't help. There isn't much else being done in starmap.next, just a call to: result = PyObject_Call(lz->func, args, NULL); I'm now wondering if starmap() is tickling a bug in PyObject_Call, perhaps memory being allocated but not checked for NULL or somesuch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 16:17:28 2012 From: report at bugs.python.org (Christian Clauss) Date: Sun, 15 Apr 2012 14:17:28 +0000 Subject: =?utf-8?q?=5Bissue14587=5D_Certain_diacritical_marks_can_and_should_be_ca?= =?utf-8?b?cGl0YWxpemVkLi4uIGUuZy4gw7wgLS0+IMOc?= Message-ID: <1334499448.33.0.168656695712.issue14587@psf.upfronthosting.co.za> New submission from Christian Clauss : BUGS: certain diacritical marks can and should be capitalized... str.upper() does not .replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?'), etc. str.lower() does not .replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?'), etc. str.title() has the same problems plus it capitalizes the letter _after_ a diacritic. e.g. 'l?sai'.title() --> 'L?Sai' with a capitol 'S' myUpper(), myLower(), myTitle() exhibit the correct behavior with a handful of diacritic marks. def myUpper(inString): return inString.upper().replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?') def myLower(inString): return inString.lower().replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?') def myTitle(inString): # WARNING: converts all whitespace to a single space returnValue = [] for theWord in inString.split(): returnValue.append(myUpper(theWord[:1]) + myLower(theWord[1:])) return ' '.join(returnValue) ---------- components: Unicode messages: 158332 nosy: Christian.Clauss, ezio.melotti priority: normal severity: normal status: open title: Certain diacritical marks can and should be capitalized... e.g. ? --> ? versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 16:19:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 15 Apr 2012 14:19:20 +0000 Subject: [issue13889] str(float) and round(float) issues with FPU precision In-Reply-To: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset bf3b77722c9f by Mark Dickinson in branch '2.7': Issue #13889: On MSVC builds, set FPU control word at runtime for all string <-> float conversions. Patch by Samuel Iseli and Stefan Krah. http://hg.python.org/cpython/rev/bf3b77722c9f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 16:21:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Apr 2012 14:21:09 +0000 Subject: [issue14573] json iterencode can not handle general iterators In-Reply-To: <1334355033.57.0.314676653112.issue14573@psf.upfronthosting.co.za> Message-ID: <1334499669.7.0.303153008629.issue14573@psf.upfronthosting.co.za> Antoine Pitrou added the comment: That's more of a feature request than a bug. By definition JSON can only represent a small subset of Python's types. Also, if you encode an iterator as a JSON list, you will get back a Python list when decoding the JSON representation, so it won't round-trip. ---------- nosy: +pitrou stage: test needed -> needs patch type: behavior -> enhancement versions: -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 16:38:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Apr 2012 14:38:03 +0000 Subject: [issue14507] Segfault with deeply nested starmap calls In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1334500683.23.0.509756174358.issue14507@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I'm now wondering if starmap() is tickling a bug in PyObject_Call, > perhaps memory being allocated but not checked for NULL or somesuch. The issue is that the code paths involved here circumvent recursion checking, so the stack blows up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 16:43:23 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 15 Apr 2012 14:43:23 +0000 Subject: =?utf-8?q?=5Bissue14587=5D_Certain_diacritical_marks_can_and_should_be_ca?= =?utf-8?b?cGl0YWxpemVkLi4uIGUuZy4gw7wgLS0+IMOc?= In-Reply-To: <1334499448.33.0.168656695712.issue14587@psf.upfronthosting.co.za> Message-ID: <1334501003.5.0.798483746835.issue14587@psf.upfronthosting.co.za> R. David Murray added the comment: It works fine if you use unicode. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 16:43:30 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 15 Apr 2012 14:43:30 +0000 Subject: [issue14507] Segfault with deeply nested starmap calls In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1334501010.33.0.36249445893.issue14507@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: a = map(add, a, b) also crashes this. a = chain(a, b) also. If, by "provisions" you speak of sys.max_recursion_depth, that is only invoked when executing "python" code. What's happening here is just simple c recursion trough function pointers, ending in stack overflow, at least on Windows: > python33_d.dll!chain_next(chainobject * lz) Line 1811 + 0x6 bytes C python33_d.dll!PyIter_Next(_object * iter) Line 2741 + 0xf bytes C python33_d.dll!chain_next(chainobject * lz) Line 1823 + 0xc bytes C python33_d.dll!PyIter_Next(_object * iter) Line 2741 + 0xf bytes C python33_d.dll!chain_next(chainobject * lz) Line 1823 + 0xc bytes C python33_d.dll!PyIter_Next(_object * iter) Line 2741 + 0xf bytes C ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 16:53:17 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Apr 2012 14:53:17 +0000 Subject: [issue14507] Segfault with deeply nested starmap calls In-Reply-To: <1334501010.33.0.36249445893.issue14507@psf.upfronthosting.co.za> Message-ID: <1334501543.3414.3.camel@localhost.localdomain> Antoine Pitrou added the comment: > a = map(add, a, b) also crashes this. > a = chain(a, b) also. > If, by "provisions" you speak of sys.max_recursion_depth, that is only > invoked when executing "python" code. There's nothing that prevents it from protecting C code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 17:10:08 2012 From: report at bugs.python.org (Christian Clauss) Date: Sun, 15 Apr 2012 15:10:08 +0000 Subject: =?utf-8?q?=5Bissue14587=5D_Certain_diacritical_marks_can_and_should_be_ca?= =?utf-8?b?cGl0YWxpemVkLi4uIGUuZy4gw7wgLS0+IMOc?= In-Reply-To: <1334501003.5.0.798483746835.issue14587@psf.upfronthosting.co.za> Message-ID: Christian Clauss added the comment: On Apr 15, 2012, at 4:43 PM, R. David Murray wrote: > > R. David Murray added the comment: > > It works fine if you use unicode. > > ---------- > nosy: +r.david.murray > resolution: -> invalid > stage: -> committed/rejected > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ What does it mean in this context to "use unicode"?? =============================================== In Idle... =============================================== Python 2.7.3 (v2.7.3:70274d53c1dd, Apr 9 2012, 20:52:43) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "copyright", "credits" or "license()" for more information. >>> lusai = u'l?sai' Unsupported characters in input >>> lusai = 'l?sai' Unsupported characters in input >>> print "???" Unsupported characters in input =============================================== In a script... Every time that I try to "use unicode" an exception is thrown. All try blocks in the following code trigger an exception =============================================== #/bin/bash/env python # -*- coding: utf-8 -*- print '==========' import sys # sys.version_info = sys.version_info(major=2, minor=7, micro=1, releaselevel='final', serial=0) print 'sys.version_info = {}.{}.{} {} {}'.format(sys.version_info[0], sys.version_info[1], sys.version_info[2], sys.version_info[3], sys.version_info[4]) import commands, os print 'os.name = {}'.format(os.name) print 'os.uname = {}'.format(os.uname()) print '==========' def myUpper(inString): return inString.upper().replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?') def myLower(inString): return inString.lower().replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?') def myTitle(inString): returnValue = [] for theWord in inString.split(): returnValue.append(myUpper(theWord[:1]) + myLower(theWord[1:])) return ' '.join(returnValue) def formatted(inValue, inSep = ' '): s = str(inValue) print ' s={}{}su={}{}sl={}{}st={}...'.format(s, inSep, s.upper(), inSep, s.lower(), inSep, s.title()) print ' s={}{}mu={}{}ml={}{}mt={}...'.format(s, inSep, myUpper(s), inSep, myLower(s), inSep, myTitle(s)) u = unicode(inValue, 'utf8') try: print ' u={}{}uu={}{}ul={}{}ut={}...'.format(u, inSep, u.upper(), inSep, u.lower(), inSep, u.title()) except: print "=== Exception thrown trying to print unicode({}, 'utf8')".format(repr(s)) kolnUpperUnspecified = str('K?LN') kolnUpperAsString = str('K?LN') kolnUpperAsUnicode = unicode('K?LN', 'utf8') kolnLowerUnspecified = str('k?ln') kolnLowerAsString = str('k?ln') kolnLowerAsUnicode = unicode('k?ln', 'utf8') formatted(kolnUpperUnspecified) formatted(kolnUpperAsString) try: formatted(kolnUpperAsUnicode) except: pass formatted(kolnLowerUnspecified) formatted(kolnLowerAsString) try: formatted(kolnLowerAsUnicode) except: pass formatted('?tto Clau? lives in the hamlet of L?sai in the village of L? in the valley of Val M?stair in the Canton of Graub?nden', '\n') formatted('Z?RICH is the largest city in Switzerland and the geographic center of the country is in ?lggi-Alp which can be reached via the L?tschberg Tunnel', '\n') formatted('20% of Swiss people speak Franz?sisch but only 0.5% speak R?toromanisch', '\n') formatted('L?SAI, l?sai, M?nchen, Neuch?tel, Ny-?lesund, Troms?, Z?RICH', '\n') print """BUGS: certain diacritical marks can and should be capitalized... str.upper() does not .replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?'), etc. str.lower() does not .replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?'), etc. str.title() has the same problems plus it capitalizes the letter _after_ a diacritic. e.g. 'l?sai'.title() --> 'L?Sai' with a capitol 'S' myUpper(), myLower(), myTitle() exhibit the correct behavior with a handful of diacritic marks.""" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 17:43:47 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 15 Apr 2012 15:43:47 +0000 Subject: [issue13496] bisect module: Overflow at index computation In-Reply-To: <1322519672.22.0.173147243777.issue13496@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 35a3a7e0d66d by Mark Dickinson in branch '3.2': Issue 13496: Fix bisect.bisect overflow bug for large collections. http://hg.python.org/cpython/rev/35a3a7e0d66d New changeset 1a9252280f07 by Mark Dickinson in branch 'default': Issue #13496: Merge from 3.2 http://hg.python.org/cpython/rev/1a9252280f07 New changeset 709af2d0e862 by Mark Dickinson in branch '2.7': Issue 13496: Fix bisect.bisect overflow bug for large collections. http://hg.python.org/cpython/rev/709af2d0e862 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 17:44:15 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 15 Apr 2012 15:44:15 +0000 Subject: [issue13496] bisect module: Overflow at index computation In-Reply-To: <1322519672.22.0.173147243777.issue13496@psf.upfronthosting.co.za> Message-ID: <1334504655.57.0.0836672090432.issue13496@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 17:50:56 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 15 Apr 2012 15:50:56 +0000 Subject: =?utf-8?q?=5Bissue14587=5D_Certain_diacritical_marks_can_and_should_be_ca?= =?utf-8?b?cGl0YWxpemVkLi4uIGUuZy4gw7wgLS0+IMOc?= In-Reply-To: <1334499448.33.0.168656695712.issue14587@psf.upfronthosting.co.za> Message-ID: <1334505056.36.0.0441811962104.issue14587@psf.upfronthosting.co.za> Martin v. L?wis added the comment: In addition to R. David's remark, it also works fine in a German locale. In general, you cannot know whether the byte '\xe4' denotes '?' or some other letter. For example, in KOI8-R, it denotes ?, instead, which already is an upper-case letter. So either do setlocale at the start of your program, or (better) switch to Unicode strings. Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print u'?'.upper() ? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 17:50:58 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 15 Apr 2012 15:50:58 +0000 Subject: [issue13889] str(float) and round(float) issues with FPU precision In-Reply-To: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za> Message-ID: <1334505058.01.0.373385439171.issue13889@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 17:57:28 2012 From: report at bugs.python.org (Meador Inge) Date: Sun, 15 Apr 2012 15:57:28 +0000 Subject: [issue14507] Segfault with deeply nested starmap calls In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1334505448.12.0.220888909644.issue14507@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 17:59:20 2012 From: report at bugs.python.org (Meador Inge) Date: Sun, 15 Apr 2012 15:59:20 +0000 Subject: [issue8212] A tp_dealloc of a subclassed class cannot resurrect an object In-Reply-To: <1269350912.78.0.210466349131.issue8212@psf.upfronthosting.co.za> Message-ID: <1334505560.54.0.191546900655.issue8212@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 18:02:10 2012 From: report at bugs.python.org (Meador Inge) Date: Sun, 15 Apr 2012 16:02:10 +0000 Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za> Message-ID: <1334505730.02.0.788957480477.issue4130@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 18:47:43 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Apr 2012 16:47:43 +0000 Subject: [issue14507] Segfault with deeply nested starmap calls In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1334508463.42.0.863490989266.issue14507@psf.upfronthosting.co.za> Raymond Hettinger added the comment: [Kristj?n] > a = map(add, a, b) also crashes this. > ... What's happening here is just simple c recursion > trough function pointers, ending in stack overflow, ... Thanks for the analysis. ISTM, this bug report is getting less and less interesting (or at least, less actionable without heavy-handed interventions in multiple tools). One other thought, the OPs isn't really recursive in the sense of a function calling itself repeatedly. Instead, the OPs explicitly creates a heavily nested pile of distinct iterator objects and then runs the entire chain. This isn't much different from someone writing: os.system('cat somefile | ' + ' | '.join(['sort']*100000)). The existing sys.max_recursion_depth was put in as a defense against the relatively common mistake of users writing a recursive function and getting the termination code wrong. I don't think that logic would apply to intentionally deeply nested data structures or iterators. Stackoverflows in C are hard to protect against. We could take every iterator and set some limits on it, but that would be heavy handed and likely do more harm than good (C iterators have been around almost a decade and haven't done fine in the wild. The itertools in particular were designed to gain speed through by-passing the eval-loop. Slowing them down would be counter to their primary use case.) ---------- resolution: -> later _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 19:07:51 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Apr 2012 17:07:51 +0000 Subject: [issue14507] Segfault with deeply nested starmap calls In-Reply-To: <1334508463.42.0.863490989266.issue14507@psf.upfronthosting.co.za> Message-ID: <1334509616.3414.6.camel@localhost.localdomain> Antoine Pitrou added the comment: > The existing sys.max_recursion_depth was put in as a defense against > the relatively common mistake of users writing a recursive function > and getting the termination code wrong. I don't think that logic > would apply to intentionally deeply nested data structures or > iterators. Well, we have a history of trying to fix crashers, even when they only occur in weird cases. > Stackoverflows in C are hard to protect against. We could simply re-use the existing infrastructure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 19:43:25 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Apr 2012 17:43:25 +0000 Subject: =?utf-8?q?=5Bissue14587=5D_Certain_diacritical_marks_can_and_should_be_ca?= =?utf-8?b?cGl0YWxpemVkLi4uIGUuZy4gw7wgLS0+IMOc?= In-Reply-To: <1334499448.33.0.168656695712.issue14587@psf.upfronthosting.co.za> Message-ID: <1334511805.48.0.415569882837.issue14587@psf.upfronthosting.co.za> STINNER Victor added the comment: Or you can port your program to Python 3 to avoid such issues :-) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 19:52:23 2012 From: report at bugs.python.org (sbt) Date: Sun, 15 Apr 2012 17:52:23 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: <1334512343.59.0.517564113703.issue11750@psf.upfronthosting.co.za> sbt added the comment: > I think the module would be better named _win32, since that's the name > of the API (like POSIX under Unix). Changed in new patch. > Also, it seems there are a couple of naming inconsistencies renaming > (e.g. the overlapped wrapper is named "_multiprocessing.win32.Overlapped") I've fixed that one (and changed the initial comment at the beginning of _win32.c), but I can't see any other. I also removed a duplicate of getulong(). ---------- Added file: http://bugs.python.org/file25224/win32_module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 20:02:19 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 15 Apr 2012 18:02:19 +0000 Subject: =?utf-8?q?=5Bissue14587=5D_Certain_diacritical_marks_can_and_should_be_ca?= =?utf-8?b?cGl0YWxpemVkLi4uIGUuZy4gw7wgLS0+IMOc?= In-Reply-To: <1334499448.33.0.168656695712.issue14587@psf.upfronthosting.co.za> Message-ID: <1334512939.18.0.93904788076.issue14587@psf.upfronthosting.co.za> R. David Murray added the comment: Indeed, this type of confusion is a large part of the motivation behind Python3. You might try posting to the python-list mailing list asking for help if for some reason you are required to use python2 for your program. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 20:18:36 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 15 Apr 2012 18:18:36 +0000 Subject: [issue14585] Have test_import run more importlib tests In-Reply-To: <1334453245.9.0.0799360762368.issue14585@psf.upfronthosting.co.za> Message-ID: <1334513916.94.0.0225007116742.issue14585@psf.upfronthosting.co.za> Brett Cannon added the comment: This also means that the importlib.test.import_.util.importlib_only decorators are probably all useless. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 20:23:24 2012 From: report at bugs.python.org (Roger Serwy) Date: Sun, 15 Apr 2012 18:23:24 +0000 Subject: [issue8900] IDLE crashes if Preference set to At Startup -> Open Edit Window In-Reply-To: <1275695898.02.0.763223364629.issue8900@psf.upfronthosting.co.za> Message-ID: <1334514204.61.0.680156904118.issue8900@psf.upfronthosting.co.za> Roger Serwy added the comment: Implicit relative imports are not related to this issue. Can someone please review the given patch? ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 20:26:38 2012 From: report at bugs.python.org (Brian Curtin) Date: Sun, 15 Apr 2012 18:26:38 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1334499205.3414.2.camel@localhost.localdomain> Message-ID: Brian Curtin added the comment: pythoncore.vcproj) > > * no changes to pcbuild.sln needed > > * removed reference to 'win32_functions.c' in setup.py > > I think the module would be better named _win32, since that's the name > of the API (like POSIX under Unix). While there are many references to it being called Win32 API around the web, at some point it became the Windows API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 20:32:57 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 15 Apr 2012 18:32:57 +0000 Subject: [issue14507] Segfault with deeply nested starmap calls In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1334514777.54.0.244052029761.issue14507@psf.upfronthosting.co.za> Terry J. Reedy added the comment: [Raymond: I presume you meant that C iterators have not been a problem in the wild and have done fine.] The RuntimeError message "maximum recursion depth exceeded" is not exactly correct. As Kristj?n implied in his first message, what has been reached is the maximum call stack or nested call depth. It happens to be that recursive calls are the easiest way to do that, but Python makes it somewhat easy to dynamically generate thousands of different callables making thousands of non-recursive nested calls. (A static expression with even 100 nested calls fails compilation with a MemoryError (3.2.3).) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 20:48:13 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 15 Apr 2012 18:48:13 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1331932171.45.0.56771909125.issue14339@psf.upfronthosting.co.za> Message-ID: <1334515693.42.0.543675526996.issue14339@psf.upfronthosting.co.za> Mark Dickinson added the comment: A few comments: (1) The patch appears to assume that a Unicode string created with PyUnicode_New(size, 127) will have 'kind' PyUnicode_1BYTE_KIND. While this might be true in the current implementation, I don't know whether this is guaranteed in general. Martin, any comments on this? (2) The patch doesn't compile with '--with-pydebug': there's a reference to the (now) undefined variable 'buffer' in one of the asserts. (3) The overflow check looks as though it needs to be reworked. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 20:48:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Apr 2012 18:48:20 +0000 Subject: [issue14507] Segfault with deeply nested starmap calls In-Reply-To: <1334514777.54.0.244052029761.issue14507@psf.upfronthosting.co.za> Message-ID: <1334515645.3414.7.camel@localhost.localdomain> Antoine Pitrou added the comment: > It happens to be that recursive calls are the easiest way to do that, > but Python makes it somewhat easy to dynamically generate thousands of > different callables making thousands of non-recursive nested calls. That's a rather pointless discussion of terminology, IMHO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 20:52:38 2012 From: report at bugs.python.org (Daniel Harding) Date: Sun, 15 Apr 2012 18:52:38 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1334515958.23.0.624261982877.issue9949@psf.upfronthosting.co.za> Daniel Harding added the comment: I have attached a series of patches with (hopefully) provide more robust fix for this issue, against the Python 3.3 branch. It handles both bytes and str objects, paths that do not actually exist on the filesystem, and removal of the '\\?\' prefix returned by _getfinalpathname, unless the supplied path had that prefix already. A couple of the patches contain some separate infrastructure that could hopefully be used to simplify some of the other Windows code in posixmodule.c (One immediate possibility would be to combine the code provided in these patches with the symbolic-link resolution code in the Windows stat functions - there is quite a bit of duplication there that could be eliminated.) One thing these patches do not address is resolving a broken symbolic link. The Windows API function GetFinalPathNameByHandle does not handle this case (because CreateFile cannot be used to get a handle if the symbolic link is broken). This functionality could be implemented by manually following the reparse points, but that would basically require reimplementing GetFinalPathNameByHandle. Finally, this patch could be fairly easily backported to Python 3.2, but that shouldn't be done without careful consideration. It changes the return value from os.path.realpath on Windows even when there are no symbolic links in the path (the returned value will have the actual casing as stored on the filesystem, instead of the casing supplied by the user). I don't think it should be backported to Python 2.7, because that version, like all Python versions before Python 3.2 are unaware of symbolic links on Windows (e.g. lexists is the same function as exists). The patches were generated using git (I use git-hg) - if that format is a problem, let me know and I can regenerate them. ---------- nosy: +dharding Added file: http://bugs.python.org/file25225/issue9949.tar.bz2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 20:55:51 2012 From: report at bugs.python.org (Roger Serwy) Date: Sun, 15 Apr 2012 18:55:51 +0000 Subject: [issue12387] IDLE save keyboard shortcut problem In-Reply-To: <1308765598.77.0.79184481064.issue12387@psf.upfronthosting.co.za> Message-ID: <1334516151.19.0.952488727435.issue12387@psf.upfronthosting.co.za> Roger Serwy added the comment: Attached is a patch to fix the caps-lock issue with Windows key bindings in config-keys.def. ---------- keywords: +patch Added file: http://bugs.python.org/file25226/windows_caps_lock.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 20:56:27 2012 From: report at bugs.python.org (Roger Serwy) Date: Sun, 15 Apr 2012 18:56:27 +0000 Subject: [issue12387] IDLE save keyboard shortcut problem In-Reply-To: <1308765598.77.0.79184481064.issue12387@psf.upfronthosting.co.za> Message-ID: <1334516187.47.0.872729465298.issue12387@psf.upfronthosting.co.za> Changes by Roger Serwy : ---------- stage: -> patch review versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 20:56:51 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 15 Apr 2012 18:56:51 +0000 Subject: [issue9303] Migrate sqlite3 module to _v2 API to enhance performance In-Reply-To: <1279541286.68.0.824716490463.issue9303@psf.upfronthosting.co.za> Message-ID: <1334516211.49.0.673510858449.issue9303@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 20:59:20 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 15 Apr 2012 18:59:20 +0000 Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za> Message-ID: <1334516360.6.0.297641354115.issue4130@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: I suggest to not apply additional patches for Modules/_ctypes/libffi* due to issue #12081. Patches for libffi should be sent to libffi upstream. ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 21:25:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 15 Apr 2012 19:25:26 +0000 Subject: [issue14582] Have importlib use return value from a loader's load_module() In-Reply-To: <1334435501.08.0.930274319662.issue14582@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 005fd1fe31ab by Brett Cannon in branch 'default': Issue #14582: Import returns the module returned by a loader instead http://hg.python.org/cpython/rev/005fd1fe31ab ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 21:25:29 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 15 Apr 2012 19:25:29 +0000 Subject: [issue14507] Segfault with deeply nested starmap calls In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1334517929.33.0.228324523239.issue14507@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: On the other hand, Antoine is correct in that we _could_ use the existing infrastructure and count PyIter_Next() as a recursion in the same way as entering the ceval loop is a recursion. Extra checking in there would hardly slow down the execution much. (but it would have to do its job only when invoking a "c" implemented iternext routine...) I tried to come up with other ways that we could create deeply nested C function calls... Here's one: ... a = (a, a) b = (b, b) a < b This however gets caught by this code: if (Py_EnterRecursiveCall(" in comparison")) return NULL; res = do_richcompare(v, w, op); Py_LeaveRecursiveCall(); So obviously someone thought this could be an issue. However: ... a = {1: a} repr(a) will generate the same crash. (tuple repr and list repr have guards, dict repr not) So, there are various ways to get c recursion to overflow the C stack. Some of them have been patched throughout the years, others not. We could try to identify all the different ways. We could for example add guards in PyObject_Repr() rather than individual types. But I'm sure we will leave holes in place like the OP discovered with deeply nested iterators. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 21:25:55 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 15 Apr 2012 19:25:55 +0000 Subject: [issue14582] Have importlib use return value from a loader's load_module() In-Reply-To: <1334435501.08.0.930274319662.issue14582@psf.upfronthosting.co.za> Message-ID: <1334517955.33.0.431849161379.issue14582@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 21:33:09 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 15 Apr 2012 19:33:09 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: <1334518389.35.0.984146408374.issue11750@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: >at some point it became the Windows API. You are right: http://en.wikipedia.org/wiki/Windows_API How about _windowsapi or _winapi then, to ensure there are no clashes? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 21:37:21 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 15 Apr 2012 19:37:21 +0000 Subject: [issue14507] Segfault with deeply nested starmap calls In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1334518641.15.0.3290661537.issue14507@psf.upfronthosting.co.za> Raymond Hettinger added the comment: ISTM this would do more harm than good. An introduce a new requirement for all iterators, introducing new arbitrary limits and slowing down all iterators (this is currently a simple, fast, light-weight protocol). Also this seems to be just a CPython issue (the JVM manages its own stack). Please don't muck-up the iterator protocol over this non-issue. It isn't worth it. If someone wants a stackless version of Python, they should use a stackless version of Python. There are other crashers we choose to ignore (involving gc.getreferrers, bytecode hacks, ctypes, etc). I think this should go in that category and I would be happy to add a note to that effect in the docs for itertools. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 21:41:04 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Apr 2012 19:41:04 +0000 Subject: [issue14507] Segfault with deeply nested starmap calls In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1334518864.77.0.343186128541.issue14507@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 21:45:35 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 15 Apr 2012 19:45:35 +0000 Subject: [issue14507] Segfault with deeply nested starmap calls In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1334519135.5.0.995956729292.issue14507@psf.upfronthosting.co.za> Mark Dickinson added the comment: > (A static expression with even 100 nested calls fails compilation with a > MemoryError (3.2.3).) I don't think that's at all related to this issue: that has to do with the fixed-size parser stack used when parsing Python code (see MAXSTACK in Parser/parser.h). Nothing to do with the C stack. :-) ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 21:47:23 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 15 Apr 2012 19:47:23 +0000 Subject: [issue14507] Segfault with deeply nested starmap calls In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za> Message-ID: <1334519243.04.0.145541792569.issue14507@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: > There are other crashers we choose to ignore (involving gc.getreferrers, > bytecode hacks, ctypes, etc). I think this should go in that category > and I would be happy to add a note to that effect in the docs for tertools. Yes, including my previous example with repr() a = None for i in range(100000): a = {1: a} repr(a) This is a case where care has been taken for lists, tuples, but not dicts. If we want to fix repr, the recursion checking shoudl probably go into PyObject_repr(). I'm not advocating for a fix, Just pointing out yet another way you can construct objects so that accessnig them will cause a crash. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 21:57:27 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 15 Apr 2012 19:57:27 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1334519847.55.0.00153269986068.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: Just because I was thinking about it, I wonder if necessarily all the frozen stuff really needs to stay in import.c. I mean a frozen module is really just an entry in an array of structs that has a name of an char*[]. I don't see why one couldn't simply have a get_frozen_bytes() method to convert that char*[] into a bytes object and use that to construct a module in pure Python code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 22:05:29 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 15 Apr 2012 20:05:29 +0000 Subject: [issue8900] IDLE crashes if Preference set to At Startup -> Open Edit Window In-Reply-To: <1275695898.02.0.763223364629.issue8900@psf.upfronthosting.co.za> Message-ID: <1334520329.58.0.686961718195.issue8900@psf.upfronthosting.co.za> Terry J. Reedy added the comment: With 3.2.3, after selecting open edit on startup and using ^O to select a file, I got a silent close of the editor window. Opening from the file menu worked. After the change of adding '0', ^O worked also. However, without a test suite, I am a little nervous about the change, as the original code might be intentional. From the module doc string: "The order by which events are called is defined by these rules: 1. A more-specific event will be called before a less-specific event. 2. A recently-binded event will be called before a previously-binded event, unless this conflicts with the first rule." Is popping from the end the implementation of rule 2? Is it possible that one event pair is being appended in the wrong order? I need to read more of the comments and code to understand this subsystem. Code note 1: doafterhandler = self.doafterhandler (initially [] by default), so changes to the list must be mutations to affect the self attribute. while doafterhandler: doafterhandler.pop(0)() # is O(n*2) doafterhandler.reverse() while doafterhandler: doafterhandler.pop()() # is O(n) for f in doafterhandler: f() doafterhandler[:] = [] # doafterhandler.clear() works in 3.3 # is also O(n) and replaces repeated .pop with one clear If calling first to last is proper, I prefer this last unless the callback functions somehow require that they be removed from doafterhandler before being called. Code note 2: unless the default args for handler def __create_handler(self, lists, mc_type, mc_state): def handler(event, lists = lists, mc_type = mc_type, mc_state = mc_state, ishandlerrunning = self.ishandlerrunning, doafterhandler = self.doafterhandler): are ever replaced with other arguments in handler(event) calls, their presence in the signature would appear to be holdovers from before closures. If so, the above could be simplified to def handler(event) and 'self.' added in the body where needed. I also wonder whether the double underscore and consequent name mangling for __create_handler is needed. My understanding is that this is only needed, perhaps, for multiple inheritance mixin classes, and I do not see that class _ComplexBinder qualifies. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 22:09:12 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 15 Apr 2012 20:09:12 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset d777f854a66e by Brett Cannon in branch 'default': Issue #13959: Rename imp to _imp and add Lib/imp.py and begin http://hg.python.org/cpython/rev/d777f854a66e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 22:12:38 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 15 Apr 2012 20:12:38 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1334520758.36.0.85145758838.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, so I have started to check this stuff in, but I think it's best to do it piecemeal. Going forward I would like to commit in units of functions being replaced, and prioritize stuff that cuts out C code (e.g. the load_*() methods, find_module(), etc.). That way it's clear that progress is being made. Obviously the best way to tell if code is hanging on just because of imp is to comment out the interface code and see what your compiler complains about in terms of dead code (or at least clang is good at this). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 22:32:12 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 15 Apr 2012 20:32:12 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1334515693.42.0.543675526996.issue14339@psf.upfronthosting.co.za> Message-ID: <1334522074.17945.71.camel@raxxla> Serhiy Storchaka added the comment: > (1) The patch appears to assume that a Unicode string created with PyUnicode_New(size, 127) will have 'kind' PyUnicode_1BYTE_KIND. While this might be true in the current implementation, I don't know whether this is guaranteed in general. Martin, any comments on this? The same assumption is used above in long_to_decimal_string(). I added the same assert and changed maxchar to 'f'. > (2) The patch doesn't compile with '--with-pydebug': there's a reference to the (now) undefined variable 'buffer' in one of the asserts. Fixed. > (3) The overflow check looks as though it needs to be reworked. I was left an old constraint (it is enough), but it really can be weakened (in fact, it can be so weakened in the current code). Thank you for the comments and the found error. ---------- Added file: http://bugs.python.org/file25227/long_to_binary_base_2.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 13307eb5bf47 Objects/longobject.c --- a/Objects/longobject.c Sat Apr 14 14:20:29 2012 -0500 +++ b/Objects/longobject.c Sun Apr 15 23:29:34 2012 +0300 @@ -1672,11 +1672,10 @@ { register PyLongObject *a = (PyLongObject *)aa; PyObject *v; - Py_ssize_t i, sz; + Py_ssize_t sz; Py_ssize_t size_a; - char *p; - char sign = '\0'; - char *buffer; + Py_UCS1 *p; + int negative; int bits; assert(base == 2 || base == 8 || base == 10 || base == 16); @@ -1688,6 +1687,7 @@ return NULL; } size_a = ABS(Py_SIZE(a)); + negative = Py_SIZE(a) < 0; /* Compute a rough upper bound for the length of the string */ switch (base) { @@ -1706,31 +1706,37 @@ } /* compute length of output string: allow 2 characters for prefix and 1 for possible '-' sign. */ - if (size_a > (PY_SSIZE_T_MAX - 3) / PyLong_SHIFT / sizeof(Py_UCS4)) { + if (size_a > (PY_SSIZE_T_MAX - 3) / PyLong_SHIFT) { PyErr_SetString(PyExc_OverflowError, "int is too large to format"); return NULL; } /* now size_a * PyLong_SHIFT + 3 <= PY_SSIZE_T_MAX, so the RHS below is safe from overflow */ - sz = 3 + (size_a * PyLong_SHIFT + (bits - 1)) / bits; - assert(sz >= 0); - buffer = PyMem_Malloc(sz); - if (buffer == NULL) { + if (size_a == 0) { + sz = 3; + } + else { + sz = 2 + negative + ((size_a - 1) * PyLong_SHIFT + + bits_in_digit(a->ob_digit[size_a - 1]) + + (bits - 1)) / bits; + } + v = PyUnicode_New(sz, 'f'); + if (v == NULL) { PyErr_NoMemory(); return NULL; } - p = &buffer[sz]; - if (Py_SIZE(a) < 0) - sign = '-'; - - if (Py_SIZE(a) == 0) { + assert(PyUnicode_KIND(v) == PyUnicode_1BYTE_KIND); + p = PyUnicode_1BYTE_DATA(v) + sz; + + if (size_a == 0) { *--p = '0'; } else { /* JRH: special case for power-of-2 bases */ twodigits accum = 0; int accumbits = 0; /* # of bits in accum */ + Py_ssize_t i; for (i = 0; i < size_a; ++i) { accum |= (twodigits)a->ob_digit[i] << accumbits; accumbits += PyLong_SHIFT; @@ -1739,7 +1745,7 @@ char cdigit; cdigit = (char)(accum & (base - 1)); cdigit += (cdigit < 10) ? '0' : 'a'-10; - assert(p > buffer); + assert(p > PyUnicode_1BYTE_DATA(v)); *--p = cdigit; accumbits -= bits; accum >>= bits; @@ -1747,6 +1753,7 @@ } } + assert(p == PyUnicode_1BYTE_DATA(v) + 2 + negative); if (base == 16) *--p = 'x'; else if (base == 8) @@ -1754,10 +1761,8 @@ else /* (base == 2) */ *--p = 'b'; *--p = '0'; - if (sign) - *--p = sign; - v = PyUnicode_DecodeASCII(p, &buffer[sz] - p, NULL); - PyMem_Free(buffer); + if (negative) + *--p = '-'; return v; } From report at bugs.python.org Sun Apr 15 22:42:23 2012 From: report at bugs.python.org (clikkeb) Date: Sun, 15 Apr 2012 20:42:23 +0000 Subject: [issue14576] IDLE cannot connect to subprocess - New solution In-Reply-To: <1334400065.92.0.605072928338.issue14576@psf.upfronthosting.co.za> Message-ID: <1334522543.2.0.558118494262.issue14576@psf.upfronthosting.co.za> clikkeb added the comment: Thanks for your answer. Trying to understand how IDLE uses HOMEPATH and USERPROFILE Windows variables, I have found the following information: 1) it seems that when executed via Windows command prompt (cmd.exe), os.path.expanduser refers to USERPROFILE to determine the user's home directory; 2) analizing the stack traces of the first calls to IdleConf.GetUserCfgDir, you can see that GetUserCfgDir (which calls expanduser) is called three times during IDLE startup: the first two times it refers to USERPROFILE, the third (called via run.py, probably after starting a subprocess) it refers to the combination of HOMEDRIVE and HOMEPATH. (???) 3) when you start IDLE using pythonw, sys.stderr.write(warn) seems to raise an AttributeError exception, which is unhandled. This causes IDLE to stop running when you either start IDLE that way and the user's home directory is unreachable. Due to the Python's tricky behaviour in determining the Windows user's home directory, my opinion would be to consider if it is worth to go further with this discussion or if it could produce a benefit to IDLE. For sure, it gave me a little bit of headache. clikkeb. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 22:59:05 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 15 Apr 2012 20:59:05 +0000 Subject: [issue12387] IDLE save keyboard shortcut problem In-Reply-To: <1308765598.77.0.79184481064.issue12387@psf.upfronthosting.co.za> Message-ID: <1334523545.75.0.0322720789139.issue12387@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Changes look complete and correct as far as I can tell, except that I have some confusion about the relation of Shift and CapsLock key. For instance, Control-C and Control-Shift-C (using the key labels) both interrupt a loop whether or not CapsLock is on. In all, 4 combinations work even though only 2 are listed. interrupt-execution= However, this pair of specifications +save-window-as-file= +save-window= only makes sense to me if 's' and 'S' refer to the 'S' key without and with CapLock on as using Shift is meant to give a different meaning. It appears to split the 4 combinations into 2 pairs that do different things. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 23:22:39 2012 From: report at bugs.python.org (Roger Serwy) Date: Sun, 15 Apr 2012 21:22:39 +0000 Subject: [issue8900] IDLE crashes if Preference set to At Startup -> Open Edit Window In-Reply-To: <1275695898.02.0.763223364629.issue8900@psf.upfronthosting.co.za> Message-ID: <1334524959.26.0.82967370313.issue8900@psf.upfronthosting.co.za> Roger Serwy added the comment: Thanks for your review, Terry. Popping from the end is not an implementation of rule 2. Calling event handlers is separate concept from binding/unbinding event handlers. The "doafterhandler" list contains bind/unbind requests that were made while calling event handlers. The doafterhandler "queue" should be FIFO, not LIFO. Code note 1: The running time of the algorithm is an important consideration. Your last suggestion for using a for-loop looks most appropriate, as you've said. Attached is a revised patch for it. Code note 2: The _ComplexBinder class may need refactoring, but that's a separate issue. I'm willing to review patches for that. ---------- Added file: http://bugs.python.org/file25228/issue8900_rev1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 23:52:19 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 15 Apr 2012 21:52:19 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1334526739.15.0.52727892702.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: It looks like in order to get a clear sign of what it will take to remove various parts of import.c, imp.load_module() needs to go along with imp.load_package() (since they call each other in the C code). You also have to take care of imp.reload(), but I am simplifying the C code greatly and will take care of referencing other code in the module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 23:56:19 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 15 Apr 2012 21:56:19 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 4dce3afc392c by Brett Cannon in branch 'default': Issue #13959: Simplify imp.reload() by relying on a module's http://hg.python.org/cpython/rev/4dce3afc392c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 23:58:07 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Apr 2012 21:58:07 +0000 Subject: [issue14579] Possible vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1334527087.49.0.613540478042.issue14579@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 15 23:59:23 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Apr 2012 21:59:23 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1334527163.08.0.0895125419195.issue14304@psf.upfronthosting.co.za> STINNER Victor added the comment: What is this codec? What do you mean by "escpe non-ascii"? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 00:11:23 2012 From: report at bugs.python.org (Meador Inge) Date: Sun, 15 Apr 2012 22:11:23 +0000 Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za> Message-ID: <1334527883.93.0.217671855721.issue4130@psf.upfronthosting.co.za> Meador Inge added the comment: > I suggest to not apply additional patches for Modules/_ctypes/libffi* > due to issue #12081. Patches for libffi should be sent to libffi > upstream. For trunk I agree. However, it is probably worth considering this patch for 2.7 and 3.2. Did anyone check to see if this is already fixed in upstream libffi? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 00:17:05 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 15 Apr 2012 22:17:05 +0000 Subject: [issue14386] Expose dict_proxy internal type as types.MappingProxyType In-Reply-To: <1332381004.13.0.167648412562.issue14386@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset c3a0197256ee by Victor Stinner in branch 'default': Issue #14386: Expose the dict_proxy internal type as types.MappingProxyType http://hg.python.org/cpython/rev/c3a0197256ee ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 00:21:28 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Apr 2012 22:21:28 +0000 Subject: [issue14386] Expose dict_proxy internal type as types.MappingProxyType In-Reply-To: <1332381004.13.0.167648412562.issue14386@psf.upfronthosting.co.za> Message-ID: <1334528488.86.0.814580406103.issue14386@psf.upfronthosting.co.za> STINNER Victor added the comment: > Summary: The collections.abc module is fine as-is. Ok, but there is still an issue: issubclass(types.MappingProxyType, collections.abc.Mapping) is False. Attached registers MappingProxyType as a Mapping. Is it correct? The patch also renames dict_proxy to mappingproxy. Is it backward incompatible? (collections.abc module was added to Python 3.3) ---------- Added file: http://bugs.python.org/file25229/mappingproxy_abc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 00:31:10 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 15 Apr 2012 22:31:10 +0000 Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za> Message-ID: <1334529070.27.0.621609757006.issue4130@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: https://github.com/atgreen/libffi/blob/master/src/x86/ffi64.c contains: #ifdef __INTEL_COMPILER #define UINT128 __m128 #else #define UINT128 __int128_t #endif ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 00:31:17 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Apr 2012 22:31:17 +0000 Subject: [issue14385] Support other types than dict for __builtins__ In-Reply-To: <1332380135.46.0.264363154256.issue14385@psf.upfronthosting.co.za> Message-ID: <1334529077.79.0.429026024266.issue14385@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file24989/builtins.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 00:34:59 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 15 Apr 2012 22:34:59 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1334529299.33.0.13189489318.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: I am seeing how this is going to go down. the load_dynamic, load_source, etc. family of functions are simply dispatched to by load_module(). So to keep some semblance of backwards-compatibility, each of those modules need to be implemented and then have load_module() simply dispatch to them based on the "type" of module it is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 00:47:31 2012 From: report at bugs.python.org (Alex Leach) Date: Sun, 15 Apr 2012 22:47:31 +0000 Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za> Message-ID: <1334530051.46.0.807993524662.issue4130@psf.upfronthosting.co.za> Alex Leach added the comment: Submitting a working patch upstream would make sense.. Just found, downloaded and tried compiling libffi-3.0.11. The developers have made some changes towards a solution, but compilation fails with the same error:- libtool: compile: icc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -DFFI_BUILDING -g -O3 -ansi_alias -Wall -fexceptions -MT src/x86/ffi64.lo -MD -MP -MF src/x86/.deps/ffi64.Tpo -c ../src/x86/ffi64.c -fPIC -DPIC -o src/x86/.libs/ffi64.o ../src/x86/ffi64.c(50): error: identifier "__m128" is undefined UINT128 sse[MAX_SSE_REGS]; __m128 is defined in Intel's xmmintrin.h though [http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/cpp/lin/compiler_c/intref_cls/common/intref_sse_arithmetic.htm]. So I added the necessary include line, which gets a different error:- libtool: compile: icc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -DFFI_BUILDING -g -O3 -ansi_alias -Wall -fexceptions -MT src/x86/ffi64.lo -MD -MP -MF src/x86/.deps/ffi64.Tpo -c ../src/x86/ffi64.c -fPIC -DPIC -o src/x86/.libs/ffi64.o ../src/x86/ffi64.c(481): error: a value of type "UINT64={unsigned long}" cannot be assigned to an entity of type "__m128" reg_args->sse[ssecount++] = *(UINT64 *) a; ^ ../src/x86/ffi64.c(484): error: a value of type "UINT32={unsigned int}" cannot be assigned to an entity of type "__m128" reg_args->sse[ssecount++] = *(UINT32 *) a; ^ Regarding my previous patch, I'm not convinced it works actually.. It compiles, and passes the default Python tests, but I get some dodgy behaviour. e.g. when compiling 2.7.3 with --enable-shared, I get a segfault when compiling the gdbm module against libdb4.8-dev. Any specific ways of testing the build? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 01:49:25 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Apr 2012 23:49:25 +0000 Subject: [issue14385] Support other types than dict for __builtins__ In-Reply-To: <1332380135.46.0.264363154256.issue14385@psf.upfronthosting.co.za> Message-ID: <1334533765.39.0.473993347276.issue14385@psf.upfronthosting.co.za> STINNER Victor added the comment: Oops, patch version 2 was not correct: I forgot a { ... } in ceval.c. New patch fixing this issue but leaves also the LOAD_GLOBAL code unchanged : keep the goto and don't try to factorize the 3 last instructions. LOAD_GLOBAL is really critical in performance. With patch version 3, the overall overhead is +0.4% according to pybench. ---------- Added file: http://bugs.python.org/file25230/builtins-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 01:49:45 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Apr 2012 23:49:45 +0000 Subject: [issue14385] Support other types than dict for __builtins__ In-Reply-To: <1332380135.46.0.264363154256.issue14385@psf.upfronthosting.co.za> Message-ID: <1334533785.43.0.619493974479.issue14385@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25132/builtins-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 01:52:40 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 15 Apr 2012 23:52:40 +0000 Subject: [issue1508475] transparent gzip compression in urllib In-Reply-To: <1334483492.4.0.124242355754.issue1508475@psf.upfronthosting.co.za> Message-ID: <20120415235233.GA4217@mathmagic> Senthil Kumaran added the comment: In that case, transparent decompression should not be available. ( Request header should not be sent and response wont be compressed). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 01:53:11 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 15 Apr 2012 23:53:11 +0000 Subject: [issue14385] Support other types than dict for __builtins__ In-Reply-To: <1332380135.46.0.264363154256.issue14385@psf.upfronthosting.co.za> Message-ID: <1334533991.1.0.447255948616.issue14385@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 02:11:32 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 16 Apr 2012 00:11:32 +0000 Subject: [issue9403] cElementTree: replace PyObject_DEL() by Py_DECREF() to fix a crash in pydebug mode In-Reply-To: <1280350705.3.0.213499722891.issue9403@psf.upfronthosting.co.za> Message-ID: <1334535092.1.0.817522231381.issue9403@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 02:19:53 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 16 Apr 2012 00:19:53 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1334535593.81.0.0575962885584.issue13072@psf.upfronthosting.co.za> STINNER Victor added the comment: @Stefan: What is the status of this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 02:23:19 2012 From: report at bugs.python.org (Daniel Urban) Date: Mon, 16 Apr 2012 00:23:19 +0000 Subject: [issue14588] PEP 3115 compliant dynamic class creation Message-ID: <1334535798.87.0.826104374353.issue14588@psf.upfronthosting.co.za> New submission from Daniel Urban : As Nick Coghlan proposed [1, 2], there should be a way to dynamically create classes, which handles metaclasses correctly (see also issue1294232). Here is my first attempt at creating an operator.build_class method. It only includes very simple tests and no documentation, but I will write them if needed. With this patch there are two functions for creating a class object: 1. __build_class__ (no change) 2. operator.build_class(name, bases=(), kwds=None, eval_body=None): finds the correct metaclass and calls its __prepare__. If eval_body is given, calls it with the namespace returned by __prepare__. Then calls the correct metaclass, and returns the created class object. Both of these functions (after parsing their arguments) call _PyType_BuildClass, a new C API function. The first argument of this function is a callable, that will be called with the namespace returned by __prepare__ (it also can be NULL, in that case nothing will be called). __build_class__ passes the function that is the body of the class statement. operator.build_class passes the callable given by the user (or NULL, if the user didn't pass the eval_body argument). The implementation of _PyType_BuildClass is approximately the following: def _PyType_BuildClass(func=None, name, bases, kwds={}): meta = kwds.pop('metaclass', None) if meta is None: if not bases: meta = type else: meta = type(bases[0]) ns, meta = prepare_namespace(name, meta, bases, kwds) if func is not None: func(ns) return meta(name, bases, ns, kwds) (Actually the return value of the func is used if it's a cell object. I'm not sure, why and when this is needed, this code comes from __build_class__.) The changes are in the following files: 1. object.h: the exported function is _PyType_BuildClass instead of _PyType_CalculateMetaclass (that doesn't need to be in the include file anymore). 2. operator.c: the build_class method checks its arguments, then calls _PyType_BuildClass. 3. typeobject.c: _PyType_CalculateMetaclass is renamed to calculate_metaclass, because now it is only called from this file. prepare_namespace calls calculate_metaclass to determine the correct metaclass, then calls its __prepare__ method. (This code is moved here mostly from __build_class__). It also passes back the correct metaclass to its caller. _PyType_BuildClass gets the starting metaclass from its arguments. Then it calls prepare_namespace to get the namespace and the correct metaclass. If it received a non-NULL first argument (the function that is the class body or the eval_body argument of operator.build_class), then calls it, passing the namespace. Then it calls the correct metaclass. (Most of this code is also from __build_class__.) 4. bltinmodule.c: builtin___build_class__ now only parses its arguments, and simply calls _PyType_BuildClass. 5. test_operator.py: a simple test for operator.build_class [1] http://mail.python.org/pipermail/python-dev/2011-April/110874.html [2] http://mail.python.org/pipermail/python-dev/2012-April/118732.html ---------- components: Extension Modules, Interpreter Core files: operator_build_class.patch keywords: patch messages: 158382 nosy: durban, ncoghlan priority: normal severity: normal status: open title: PEP 3115 compliant dynamic class creation type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25231/operator_build_class.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 02:25:30 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Apr 2012 00:25:30 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2df37938b8e1 by Brett Cannon in branch 'default': Issue #13959: Re-implement imp.load_module() in imp.py. http://hg.python.org/cpython/rev/2df37938b8e1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 02:31:57 2012 From: report at bugs.python.org (Joseph) Date: Mon, 16 Apr 2012 00:31:57 +0000 Subject: [issue8820] IDLE not launching correctly In-Reply-To: <1334441325.76.0.397281044886.issue8820@psf.upfronthosting.co.za> Message-ID: Joseph added the comment: Seems to work fine for me, operating system still Windows 64 bit, Python 2.7.2, IDLE 2.7.2 On Sat, Apr 14, 2012 at 6:08 PM, Roger Serwy wrote: > > Roger Serwy added the comment: > > Joseph, Jeff, > > Is this still a valid issue with the latest release of IDLE? > > ---------- > status: open -> pending > type: -> behavior > > _______________________________________ > Python tracker > > _______________________________________ > ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 02:42:53 2012 From: report at bugs.python.org (Roger Serwy) Date: Mon, 16 Apr 2012 00:42:53 +0000 Subject: [issue8820] IDLE not launching correctly In-Reply-To: <1274842084.45.0.257196773636.issue8820@psf.upfronthosting.co.za> Message-ID: <1334536973.18.0.341351743168.issue8820@psf.upfronthosting.co.za> Roger Serwy added the comment: Thank you for your feedback. I will close this issue since it is now out of date. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 02:46:40 2012 From: report at bugs.python.org (Roger Serwy) Date: Mon, 16 Apr 2012 00:46:40 +0000 Subject: [issue10722] IDLE's subprocess didnit make connection ..... Python 2.7 In-Reply-To: <1292541211.42.0.50542503549.issue10722@psf.upfronthosting.co.za> Message-ID: <1334537200.22.0.531591351621.issue10722@psf.upfronthosting.co.za> Changes by Roger Serwy : ---------- nosy: +serwy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 02:49:51 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 16 Apr 2012 00:49:51 +0000 Subject: [issue14589] test_algorithms() of test_ssl fails: certificate of sha256.tbs-internet.com changed Message-ID: <1334537391.58.0.830155937634.issue14589@psf.upfronthosting.co.za> New submission from STINNER Victor : http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/3677/steps/test/logs/stdio ====================================================================== ERROR: test_algorithms (test.test_ssl.NetworkedTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_ssl.py", line 841, in test_algorithms s.connect(remote) File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/ssl.py", line 543, in connect self._real_connect(addr, False) File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/ssl.py", line 533, in _real_connect self.do_handshake() File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/ssl.py", line 513, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [Errno 1] _ssl.c:435: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed ---------------------------------------------------------------------- It looks like https://sha256.tbs-internet.com/ certificate changed: the serial number of the current certificate is 00:AA:55:98:78:20:F6:77:C2:A1:D0:15:C1:C3:F8:B2:2C. The serial number of Lib/test/sha256.pem is c9:9a:83:ec:a0:48:07:71:66:c6:f2:cd:88:e1:b9:6d (try "openssl x509 -in Lib/test/sha256.pem -text -noout" command). I don't know how to download the new certificate. ---------- messages: 158386 nosy: haypo, pitrou priority: normal severity: normal status: open title: test_algorithms() of test_ssl fails: certificate of sha256.tbs-internet.com changed versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 02:58:14 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 00:58:14 +0000 Subject: [issue14576] IDLE cannot connect to subprocess - New solution In-Reply-To: <1334400065.92.0.605072928338.issue14576@psf.upfronthosting.co.za> Message-ID: <1334537894.62.0.715867544264.issue14576@psf.upfronthosting.co.za> R. David Murray added the comment: It certainly is worthwhile pursing this in some fashion, since at the very least the existing error message needs to be improved. But perhaps there is something more that can be done to gracefully handle this case, instead. I think the next interesting question is to find out why an invalid home directory causes idle to not start up. There's no obvious reason why that should be the case in principle, so I suspect there's some error handling missing somewhere. This probably also applies to 2.7; someone should test that. ---------- nosy: +r.david.murray stage: -> needs patch type: -> behavior versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 03:07:06 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 01:07:06 +0000 Subject: [issue14586] TypeError: truncate() takes no keyword arguments In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za> Message-ID: <1334538426.22.0.3250724947.issue14586@psf.upfronthosting.co.za> R. David Murray added the comment: The suggested doc change won't work, since that would imply that the size argument was required. We'd have to use the old truncate([size]) notation. Supporting it as a keyword argument is probably to be preferred, but someone will have to write the patch :) ---------- nosy: +pitrou, r.david.murray stage: -> needs patch versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 03:08:39 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 16 Apr 2012 01:08:39 +0000 Subject: [issue10722] IDLE's subprocess didnit make connection ..... Python 2.7 In-Reply-To: <1292541211.42.0.50542503549.issue10722@psf.upfronthosting.co.za> Message-ID: <1334538519.53.0.229745636306.issue10722@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 3.2.3 and 2.7.3 are out. And I am running on win7 without problems. I have not tried running multiple shells of the same Python version, but I have occasionally run 2.7 and 3.2 simultaneously without problems that I noticed. Roger, does IDLE get any info at all from the subprocess failure that it could display? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 03:11:39 2012 From: report at bugs.python.org (Daniel Harding) Date: Mon, 16 Apr 2012 01:11:39 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1334538699.89.0.969032069014.issue9949@psf.upfronthosting.co.za> Daniel Harding added the comment: Uploading a new series of patches - they are all the same as the first set, except for 0006-Make-realpath-follow-symbolic-links-on-Windows.patch. I realized that I could use os.readlink to handle broken symbolic links, so I changed the logic of os.path.realpath slightly to do that (including recursive symlink detection). ---------- Added file: http://bugs.python.org/file25232/issue9949-v2.tar.bz2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 03:27:49 2012 From: report at bugs.python.org (Roger Serwy) Date: Mon, 16 Apr 2012 01:27:49 +0000 Subject: [issue10722] IDLE's subprocess didnit make connection ..... Python 2.7 In-Reply-To: <1292541211.42.0.50542503549.issue10722@psf.upfronthosting.co.za> Message-ID: <1334539669.92.0.917028663355.issue10722@psf.upfronthosting.co.za> Roger Serwy added the comment: The IDLE front-end doesn't receive anything about the subprocess failure mode. The "poll_subprocess" method in PyShell.py will restart the subprocess if the socket closes. (The "pollpacket" method in rpc.py raises an EOFError.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 03:38:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Apr 2012 01:38:37 +0000 Subject: [issue14589] test_algorithms() of test_ssl fails: certificate of sha256.tbs-internet.com changed In-Reply-To: <1334537391.58.0.830155937634.issue14589@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f323b37ef6c1 by Antoine Pitrou in branch '3.2': Issue #14589: Update certificate chain for sha256.tbs-internet.com, fixing a test failure in test_ssl. http://hg.python.org/cpython/rev/f323b37ef6c1 New changeset 34f09c654a5b by Antoine Pitrou in branch 'default': Issue #14589: Update certificate chain for sha256.tbs-internet.com, fixing a test failure in test_ssl. http://hg.python.org/cpython/rev/34f09c654a5b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 03:40:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Apr 2012 01:40:33 +0000 Subject: [issue14589] test_algorithms() of test_ssl fails: certificate of sha256.tbs-internet.com changed In-Reply-To: <1334537391.58.0.830155937634.issue14589@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 33bc53e0aa9e by Antoine Pitrou in branch '2.7': Issue #14589: Update certificate chain for sha256.tbs-internet.com, fixing a test failure in test_ssl. http://hg.python.org/cpython/rev/33bc53e0aa9e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 03:42:30 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Apr 2012 01:42:30 +0000 Subject: [issue14589] test_algorithms() of test_ssl fails: certificate of sha256.tbs-internet.com changed In-Reply-To: <1334537391.58.0.830155937634.issue14589@psf.upfronthosting.co.za> Message-ID: <1334540550.65.0.337246025019.issue14589@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Fixed! Note: to get the new certificate chain, I just did: $ openssl s_client -connect sha256.tbs-internet.com:443 -showcerts :) ---------- components: +Tests resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 03:42:46 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 01:42:46 +0000 Subject: [issue6657] Copy documentation section In-Reply-To: <1249557535.14.0.530083384684.issue6657@psf.upfronthosting.co.za> Message-ID: <1334540566.29.0.0784768640399.issue6657@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. 2.5 years later it isn't looking like we are going to get a response. Closing. ---------- nosy: +r.david.murray resolution: -> works for me stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 03:48:04 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 16 Apr 2012 01:48:04 +0000 Subject: [issue14589] test_algorithms() of test_ssl fails: certificate of sha256.tbs-internet.com changed In-Reply-To: <1334540550.65.0.337246025019.issue14589@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 03:57:48 2012 From: report at bugs.python.org (Graham Dumpleton) Date: Mon, 16 Apr 2012 01:57:48 +0000 Subject: [issue14590] ConfigParser doesn't strip inline comment when delimiter occurs earlier without preceding space. Message-ID: <1334541468.07.0.833607995836.issue14590@psf.upfronthosting.co.za> New submission from Graham Dumpleton : When parsing for inline comments, ConfigParser will only check the first occurrence of the delimiter in the line. If that instance of the delimiter isn't preceded with a space, it then assumes no comment. This ignores the fact that there could be a second instance of the delimiter which does have a preceding space. The result is that inline comments can be left as part of the value. So, a config file of: [section] value1 = a;b value2 = a ; comment value3 = a; b ; comment after parsing actually results in: [section] value1 = a;b value2 = a value3 = a; b ; comment That is, 'value3' is incorrect as still embeds the inline comment. Test script attached for Python 2.X. Not tested on Python 3.X but code appears to do the same thing, except that on Python 3.X inline comments are disabled by default. ---------- components: Library (Lib) files: test_config.py messages: 158397 nosy: grahamd priority: normal severity: normal status: open title: ConfigParser doesn't strip inline comment when delimiter occurs earlier without preceding space. type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25233/test_config.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 04:18:19 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 02:18:19 +0000 Subject: [issue14590] ConfigParser doesn't strip inline comment when delimiter occurs earlier without preceding space. In-Reply-To: <1334541468.07.0.833607995836.issue14590@psf.upfronthosting.co.za> Message-ID: <1334542699.35.0.774571884109.issue14590@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- assignee: -> lukasz.langa nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 04:18:39 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 02:18:39 +0000 Subject: [issue14590] ConfigParser doesn't strip inline comment when delimiter occurs earlier without preceding space. In-Reply-To: <1334541468.07.0.833607995836.issue14590@psf.upfronthosting.co.za> Message-ID: <1334542719.0.0.0746955098062.issue14590@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- versions: -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 04:29:00 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Apr 2012 02:29:00 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 4256df44023b by Brett Cannon in branch 'default': Issue #13959: Re-implement imp.load_package() in imp.py. http://hg.python.org/cpython/rev/4256df44023b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 07:10:32 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Apr 2012 05:10:32 +0000 Subject: [issue10854] Output .pyd name in error message of ImportError when DLL load fails In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f341b99bb370 by Brian Curtin in branch 'default': Fix #10854. Make use of the new path and name attributes on ImportError http://hg.python.org/cpython/rev/f341b99bb370 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 07:12:12 2012 From: report at bugs.python.org (Brian Curtin) Date: Mon, 16 Apr 2012 05:12:12 +0000 Subject: [issue10854] Output .pyd name in error message of ImportError when DLL load fails In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za> Message-ID: <1334553132.76.0.235208089317.issue10854@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 07:41:12 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Apr 2012 05:41:12 +0000 Subject: [issue1508475] transparent gzip compression in urllib Message-ID: <1334554872.74.0.404730863515.issue1508475@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch for py3k also has the disadvantage that the content is decoded even if the user has defined a Content-Encoding and he is going to process compressed response himself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 08:10:57 2012 From: report at bugs.python.org (Qiangning Hong) Date: Mon, 16 Apr 2012 06:10:57 +0000 Subject: [issue14562] urllib2 maybe blocks too long with small chunks In-Reply-To: <1334233390.52.0.591380103695.issue14562@psf.upfronthosting.co.za> Message-ID: <1334556657.92.0.162373989938.issue14562@psf.upfronthosting.co.za> Changes by Qiangning Hong : ---------- nosy: +hongqn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 08:41:37 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 16 Apr 2012 06:41:37 +0000 Subject: [issue14583] try/except import fails --without-threads In-Reply-To: <1334436331.01.0.461185960127.issue14583@psf.upfronthosting.co.za> Message-ID: <1334558497.61.0.401265919978.issue14583@psf.upfronthosting.co.za> Stefan Krah added the comment: The SystemError has changed to a KeyError: http://www.python.org/dev/buildbot/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/2004/steps/test/logs/stdio At least that makes it easy to spot the location in import.c. The shortest way to reproduce the error is to compile --without-threads, then: import multiprocessing import multiprocessing.process ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 09:14:12 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 16 Apr 2012 07:14:12 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1331932171.45.0.56771909125.issue14339@psf.upfronthosting.co.za> Message-ID: <1334560452.0.0.530315882187.issue14339@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks for the updates. > The same assumption is used above in long_to_decimal_string(). I added > the same assert and changed maxchar to 'f'. I think 'x' would be more appropriate. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 09:47:43 2012 From: report at bugs.python.org (Guy Taylor) Date: Mon, 16 Apr 2012 07:47:43 +0000 Subject: [issue14586] TypeError: truncate() takes no keyword arguments In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za> Message-ID: <1334562463.88.0.9542912452.issue14586@psf.upfronthosting.co.za> Guy Taylor added the comment: What ever change is made to the new CPythons the old docs should be updated to prevent confusion, with truncate([size]). On fixing it for the future I would agree that supporting it as a keyword argument is preferred, as it is more pythonic (in my opinion). However this would cause ether backwards incompatibility or ambiguity in the language (ie. truncate(0, size=1) or need the deprecate, warn then removal stages taken three release cycles). Maybe the less perfect but acceptable solution is just to change the docs and wait for Python 4k for the real fix....? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 10:30:12 2012 From: report at bugs.python.org (clikkeb) Date: Mon, 16 Apr 2012 08:30:12 +0000 Subject: [issue14576] IDLE cannot connect to subprocess - New solution In-Reply-To: <1334400065.92.0.605072928338.issue14576@psf.upfronthosting.co.za> Message-ID: <1334565012.98.0.285011418238.issue14576@psf.upfronthosting.co.za> clikkeb added the comment: I think that lines 207-210 of GetUserCfgDir should be modified like this: try: sys.stderr.write(warn) except (IOError, AttributeError): # <---- pass #^^^^^^^^^^^^^^ because when you start IDLE via pythonw.exe (that sets sys.stderr to "None"), the function call sys.stderr.write(warn) raises the following exception: AttributeError: 'NoneType' object has no attribute 'write' and IDLE stops running without displaying any exception error, because that exception is unhandled. There is a funcion call to sys.stderr.write also at line 222, just before a "raise SystemExit" statement, which makes ininfluent the missing AttributeError exception handling. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 11:02:37 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Apr 2012 09:02:37 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1334560452.0.0.530315882187.issue14339@psf.upfronthosting.co.za> Message-ID: <1334567095.17945.724.camel@raxxla> Serhiy Storchaka added the comment: > I think 'x' would be more appropriate. :-) Oops. You are right, of cause. ---------- Added file: http://bugs.python.org/file25234/long_to_binary_base_3.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 13307eb5bf47 Objects/longobject.c --- a/Objects/longobject.c Sat Apr 14 14:20:29 2012 -0500 +++ b/Objects/longobject.c Mon Apr 16 12:01:24 2012 +0300 @@ -1672,11 +1672,10 @@ { register PyLongObject *a = (PyLongObject *)aa; PyObject *v; - Py_ssize_t i, sz; + Py_ssize_t sz; Py_ssize_t size_a; - char *p; - char sign = '\0'; - char *buffer; + Py_UCS1 *p; + int negative; int bits; assert(base == 2 || base == 8 || base == 10 || base == 16); @@ -1688,6 +1687,7 @@ return NULL; } size_a = ABS(Py_SIZE(a)); + negative = Py_SIZE(a) < 0; /* Compute a rough upper bound for the length of the string */ switch (base) { @@ -1706,31 +1706,37 @@ } /* compute length of output string: allow 2 characters for prefix and 1 for possible '-' sign. */ - if (size_a > (PY_SSIZE_T_MAX - 3) / PyLong_SHIFT / sizeof(Py_UCS4)) { + if (size_a > (PY_SSIZE_T_MAX - 3) / PyLong_SHIFT) { PyErr_SetString(PyExc_OverflowError, "int is too large to format"); return NULL; } /* now size_a * PyLong_SHIFT + 3 <= PY_SSIZE_T_MAX, so the RHS below is safe from overflow */ - sz = 3 + (size_a * PyLong_SHIFT + (bits - 1)) / bits; - assert(sz >= 0); - buffer = PyMem_Malloc(sz); - if (buffer == NULL) { + if (size_a == 0) { + sz = 3; + } + else { + sz = 2 + negative + ((size_a - 1) * PyLong_SHIFT + + bits_in_digit(a->ob_digit[size_a - 1]) + + (bits - 1)) / bits; + } + v = PyUnicode_New(sz, 'x'); + if (v == NULL) { PyErr_NoMemory(); return NULL; } - p = &buffer[sz]; - if (Py_SIZE(a) < 0) - sign = '-'; - - if (Py_SIZE(a) == 0) { + assert(PyUnicode_KIND(v) == PyUnicode_1BYTE_KIND); + p = PyUnicode_1BYTE_DATA(v) + sz; + + if (size_a == 0) { *--p = '0'; } else { /* JRH: special case for power-of-2 bases */ twodigits accum = 0; int accumbits = 0; /* # of bits in accum */ + Py_ssize_t i; for (i = 0; i < size_a; ++i) { accum |= (twodigits)a->ob_digit[i] << accumbits; accumbits += PyLong_SHIFT; @@ -1739,7 +1745,7 @@ char cdigit; cdigit = (char)(accum & (base - 1)); cdigit += (cdigit < 10) ? '0' : 'a'-10; - assert(p > buffer); + assert(p > PyUnicode_1BYTE_DATA(v)); *--p = cdigit; accumbits -= bits; accum >>= bits; @@ -1747,6 +1753,7 @@ } } + assert(p == PyUnicode_1BYTE_DATA(v) + 2 + negative); if (base == 16) *--p = 'x'; else if (base == 8) @@ -1754,10 +1761,8 @@ else /* (base == 2) */ *--p = 'b'; *--p = '0'; - if (sign) - *--p = sign; - v = PyUnicode_DecodeASCII(p, &buffer[sz] - p, NULL); - PyMem_Free(buffer); + if (negative) + *--p = '-'; return v; } From report at bugs.python.org Mon Apr 16 11:09:52 2012 From: report at bugs.python.org (Dave Reid) Date: Mon, 16 Apr 2012 09:09:52 +0000 Subject: [issue14591] Value returned by random.random() out of valid range Message-ID: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> New submission from Dave Reid : A particular combination of seed and jumpahead calls seems to force the MT generator into a state where it produces a random variate that is outside the range 0-1. Problem looks like it might be in _randommodule.c:genrand_int32, which produces a value > 0xffffffff for the given state, but I don't understand the generator well enough to debug any further. The attached test case produces 1.58809998297 as the 2nd variate in Python 2.7 and 1.35540900431 as the 23rd variate in Python 2.7.3. The problem occurs on both Linux (CentOS 6) and Mac OSX (10.6.8), both 64-bit. ---------- components: Interpreter Core files: badrand.py messages: 158406 nosy: Dave.Reid priority: normal severity: normal status: open title: Value returned by random.random() out of valid range type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file25235/badrand.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 12:11:05 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 16 Apr 2012 10:11:05 +0000 Subject: [issue8212] A tp_dealloc of a subclassed class cannot resurrect an object In-Reply-To: <1269350912.78.0.210466349131.issue8212@psf.upfronthosting.co.za> Message-ID: <1334571065.69.0.83596156043.issue8212@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Updated the patch with better documentation, and recursion safety. ---------- Added file: http://bugs.python.org/file25236/basedealloc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 12:47:07 2012 From: report at bugs.python.org (Berker Peksag) Date: Mon, 16 Apr 2012 10:47:07 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1334573227.24.0.309760932901.issue13959@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 12:57:15 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Apr 2012 10:57:15 +0000 Subject: [issue14591] Value returned by random.random() out of valid range In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1334573835.64.0.665958854084.issue14591@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Indeed, jumpahead may have problems on non-32-bit platforms. The proposed patch fixes it. Porting to Python 3 is not required. ---------- keywords: +patch nosy: +storchaka Added file: http://bugs.python.org/file25237/random_jumpahead_64bit.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 13:16:37 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 16 Apr 2012 11:16:37 +0000 Subject: [issue14591] Value returned by random.random() out of valid range In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1334574997.99.0.0680181574091.issue14591@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 13:33:01 2012 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 16 Apr 2012 11:33:01 +0000 Subject: [issue14592] old-style (level=-1) importing broken after importlib changes Message-ID: <1334575981.92.0.820846886591.issue14592@psf.upfronthosting.co.za> New submission from Stefan Behnel : Up to the early Py3.3 developer versions, calling __import__() with a level of -1 worked as in Python 2, i.e. it tried a relative import first and then a global import. This no longer seems to be available after the importlib rewrite (e.g. as of rev f341b99bb370). ---------- components: Interpreter Core messages: 158409 nosy: scoder priority: normal severity: normal status: open title: old-style (level=-1) importing broken after importlib changes type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 13:34:36 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 11:34:36 +0000 Subject: [issue14586] TypeError: truncate() takes no keyword arguments In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za> Message-ID: <1334576076.01.0.629107773857.issue14586@psf.upfronthosting.co.za> R. David Murray added the comment: There wouldn't be serious backward incompatibility. Truncate(0) would still mean the same thing as truncate(size=0). I don't remember if we treat supporting the keyword form when it is doced that as a bug or not, though, so you might be right that it can't be backported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 13:38:44 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Apr 2012 11:38:44 +0000 Subject: [issue14593] PyErr_SetFromImportErrorWithNameAndPath lacks error checking Message-ID: <1334576324.57.0.944762137092.issue14593@psf.upfronthosting.co.za> New submission from Antoine Pitrou : The PyErr_SetFromImportErrorWithNameAndPath implementation never checks for the various results returned by the C API functions it invokes. (also, it needs documenting, see python-dev) As for PyErr_SetExcWithArgsKwargs, there's a potential refleak when args is NULL. ---------- components: Interpreter Core messages: 158411 nosy: brett.cannon, brian.curtin, pitrou priority: normal severity: normal stage: needs patch status: open title: PyErr_SetFromImportErrorWithNameAndPath lacks error checking type: resource usage versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 13:40:08 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 11:40:08 +0000 Subject: [issue14588] PEP 3115 compliant dynamic class creation In-Reply-To: <1334535798.87.0.826104374353.issue14588@psf.upfronthosting.co.za> Message-ID: <1334576408.4.0.572041805674.issue14588@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 13:44:44 2012 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 16 Apr 2012 11:44:44 +0000 Subject: [issue14594] document imp.load_dynamic() Message-ID: <1334576684.12.0.825511182603.issue14594@psf.upfronthosting.co.za> New submission from Stefan Behnel : The imp.load_dynamic() function is used by third party code (e.g. Cython's pyximport) but is not currently documented. http://docs.python.org/dev/library/imp.html The latest changes to the import mechanism suggest that it should better be documented to give a hint that users can rely on it. ---------- assignee: docs at python components: Documentation messages: 158412 nosy: docs at python, scoder priority: normal severity: normal status: open title: document imp.load_dynamic() type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From __peter__ at web.de Mon Apr 16 11:55:50 2012 From: __peter__ at web.de (Peter Otten) Date: Mon, 16 Apr 2012 11:55:50 +0200 Subject: [issue14591] Value returned by random.random() out of valid range References: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: Dave Reid wrote: > > New submission from Dave Reid : > > A particular combination of seed and jumpahead calls seems to force the MT > generator into a state where it produces a random variate that is outside > the range 0-1. Problem looks like it might be in > _randommodule.c:genrand_int32, which produces a value > 0xffffffff for the > given state, but I don't understand the generator well enough to debug any > further. > > The attached test case produces 1.58809998297 as the 2nd variate in Python > 2.7 and 1.35540900431 as the 23rd variate in Python 2.7.3. The problem > occurs on both Linux (CentOS 6) and Mac OSX (10.6.8), both 64-bit. A simple way to reproduce the problem: >>> import random >>> r = random.Random() >>> a, b, c = r.getstate() >>> r.setstate((a, (0xffffffff,)*len(b), c)) >>> r.jumpahead(1) >>> r.random() 1.8015423506628903 It looks like in random_jumpahead mt[i] += i+1; needs to be masked mt[i] = (mt[i] + i + 1) & 0xffffffffUL; (random_setstate already does that) From report at bugs.python.org Mon Apr 16 13:50:58 2012 From: report at bugs.python.org (Robert E.) Date: Mon, 16 Apr 2012 11:50:58 +0000 Subject: [issue14595] Complete your registration to Python tracker -- key 25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG In-Reply-To: <20120416114931.F347A1C830@psf.upfronthosting.co.za> Message-ID: <4F8C07A0.20108@re-factory.de> New submission from Robert E. : Am 16.04.2012 13:49, schrieb Python tracker: > To complete your registration of the user "roberte" with > Python tracker, please do one of the following: > > - send a reply to report at bugs.python.org and maintain the subject line as is (the > reply's additional "Re:" is ok), > > - or visit the following URL: > > http://bugs.python.org/?@action=confrego&otk=25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG ---------- messages: 158413 nosy: roberte priority: normal severity: normal status: open title: Complete your registration to Python tracker -- key 25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 13:54:55 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 11:54:55 +0000 Subject: [issue14595] Complete your registration to Python tracker -- key 25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG In-Reply-To: <4F8C07A0.20108@re-factory.de> Message-ID: <1334577295.33.0.860917401132.issue14595@psf.upfronthosting.co.za> R. David Murray added the comment: Something seems to have gone wrong with the 'reply' form. Sorry about that. Please use the URL instead. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 13:57:00 2012 From: report at bugs.python.org (Robert E.) Date: Mon, 16 Apr 2012 11:57:00 +0000 Subject: [issue14595] Complete your registration to Python tracker -- key 25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG In-Reply-To: <1334577295.33.0.860917401132.issue14595@psf.upfronthosting.co.za> Message-ID: <4F8C090A.7000306@re-factory.de> Robert E. added the comment: Well I did that first but the tracker replied: node with key "roberte" exists Seems the username is alread in use but I still could register but not complete the registration. Am 16.04.2012 13:54, schrieb R. David Murray: > > R. David Murray added the comment: > > Something seems to have gone wrong with the 'reply' form. Sorry about that. Please use the URL instead. > > ---------- > nosy: +r.david.murray > resolution: -> invalid > stage: -> committed/rejected > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 14:01:18 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 16 Apr 2012 12:01:18 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334577678.61.0.415134141452.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: The precision of mach_absolute_time() is known: it is timebase.numer / timebase.denom * 1e-9. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 14:01:31 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 16 Apr 2012 12:01:31 +0000 Subject: [issue14591] Value returned by random.random() out of valid range In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1334577691.43.0.497733366883.issue14591@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks for the report and patch. I've investigate and load a fix this week. ---------- assignee: -> rhettinger priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 14:10:12 2012 From: report at bugs.python.org (Robert Elsner) Date: Mon, 16 Apr 2012 12:10:12 +0000 Subject: [issue14596] struct.unpack memory leak Message-ID: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> New submission from Robert Elsner : When unpacking multiple files with _variable_ length, struct unpack leaks massive amounts of memory. The corresponding functions from numpy (fromfile) or the array (fromfile) standard lib module behave as expected. I prepared a minimal testcase illustrating the problem on Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) [GCC 4.4.5] on linux2 This is a severe limitation when reading big files where performance is critical. The struct.Struct class does not display this behavior. Note that the variable length of the buffer is necessary to reproduce the problem (as is usually the case with real data files). I suspect this is due to some internal buffer in the struct module not being freed after use. I did not test on later Python versions, but could not find a related bug in the tracker. ---------- components: Library (Lib) files: unpack_memory_leak.py messages: 158418 nosy: Robert.Elsner priority: normal severity: normal status: open title: struct.unpack memory leak versions: Python 2.6 Added file: http://bugs.python.org/file25238/unpack_memory_leak.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 14:18:44 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 16 Apr 2012 12:18:44 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1334578724.18.0.0639014663588.issue14596@psf.upfronthosting.co.za> Mark Dickinson added the comment: Do you see the same results with Python 2.7? Python 2.6 is only receiving security bugfixes at this point. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 14:22:03 2012 From: report at bugs.python.org (Robert Elsner) Date: Mon, 16 Apr 2012 12:22:03 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1334578923.66.0.858768090416.issue14596@psf.upfronthosting.co.za> Robert Elsner added the comment: I would love to test but I am in a production environment atm and can't really spare the time to set up a test box. But maybe somebody with access to 2.7 on linux could test it with the supplied script (just start it and it should happily eat 8GB of memory - I think most users are going to notice ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 14:25:08 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 16 Apr 2012 12:25:08 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1334579108.16.0.286213927166.issue14596@psf.upfronthosting.co.za> Mark Dickinson added the comment: I suspect that this is due to the struct module cache, which caches Struct instances corresponding to formats used. If that's true, there's no real leak as such. As a test, what happens if you increase your xrange(30) to xrange(300)? (And perhaps decrease the size of the struct itself a bit to compensate). You should see that memory usage stays constant after the first ~100 runs. Using Struct directly is a good workaround if this is a problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 14:30:28 2012 From: report at bugs.python.org (Robert Elsner) Date: Mon, 16 Apr 2012 12:30:28 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1334579428.05.0.472115339974.issue14596@psf.upfronthosting.co.za> Robert Elsner added the comment: Well seems like 3.1 is in the Debian repos as well. Same memory leak. So it is very unlikely it has been fixed in 2.7. I modified the test case to be compatible to 3.1 and 2.6. ---------- versions: +Python 3.1 Added file: http://bugs.python.org/file25239/unpack_memory_leak.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 14:35:44 2012 From: report at bugs.python.org (Robert Elsner) Date: Mon, 16 Apr 2012 12:35:44 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1334579744.55.0.286784173297.issue14596@psf.upfronthosting.co.za> Robert Elsner added the comment: Well the problem is, that performance is severely degraded when calling unpack multiple times. I do not know in advance the size of the files and they might vary in size from 1M to 1G. I could use some fixed-size buffer which is inefficient depending on the file size (too big or too small). And if I change the buffer on the fly, I end up with the memory leak. I think the caching should take into account the available memory on the system. the no_leak function has comparable performance without the leak. And I think there is no point in caching Struct instances when they go out of scope and can not be accessed anymore? If i let it slip from the scope I do not want to use it thereafter. Especially considering that struct.Struct behaves as expected as do array.fromfile and numpy.fromfile. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 14:45:15 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 16 Apr 2012 12:45:15 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1334580315.48.0.748874376191.issue14304@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This codec is one that is equal to UTF-8, but restricted to the BMP. For non-BMP character, the error handler is called. It will be the stdout codec for the IDLE interactive shell, causing non-BMP results to be ascii() escaped. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 14:47:07 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 12:47:07 +0000 Subject: [issue14595] Complete your registration to Python tracker -- key 25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG In-Reply-To: <4F8C07A0.20108@re-factory.de> Message-ID: <1334580427.91.0.312504930978.issue14595@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. The account *looks* normal, and has your email address attached. Can you log in using the password you chose? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 14:50:53 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 16 Apr 2012 12:50:53 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1334580653.65.0.682540824046.issue14304@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Tkinter (as Tcl itself) has no support of non-BMP characters in any form. It looks like support of UTF-16 without surrogates. I like to implement codec for that which will process different error modes (strict, replace, ignore etc) as well as others codecs does. It will allow to support BMP well and control processing of non-BMP in IDLE. About your second question. IDLE has interactive shell. This shell in REPL will try to print expression result. It it contains non-BMP whole result is converted to ASCII with escaping. It's different from standard python console. From my perspective expected behavior is to pass BMP chars and escape only non-BMP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 14:51:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Apr 2012 12:51:29 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1334580689.19.0.538042277862.issue14596@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I suspect that this is due to the struct module cache, which caches > Struct instances corresponding to formats used. If that's true, > there's no real leak as such. Well, the posted code creates 30 struct instances. That shouldn't exhaust the memory of a 8GB box (which it does here)... ---------- nosy: +pitrou type: -> resource usage versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 14:51:43 2012 From: report at bugs.python.org (Robert E.) Date: Mon, 16 Apr 2012 12:51:43 +0000 Subject: [issue14595] Complete your registration to Python tracker -- key 25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG In-Reply-To: <1334580427.91.0.312504930978.issue14595@psf.upfronthosting.co.za> Message-ID: <4F8C15DC.7090404@re-factory.de> Robert E. added the comment: No I can't (says invalid login). I created a new account using my Google ID which works alright. If you want to debug this problem I am happy to help but otherwise this "bug entry" can be removed. Cheers Am 16.04.2012 14:47, schrieb R. David Murray: > > R. David Murray added the comment: > > Hmm. The account *looks* normal, and has your email address attached. Can you log in using the password you chose? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 14:56:22 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Apr 2012 12:56:22 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1334580982.24.0.719129119221.issue14596@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, the problem is the place to be in Python 2.7, in Python 3.2 and in Python 3.3. Random size of the structure is important -- if you remove the randint, leakage will not. The memory is not released in cached structuress, which are created in module-level unpack. I now deal with it. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 14:58:36 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 16 Apr 2012 12:58:36 +0000 Subject: [issue12081] Remove distributed copy of libffi In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za> Message-ID: <1334581116.29.0.301038835997.issue12081@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Arfrever: I doubt anybody has contributed patches back, or that anybody is interested in doing so. I personally don't see a problem in using an old libffi version, so I fail to see Benjamin's issue. Figuring out how exactly to use the system libffi is more hassle than keeping our own copy. Please understand that ctypes is unmaintained. Anybody actively taking over maintenance of ctypes would have to decide on how integration with libffi is supposed to work. Without a maintainer, falling back to the sytem libffi is a too high risk, IMO, since this will certainly produce tons of new bug reports, with nobody prepared to deal with them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:02:51 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Apr 2012 13:02:51 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1334581371.59.0.658435383651.issue14596@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It appears the storage of Struct instances is rather inefficient when there's a repeat code such as "<48L". In this example, 48 almost identical structures describing the "L" format (struct _formatcode) will be created. You can guess what happens with large repeat counts... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:06:04 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 16 Apr 2012 13:06:04 +0000 Subject: [issue12723] Provide an API in tkSimpleDialog for defining custom validation functions In-Reply-To: <1312989791.6.0.177522419712.issue12723@psf.upfronthosting.co.za> Message-ID: <1334581564.71.0.809832063534.issue12723@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:08:18 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 16 Apr 2012 13:08:18 +0000 Subject: [issue14576] IDLE cannot connect to subprocess - New solution In-Reply-To: <1334400065.92.0.605072928338.issue14576@psf.upfronthosting.co.za> Message-ID: <1334581698.88.0.369254162529.issue14576@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I guess IdleConf should to have flag like 'writable'. If user environment points to invalid location (or there are no write access) this flag should be set. It flag can affect IDLE configuration dialog: user should be notified what him changes will not be permanently saved. Subprocess can check that flag as well if need. BTW, there are related issue8231. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:09:33 2012 From: report at bugs.python.org (Pat Lynch) Date: Mon, 16 Apr 2012 13:09:33 +0000 Subject: [issue14597] Cannot unload dll in ctypes until script exits Message-ID: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za> New submission from Pat Lynch : If I load a dll in ctypes, then delete that loaded DLL instance, the DLL is not unloaded until the script finishes and exits. I'm trying to write some unit tests in python to exercise that DLL where each test case loads a DLL, does some work, then unloads the DLL. Unfortunately the DLL only gets unloaded when the unit tests finish. I've tried forcing the garbage collector to run to get the DLL to unload. It did nothing... # load the DLL parser_dll = CDLL(dllpath) # do some work here # 'unload' the dll (or as close as I can get it to it) if (parser_dll): del parser_dll ---------- components: ctypes messages: 158433 nosy: plynch76 priority: normal severity: normal status: open title: Cannot unload dll in ctypes until script exits type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:10:35 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 13:10:35 +0000 Subject: [issue14595] Complete your registration to Python tracker -- key 25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG In-Reply-To: <4F8C07A0.20108@re-factory.de> Message-ID: <1334581835.25.0.126104863355.issue14595@psf.upfronthosting.co.za> R. David Murray added the comment: As long as you are good with a registered account, that's what's important. If I get time I'll take a deeper look, but most likely I won't unless this happens again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:13:40 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 13:13:40 +0000 Subject: [issue14592] old-style (level=-1) importing broken after importlib changes In-Reply-To: <1334575981.92.0.820846886591.issue14592@psf.upfronthosting.co.za> Message-ID: <1334582020.7.0.502124418037.issue14592@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:13:51 2012 From: report at bugs.python.org (Pat Lynch) Date: Mon, 16 Apr 2012 13:13:51 +0000 Subject: [issue14597] Cannot unload dll in ctypes until script exits In-Reply-To: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za> Message-ID: Pat Lynch added the comment: I should mention also, that this is mostly an issue for me on Win7 x64. It does behave 'slightly' better on WinXP x86. (I have the 64-bit version of python installed on Win7 x64 & the 32-bit version installed on WinXP) thanks, Pat. On 16 April 2012 14:09, Pat Lynch wrote: > > New submission from Pat Lynch : > > If I load a dll in ctypes, then delete that loaded DLL instance, the DLL > is not unloaded until the script finishes and exits. > > I'm trying to write some unit tests in python to exercise that DLL where > each test case loads a DLL, does some work, then unloads the DLL. > Unfortunately the DLL only gets unloaded when the unit tests finish. > > I've tried forcing the garbage collector to run to get the DLL to unload. > It did nothing... > > # load the DLL > parser_dll = CDLL(dllpath) > > # do some work here > > # 'unload' the dll (or as close as I can get it to it) > if (parser_dll): > del parser_dll > > ---------- > components: ctypes > messages: 158433 > nosy: plynch76 > priority: normal > severity: normal > status: open > title: Cannot unload dll in ctypes until script exits > type: enhancement > versions: Python 2.7 > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:14:02 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 16 Apr 2012 13:14:02 +0000 Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za> Message-ID: <1334582042.61.0.0788413539652.issue4130@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Changes to ctypes should not affect the gdbm module. More likely, icc and python just don't work together. It may be a compiler bug in icc (it wouldn't be the first one discovered by Python), or it may be a portability defect in Python (where it wouldn't be the first case, either). In any case, the gdbm issue is likely unrelated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:14:37 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 16 Apr 2012 13:14:37 +0000 Subject: [issue14592] old-style (level=-1) importing broken after importlib changes In-Reply-To: <1334575981.92.0.820846886591.issue14592@psf.upfronthosting.co.za> Message-ID: <1334582077.61.0.939148611624.issue14592@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Relative imports are no longer supported in python 3, so this makes sense. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:14:48 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 16 Apr 2012 13:14:48 +0000 Subject: [issue14592] old-style (level=-1) importing broken after importlib changes In-Reply-To: <1334575981.92.0.820846886591.issue14592@psf.upfronthosting.co.za> Message-ID: <1334582088.85.0.175951150862.issue14592@psf.upfronthosting.co.za> Benjamin Peterson added the comment: By "relative" I meant "sibling". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:17:43 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 13:17:43 +0000 Subject: [issue14594] document imp.load_dynamic() In-Reply-To: <1334576684.12.0.825511182603.issue14594@psf.upfronthosting.co.za> Message-ID: <1334582263.3.0.581320631905.issue14594@psf.upfronthosting.co.za> R. David Murray added the comment: This is essentially a duplicate of issue 14551, but perhaps with a bit more weight behind it. ---------- nosy: +brett.cannon, pitrou, r.david.murray versions: -Python 2.6, Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:21:56 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Apr 2012 13:21:56 +0000 Subject: [issue14594] document imp.load_dynamic() In-Reply-To: <1334576684.12.0.825511182603.issue14594@psf.upfronthosting.co.za> Message-ID: <1334582516.27.0.327318977112.issue14594@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, let's redocument them, then :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:25:26 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 16 Apr 2012 13:25:26 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1334515693.42.0.543675526996.issue14339@psf.upfronthosting.co.za> Message-ID: <4F8C1DC4.6010400@v.loewis.de> Martin v. L?wis added the comment: > (1) The patch appears to assume that a Unicode string created with > PyUnicode_New(size, 127) will have 'kind' PyUnicode_1BYTE_KIND. > While this might be true in the current implementation, I don't know > whether this is guaranteed in general. Martin, any comments on > this? There is a guarantee that the shortest form must always be used. So as long as the Unicode representation doesn't fundamentally change again, this property is indeed guaranteed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:25:29 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 16 Apr 2012 13:25:29 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1334582729.21.0.971857169377.issue14596@psf.upfronthosting.co.za> Mark Dickinson added the comment: > It appears the storage of Struct instances is rather inefficient when > there's a repeat code such as "<48L" Right. Repeat counts aren't directly supported in the underlying PyStructObject; a format string containing repeat counts is effectively 'compiled' to a series of (type, offset, size) triples before it can be used. The caching is there to save repeated compilations when the same format string is used repeatedly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:30:06 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 13:30:06 +0000 Subject: [issue14597] Cannot unload dll in ctypes until script exits In-Reply-To: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za> Message-ID: <1334583006.05.0.521688586738.issue14597@psf.upfronthosting.co.za> R. David Murray added the comment: In general it is difficult to impossible to get Python2 to unload modules before the interpreter shuts down. See issue 9072. I'm not savvy enough with the C stuff to know if the fact that you loaded it via ctypes changes anything, but I doubt it. Note that the implication of that issue is that if you could move to Python3 there might be a way to do it, but that would indeed be an enhancement as there is no direct support for it yet. ---------- nosy: +r.david.murray versions: +Python 3.3 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:31:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Apr 2012 13:31:13 +0000 Subject: [issue8212] A tp_dealloc of a subclassed class cannot resurrect an object In-Reply-To: <1269350912.78.0.210466349131.issue8212@psf.upfronthosting.co.za> Message-ID: <1334583073.39.0.473040779285.issue8212@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Urg, that's a horrible hack. How about instead having an API function to resurrect an object from a tp_dealloc? That way the iobase_dealloc code would be written: if (_PyIOBase_finalize((PyObject *) self) < 0) { _PyObject_ResurrectFromDealloc(self); return; } That API function could also perhaps take care of the _Py_NewReference stuff (see the end of _PyIOBase_finalize). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:31:15 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 16 Apr 2012 13:31:15 +0000 Subject: [issue14588] PEP 3115 compliant dynamic class creation In-Reply-To: <1334535798.87.0.826104374353.issue14588@psf.upfronthosting.co.za> Message-ID: <1334583075.51.0.978103736798.issue14588@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:35:43 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Apr 2012 13:35:43 +0000 Subject: [issue14597] Cannot unload dll in ctypes until script exits In-Reply-To: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za> Message-ID: <1334583343.44.0.500497531301.issue14597@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brian.curtin, meador.inge, tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:38:50 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 16 Apr 2012 13:38:50 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1331932171.45.0.56771909125.issue14339@psf.upfronthosting.co.za> Message-ID: <1334583530.46.0.867855229293.issue14339@psf.upfronthosting.co.za> Mark Dickinson added the comment: > There is a guarantee that the shortest form must always be used. Okay, sounds good. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:44:26 2012 From: report at bugs.python.org (Pat Lynch) Date: Mon, 16 Apr 2012 13:44:26 +0000 Subject: [issue14597] Cannot unload dll in ctypes until script exits In-Reply-To: <1334583006.05.0.521688586738.issue14597@psf.upfronthosting.co.za> Message-ID: Pat Lynch added the comment: thanks for the very quick response. Since LoadLibrary is called in the constructor, why can't FreeLibrary be called in the destructor? or at least expose a function to unload that calls FreeLibrary? http://msdn.microsoft.com/en-us/library/windows/desktop/ms683152%28v=vs.85%29.aspx thanks again, Pat. On 16 April 2012 14:30, R. David Murray wrote: > > R. David Murray added the comment: > > In general it is difficult to impossible to get Python2 to unload modules > before the interpreter shuts down. See issue 9072. I'm not savvy enough > with the C stuff to know if the fact that you loaded it via ctypes changes > anything, but I doubt it. > > Note that the implication of that issue is that if you could move to > Python3 there might be a way to do it, but that would indeed be an > enhancement as there is no direct support for it yet. > > ---------- > nosy: +r.david.murray > versions: +Python 3.3 -Python 2.7 > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:44:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Apr 2012 13:44:45 +0000 Subject: [issue14452] SysLogHandler sends invalid messages when using unicode In-Reply-To: <1333105941.84.0.159307303218.issue14452@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset af46a001d5ec by Vinay Sajip in branch '2.7': Issue #14452: remove BOM insertion code. http://hg.python.org/cpython/rev/af46a001d5ec New changeset 89ab589f6fa7 by Vinay Sajip in branch '3.2': Closes #14452: remove BOM insertion code. http://hg.python.org/cpython/rev/89ab589f6fa7 New changeset 372aa4267a43 by Vinay Sajip in branch 'default': Closes #14452: remove BOM insertion code. http://hg.python.org/cpython/rev/372aa4267a43 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:45:22 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 16 Apr 2012 13:45:22 +0000 Subject: [issue14597] Cannot unload dll in ctypes until script exits In-Reply-To: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za> Message-ID: <1334583922.92.0.741599931901.issue14597@psf.upfronthosting.co.za> Martin v. L?wis added the comment: In principle, it should be possible (but perhaps not desirable, see below) to call FreeLibrary in a CDLL's __del__. However, since this would be a new feature, it can't go into 2.7. Patches are welcome; make sure to support both FreeLIbrary and dlclose. There is a general issue with closing/freeing DLLs: if they are still referenced somewhere (e.g. in an atexit function, a C++ virtual method table, or on the call stack of another thread), then a later access to the code will crash the interpreter. In a typical DLL today (including all Python extension modules), the likelihood of crashes is close to 100%. For that reason, it's probably not a good idea to have ctypes auto-close DLLs; instead, it should be an opt-in mechanism. For most ctypes uses, closing is irrelevant, since people typically access system libraries that are independently loaded anyway, so closing them would not have any effect. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:46:29 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 16 Apr 2012 13:46:29 +0000 Subject: [issue8212] A tp_dealloc of a subclassed class cannot resurrect an object In-Reply-To: <1269350912.78.0.210466349131.issue8212@psf.upfronthosting.co.za> Message-ID: <1334583989.01.0.146070206245.issue8212@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Ok, that sounds reasonable, particularly in light of that _NewReference stuff. I'll work out a different patch then. But I think the API must be public, since it would need to work from extension modules. So: if a c type decides that it wants to live after a tp_dealloc(), it must call this api ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:50:22 2012 From: report at bugs.python.org (Jim Jewett) Date: Mon, 16 Apr 2012 13:50:22 +0000 Subject: [issue14569] pystate.c #ifdef ordering problem In-Reply-To: <1334312373.76.0.210220439888.issue14569@psf.upfronthosting.co.za> Message-ID: Jim Jewett added the comment: On Fri, Apr 13, 2012 at 6:19 AM, Antoine Pitrou added the comment: > I don't think you need anyone's permission to commit such a fix :) Well, *I* would, since I don't have commit privs, and don't currently have a C dev environment with which to test. But I figured testing the various build conditions might be good documentation-of-ability for someone applying to GSoC or otherwise trying to get started. (OK, the timing wouldn't be ideal, ...) That said, I foresee adding build-multiple-ways to the regression tests (as opposed to a buildbot), so I'll let the next applicant come up with something else. :D ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:53:53 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 16 Apr 2012 13:53:53 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1334584433.11.0.398461399177.issue14596@psf.upfronthosting.co.za> Mark Dickinson added the comment: Perhaps the best quick fix would be to only cache small PyStructObjects, for some value of 'small'. (Total size < a few hundred bytes, perhaps.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:57:12 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Apr 2012 13:57:12 +0000 Subject: [issue8212] A tp_dealloc of a subclassed class cannot resurrect an object In-Reply-To: <1334583989.01.0.146070206245.issue8212@psf.upfronthosting.co.za> Message-ID: <1334584575.3426.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > Ok, that sounds reasonable, particularly in light of that > _NewReference stuff. I'll work out a different patch then. But I > think the API must be public, since it would need to work from > extension modules. Needing to work from (stdlib) extension modules and being public are too different things. I don't think we want to encourage third-party types to resurrect their instances. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 15:59:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Apr 2012 13:59:06 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334584433.11.0.398461399177.issue14596@psf.upfronthosting.co.za> Message-ID: <1334584688.3426.3.camel@localhost.localdomain> Antoine Pitrou added the comment: > Perhaps the best quick fix would be to only cache small > PyStructObjects, for some value of 'small'. (Total size < a few > hundred bytes, perhaps.) Or perhaps not care at all? Is there a use case for huge repeat counts? (limiting cacheability could decrease performance in existing applications) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 16:04:56 2012 From: report at bugs.python.org (Pat Lynch) Date: Mon, 16 Apr 2012 14:04:56 +0000 Subject: [issue14597] Cannot unload dll in ctypes until script exits In-Reply-To: <1334583922.92.0.741599931901.issue14597@psf.upfronthosting.co.za> Message-ID: Pat Lynch added the comment: ok, that's fair enough if most usage of ctypes is from people accessing system libraries :) I wouldn't have thought my usage was that weird though (given the strength of using python for unit testing). In local tests, adding a function CDLL::ForceUnloadDll (which just calls FreeLibrary(self._handle)) seems to work well. I haven't done intensive testing though at this point. I could be missing something though. thanks, Pat. On 16 April 2012 14:45, Martin v. L?wis wrote: > > Martin v. L?wis added the comment: > > In principle, it should be possible (but perhaps not desirable, see below) > to call FreeLibrary in a CDLL's __del__. However, since this would be a new > feature, it can't go into 2.7. Patches are welcome; make sure to support > both FreeLIbrary and dlclose. > > There is a general issue with closing/freeing DLLs: if they are still > referenced somewhere (e.g. in an atexit function, a C++ virtual method > table, or on the call stack of another thread), then a later access to the > code will crash the interpreter. In a typical DLL today (including all > Python extension modules), the likelihood of crashes is close to 100%. For > that reason, it's probably not a good idea to have ctypes auto-close DLLs; > instead, it should be an opt-in mechanism. > > For most ctypes uses, closing is irrelevant, since people typically access > system libraries that are independently loaded anyway, so closing them > would not have any effect. > > ---------- > nosy: +loewis > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 16:13:57 2012 From: report at bugs.python.org (Andrew Suffield) Date: Mon, 16 Apr 2012 14:13:57 +0000 Subject: [issue14432] Bug in generator if the generator in created in a C thread In-Reply-To: <1332948868.24.0.309034348776.issue14432@psf.upfronthosting.co.za> Message-ID: <1334585637.93.0.985530722738.issue14432@psf.upfronthosting.co.za> Andrew Suffield added the comment: I think I've tripped over a variation on this theme using pyqt and 2.7: When working in a QThread, the PyGILState_Ensure call when transitioning control from Qt to python will frequently allocate a new thread state - because every time control returns to the Qt event loop, gilstate_counter is likely to become zero. If a generator is kept around longer than this, it becomes quite likely to have an older thread state in f_tstate. This happens all the time. The access that blows up on me is PyEval_GetRestricted, since PyFrame_IsRestricted checks f_tstate. Annoyingly this debris is still called on the possibly-restricted operations even when restricted execution is nowhere in sight. Hence, any use of open() in a long-lived generator in a QThread is probably going to crash. Patch against 2.7? ---------- nosy: +asuffield _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 16:21:31 2012 From: report at bugs.python.org (Robert Elsner) Date: Mon, 16 Apr 2012 14:21:31 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334584688.3426.3.camel@localhost.localdomain> Message-ID: <4F8C2AE6.7070309@googlemail.com> Robert Elsner added the comment: Well I stumbled across this leak while reading big files. And what is the point of having a fast C-level unpack when it can not be used with big files? I am not adverse to the idea of caching the format string but if the cache grows beyond a reasonable size, it should be freed. And "reasonable" is not the number of objects contained but the amount of memory it consumes. And caching an arbitrary amount of data (8GB here) is a waste of memory. And reading the Python docs, struct.Struct.unpack which is _not_ affected from the memory leak is supposed to be faster. Quote: > class struct.Struct(format) > > Return a new Struct object which writes and reads binary data according to the format string format. Creating a Struct object once and calling its methods is more efficient than calling the struct functions with the same format since the format string only needs to be compiled once. Caching in case of struct.Struct is straightforward: As long as the object exists, the format string is cached and if the object is no longer accessible, its memory gets freed - including the cached format string. The problem is with the "magic" creation of struct.Struct objects by struct.unpack that linger around even after all associated variables are no longer in scope. Using for example fixed 1MB buffer to read files (regardless of size) incurs a huge performance penalty. Reading everything at once into memory using struct.unpack (or with the same speed struct.Struct.unpack) is the fastest way. Approximately 40% faster than array.fromfile and and 70% faster than numpy.fromfile. I read some unspecified report about a possible memory leak in struct.unpack but the author did not investigate further. It took me quite some time to figure out what exactly happens. So there should be at least a warning about this (ugly) behavior when reading big files for speed and a pointer to a quick workaround (using struct.Struct.unpack). cheers Am 16.04.2012 15:59, schrieb Antoine Pitrou: > > Antoine Pitrou added the comment: > >> Perhaps the best quick fix would be to only cache small >> PyStructObjects, for some value of 'small'. (Total size < a few >> hundred bytes, perhaps.) > > Or perhaps not care at all? Is there a use case for huge repeat counts? > (limiting cacheability could decrease performance in existing > applications) > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 16:22:56 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 14:22:56 +0000 Subject: [issue14594] document imp.load_dynamic() In-Reply-To: <1334576684.12.0.825511182603.issue14594@psf.upfronthosting.co.za> Message-ID: <1334586176.11.0.365112907241.issue14594@psf.upfronthosting.co.za> R. David Murray added the comment: Yeah, they really need to be documented in order for us to document them as deprecated if we decide we really want to remove them later. "Obsolete" is not, I think, the same as "deprecated". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 16:30:36 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 14:30:36 +0000 Subject: [issue14452] SysLogHandler sends invalid messages when using unicode In-Reply-To: <1333105941.84.0.159307303218.issue14452@psf.upfronthosting.co.za> Message-ID: <1334586636.82.0.649667822875.issue14452@psf.upfronthosting.co.za> R. David Murray added the comment: This appears to be failing on the buildbots: http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/3358/steps/test/logs/stdio http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/2037/steps/test/logs/stdio ---------- nosy: +r.david.murray status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 16:42:52 2012 From: report at bugs.python.org (sbt) Date: Mon, 16 Apr 2012 14:42:52 +0000 Subject: [issue14087] multiprocessing.Condition.wait_for missing In-Reply-To: <1329922885.58.0.881756065062.issue14087@psf.upfronthosting.co.za> Message-ID: <1334587372.8.0.869020617866.issue14087@psf.upfronthosting.co.za> sbt added the comment: New patch which calculates endtime outside loop. ---------- Added file: http://bugs.python.org/file25240/cond_wait_for.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 16:56:47 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Apr 2012 14:56:47 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1334588207.85.0.0319557013719.issue14304@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Example: >>> '\u0100' '?' >>> '\u0100\U00010000' '\u0100\U00010000' >>> print('\u0100') ? >>> print('\u0100\U00010000') Traceback (most recent call last): File "", line 1, in print('\u0100\U00010000') UnicodeEncodeError: 'UCS-2' codec can't encode characters in position 1-1: Non-BMP character not supported in Tk But I think that it is too specific problem and too specific solution. It would be better if IDLE itself escapes the string in the most appropriate way. def utf8bmp_encode(s): return ''.join(c if ord(c) <= 0xffff else '\\U%08x' % ord(c) for c in s).encode('utf-8') or def utf8bmp_encode(s): return re.sub('[^\x00-\uffff]', lambda m: '\\U%08x' % ord(m.group()), s).encode('utf-8') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 17:06:15 2012 From: report at bugs.python.org (Alexey Luchko) Date: Mon, 16 Apr 2012 15:06:15 +0000 Subject: [issue14437] _io build fails on cygwin In-Reply-To: <1333017729.78.0.731120950882.issue14437@psf.upfronthosting.co.za> Message-ID: <1334588775.28.0.914096974963.issue14437@psf.upfronthosting.co.za> Alexey Luchko added the comment: Final 2.7.3 didn't get the fix. Checked http://python.org/ftp/python/2.7.3/Python-2.7.3.tar.xz ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 17:06:46 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 16 Apr 2012 15:06:46 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1334588806.96.0.704570792248.issue14596@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Or perhaps not care at all? That's also possible. :-) IMO, Robert's use-case doesn't really match the intended use-case for struct (parsing structures of values laid out like a C-struct ). There the caching makes sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 17:13:18 2012 From: report at bugs.python.org (sbt) Date: Mon, 16 Apr 2012 15:13:18 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: <1334589198.61.0.660524452736.issue11750@psf.upfronthosting.co.za> sbt added the comment: > How about _windowsapi or _winapi then, to ensure there are no clashes? I don't have any strong feelings, but I would prefer _winapi. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 17:22:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 16 Apr 2012 15:22:48 +0000 Subject: [issue14452] SysLogHandler sends invalid messages when using unicode In-Reply-To: <1333105941.84.0.159307303218.issue14452@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 603301cfb194 by Vinay Sajip in branch 'default': Closes #14452: brought tests in line with removal of BOM insertion code. http://hg.python.org/cpython/rev/603301cfb194 ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 17:26:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Apr 2012 15:26:40 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1334589198.61.0.660524452736.issue11750@psf.upfronthosting.co.za> Message-ID: <1334589943.3426.4.camel@localhost.localdomain> Antoine Pitrou added the comment: > > How about _windowsapi or _winapi then, to ensure there are no clashes? > > I don't have any strong feelings, but I would prefer _winapi. Ditto here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 17:27:14 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Apr 2012 15:27:14 +0000 Subject: [issue14592] old-style (level=-1) importing broken after importlib changes In-Reply-To: <1334575981.92.0.820846886591.issue14592@psf.upfronthosting.co.za> Message-ID: <1334590034.45.0.940223244548.issue14592@psf.upfronthosting.co.za> Brett Cannon added the comment: What Benjamin said. PEP 328 should have done away with relative imports, but somehow the __import__() function itself was not updated even though its docs were changed to say that index defaulted to 0. So this isn't actually a regressions because of importlib but actually just the implicit fixing of a bug. I was going to make sure to mention it in the "What's New" entry, but I will also add something to Misc/NEWS. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 17:28:11 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 16 Apr 2012 15:28:11 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1334590091.12.0.405335872983.issue14304@psf.upfronthosting.co.za> Andrew Svetlov added the comment: The way is named 'codec'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 17:29:15 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 16 Apr 2012 15:29:15 +0000 Subject: [issue2193] Cookie Colon Name Bug In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za> Message-ID: <1334590155.83.0.0520010857749.issue2193@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I tested setting cookies with ":" in the cookie name in both firefox and google-chrome. They both seem to allow and store the cookie with ":" in them. Firefox sent a request header like this: Set-Cookie test:value=solution:is:he the cookie with name containing ; or , failed. The patched attached tries to silence the error with SimpleCookie. I am not sure how far it is going to help. I believe, we could just allow it from 3.3 onwards or create a new BrowserCookie class which is more lenient than SimpleCookie. As far I see, the allowing ":" in the Legalchars seem to have met with negative votes because it was not in RFC, but well it seems some kind of de-facto acceptable behaviour with browsers, so having from a new version may not cause any harm. +1 to that. I can modify the tests from the attached patch. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 17:32:26 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Apr 2012 15:32:26 +0000 Subject: [issue14592] old-style (level=-1) importing broken after importlib changes In-Reply-To: <1334575981.92.0.820846886591.issue14592@psf.upfronthosting.co.za> Message-ID: <1334590346.58.0.991123570704.issue14592@psf.upfronthosting.co.za> Brett Cannon added the comment: I should also mention that the support for -1 indexing in Python 3 was weird because support was partially removed, but some 'if' checks only did ``< 1`` and so negative indices didn't trigger an error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 17:35:35 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 16 Apr 2012 15:35:35 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1334588207.85.0.0319557013719.issue14304@psf.upfronthosting.co.za> Message-ID: <4F8C3C46.4060605@v.loewis.de> Martin v. L?wis added the comment: > But I think that it is too specific problem and too specific > solution. It would be better if IDLE itself escapes the string in the > most appropriate way. That is not implementable correctly. If you think otherwise, please submit a patch. If not, please trust me on that judgment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 17:41:35 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Apr 2012 15:41:35 +0000 Subject: [issue14594] document imp.load_dynamic() In-Reply-To: <1334576684.12.0.825511182603.issue14594@psf.upfronthosting.co.za> Message-ID: <1334590895.07.0.889364789824.issue14594@psf.upfronthosting.co.za> Brett Cannon added the comment: I'm fine w/ documenting load_dynamic() and leaving it as-is since importlib uses the function itself (plus the frozen/builtin functions, although the frozen stuff might be simplified since they can probably just return the bytes for the frozen module instead of doing as much work in C code). But load_package(), load_source(), and load_module() need to go. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 17:44:40 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Apr 2012 15:44:40 +0000 Subject: [issue14583] try/except import fails --without-threads In-Reply-To: <1334436331.01.0.461185960127.issue14583@psf.upfronthosting.co.za> Message-ID: <1334591080.63.0.905232104028.issue14583@psf.upfronthosting.co.za> Brett Cannon added the comment: Just to clarify the failure for the bug history, somehow multiprocessing is not ending up in sys.modules as expected. It changed from a SystemError to a KeyError because I started to properly check a PyDict_GetItem() return value instead of blindly assuming something was going to be in sys.modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 17:45:28 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Apr 2012 15:45:28 +0000 Subject: [issue14551] imp.load_source docs removed from python3 docs...is this correct? In-Reply-To: <1334168911.32.0.490760920072.issue14551@psf.upfronthosting.co.za> Message-ID: <1334591128.19.0.659333927588.issue14551@psf.upfronthosting.co.za> Brett Cannon added the comment: David, did you find load_source() convenient because you could specify the file to use for the module's source? Did you actually like the file object argument? Just trying to gauge if some new API is needed on a loader of if the one-liner I proposed is good enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 17:48:31 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Apr 2012 15:48:31 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1334591311.23.0.134163970162.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: >From Eric Smith on python-dev: > + suffix, mode, type_ = details > + if mode and (not mode.startswith(('r', 'U'))) or '+' in mode: > + raise ValueError('invalid file open mode {!r}'.format(mode)) Should this be: if mode and (not mode.startswith(('r', 'U')) or '+' in mode): to match: > - if (*mode) { ... > - if (!(*mode == 'r' || *mode == 'U') || strchr(mode, '+')) { > - PyErr_Format(PyExc_ValueError, > - "invalid file open mode %.200s", mode); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 17:49:30 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 16 Apr 2012 15:49:30 +0000 Subject: [issue14437] _io build fails on cygwin In-Reply-To: <1333017729.78.0.731120950882.issue14437@psf.upfronthosting.co.za> Message-ID: <1334591370.43.0.320190080129.issue14437@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Yes, the 2.7.3 branch was cut long before the fix (end of February) so it was not included. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 18:00:24 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 16 Apr 2012 16:00:24 +0000 Subject: [issue14591] Value returned by random.random() out of valid range In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1334592024.42.0.266207196919.issue14591@psf.upfronthosting.co.za> Mark Dickinson added the comment: Patch looks good to me. There's one other subtle bug in random_jumpahead, which is that it's not guaranteed that the resulting state is nonzero. The way to fix this is to add a line like the one near the end of the 'init_by_array' function. mt[0] = 0x80000000UL; /* MSB is 1; assuring non-zero initial array */ ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 18:02:16 2012 From: report at bugs.python.org (sbt) Date: Mon, 16 Apr 2012 16:02:16 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: <1334592136.72.0.358461405189.issue11750@psf.upfronthosting.co.za> sbt added the comment: s/_win32/_winapi/g ---------- Added file: http://bugs.python.org/file25241/winapi_module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 18:07:53 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 16:07:53 +0000 Subject: [issue14551] imp.load_source docs removed from python3 docs...is this correct? In-Reply-To: <1334168911.32.0.490760920072.issue14551@psf.upfronthosting.co.za> Message-ID: <1334592473.2.0.465411078087.issue14551@psf.upfronthosting.co.za> R. David Murray added the comment: The one-liner is "good enough", but... The use case is indeed loading a module from an arbitrary file without having to worry about sys.path, etc. For that load_source is intuitive. The one-liner is an adequate substitute, but feels like a step backward for this particular use case. That is, load_source is a *convenience* function, from my POV :) I did not use the 'file' argument. If I were dealing with an already open file it would seem more natural to use imp.load_module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 18:09:57 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Apr 2012 16:09:57 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1334592597.05.0.199517355143.issue14596@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The proposed patch uses a more compact encoding format of large structures. ---------- keywords: +patch Added file: http://bugs.python.org/file25242/struct_repeat.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 18:11:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Apr 2012 16:11:10 +0000 Subject: [issue14551] imp.load_source docs removed from python3 docs...is this correct? In-Reply-To: <1334592473.2.0.465411078087.issue14551@psf.upfronthosting.co.za> Message-ID: <1334592612.3426.5.camel@localhost.localdomain> Antoine Pitrou added the comment: > The one-liner is an adequate substitute, but feels like a step > backward for this particular use case. That is, load_source is a > *convenience* function, from my POV :) Agreed with David. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 18:18:54 2012 From: report at bugs.python.org (Eric Snow) Date: Mon, 16 Apr 2012 16:18:54 +0000 Subject: [issue14592] old-style (level=-1) importing broken after importlib changes In-Reply-To: <1334575981.92.0.820846886591.issue14592@psf.upfronthosting.co.za> Message-ID: <1334593134.27.0.444154639589.issue14592@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 18:20:03 2012 From: report at bugs.python.org (Eric Snow) Date: Mon, 16 Apr 2012 16:20:03 +0000 Subject: [issue14594] document imp.load_dynamic() In-Reply-To: <1334576684.12.0.825511182603.issue14594@psf.upfronthosting.co.za> Message-ID: <1334593203.31.0.454800773959.issue14594@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 18:30:53 2012 From: report at bugs.python.org (=?utf-8?q?Peter_H=C3=A4ring?=) Date: Mon, 16 Apr 2012 16:30:53 +0000 Subject: [issue14598] _cursesmodule.c fails with ncurses-5.9 on Linux Message-ID: <1334593853.62.0.710921461264.issue14598@psf.upfronthosting.co.za> New submission from Peter H?ring : I need to define NCURSES_INTERNALS in py_curses.h before ncurses.h is included, even on my Linux system with ncurses-5.9. See the same issue for cygwin: 14438 ---------- components: Extension Modules messages: 158481 nosy: phaering priority: normal severity: normal status: open title: _cursesmodule.c fails with ncurses-5.9 on Linux type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 18:38:39 2012 From: report at bugs.python.org (Pat Lynch) Date: Mon, 16 Apr 2012 16:38:39 +0000 Subject: [issue14597] Cannot unload dll in ctypes until script exits In-Reply-To: Message-ID: Pat Lynch added the comment: Just to update:- I've run this pretty extensively on multiple systems (XP x86 & Win7 64-bit) and it appears to behave as expected (haven't checked it on Linux). I have that code being called in 100s of unit tests. For python 3.1, would it make sense to add it as a ForceUnload function?? - for safety bail out if handle was not None when passed into the constructor? i.e. if somebody has accessed an independently loaded DLL, they will pass in the handle when constructing the CDLL object. Disallow ForceUnload in that case. ForceUnload will only be allowed in cases where we created that type by passing in the path to the DLL. I'll be using this code as a local patch, so no rush to put it into 3.1 etc. thanks for all the info - much appreciated :) Pat. On 16 April 2012 15:04, Pat Lynch wrote: > > Pat Lynch added the comment: > > ok, that's fair enough if most usage of ctypes is from people accessing > system libraries :) > > I wouldn't have thought my usage was that weird though (given the strength > of using python for unit testing). > > In local tests, adding a function CDLL::ForceUnloadDll (which just calls > FreeLibrary(self._handle)) seems to work well. I haven't done intensive > testing though at this point. I could be missing something though. > > thanks, > Pat. > > On 16 April 2012 14:45, Martin v. L?wis wrote: > > > > > Martin v. L?wis added the comment: > > > > In principle, it should be possible (but perhaps not desirable, see > below) > > to call FreeLibrary in a CDLL's __del__. However, since this would be a > new > > feature, it can't go into 2.7. Patches are welcome; make sure to support > > both FreeLIbrary and dlclose. > > > > There is a general issue with closing/freeing DLLs: if they are still > > referenced somewhere (e.g. in an atexit function, a C++ virtual method > > table, or on the call stack of another thread), then a later access to > the > > code will crash the interpreter. In a typical DLL today (including all > > Python extension modules), the likelihood of crashes is close to 100%. > For > > that reason, it's probably not a good idea to have ctypes auto-close > DLLs; > > instead, it should be an opt-in mechanism. > > > > For most ctypes uses, closing is irrelevant, since people typically > access > > system libraries that are independently loaded anyway, so closing them > > would not have any effect. > > > > ---------- > > nosy: +loewis > > > > _______________________________________ > > Python tracker > > > > _______________________________________ > > > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 18:46:46 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 16:46:46 +0000 Subject: [issue14597] Cannot unload dll in ctypes until script exits In-Reply-To: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za> Message-ID: <1334594806.85.0.209373953015.issue14597@psf.upfronthosting.co.za> R. David Murray added the comment: Current default will become 3.3. 3.1 has been out for a while :) Your thought sounds reasonable, though Martin may have further input. Would you are to propose a patch? Otherwise most like nothing will happen with this issue. 3.3 Beta is scheduled for mid-June, so that would be the deadline for new features. (PS: Could you please trim your replies when replying to tracker messages? The quoted text makes the tracker issue hard to read.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 18:52:58 2012 From: report at bugs.python.org (Roumen Petrov) Date: Mon, 16 Apr 2012 16:52:58 +0000 Subject: [issue14598] _cursesmodule.c fails with ncurses-5.9 on Linux In-Reply-To: <1334593853.62.0.710921461264.issue14598@psf.upfronthosting.co.za> Message-ID: <1334595178.34.0.256958882855.issue14598@psf.upfronthosting.co.za> Roumen Petrov added the comment: you could find how to resolve in last patch attached to issue 3754 ---------- nosy: +rpetrov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 18:59:04 2012 From: report at bugs.python.org (Roumen Petrov) Date: Mon, 16 Apr 2012 16:59:04 +0000 Subject: [issue14598] _cursesmodule.c fails with ncurses-5.9 on Linux In-Reply-To: <1334593853.62.0.710921461264.issue14598@psf.upfronthosting.co.za> Message-ID: <1334595544.44.0.660913403863.issue14598@psf.upfronthosting.co.za> Roumen Petrov added the comment: extracted as separate patch ---------- keywords: +patch Added file: http://bugs.python.org/file25243/0001-CROSS-properly-detect-WINDOW-_flags-for-different-nc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 19:13:52 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Apr 2012 17:13:52 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <4F8C3C46.4060605@v.loewis.de> Message-ID: <1334596572.17945.1223.camel@raxxla> Serhiy Storchaka added the comment: May be I did not correctly understand the problem, but I can assume, that this patch solves it. '????!\U00010000' ---------- keywords: +patch Added file: http://bugs.python.org/file25244/idle_escape_nonbmp.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 13307eb5bf47 Lib/idlelib/rpc.py --- a/Lib/idlelib/rpc.py Sat Apr 14 14:20:29 2012 -0500 +++ b/Lib/idlelib/rpc.py Mon Apr 16 20:08:12 2012 +0300 @@ -615,10 +615,8 @@ try: sys.stdout.write(text) except UnicodeEncodeError: - # let's use ascii while utf8-bmp codec doesn't present - encoding = 'ascii' - bytes = text.encode(encoding, 'backslashreplace') - text = bytes.decode(encoding, 'strict') + # escape non-BMP characters + text = ''.join(c if ord(c) <= 0xffff else '\\U%08x' % ord(c) for c in text) sys.stdout.write(text) sys.stdout.write("\n") builtins._ = value From report at bugs.python.org Mon Apr 16 19:32:22 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 16 Apr 2012 17:32:22 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1334597542.23.0.404640578745.issue14304@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, the mail daemon has eaten a piece of example. >>> '\u0410\u0433\u043e\u0432!\U00010000' '????!\U00010000' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 19:46:44 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Apr 2012 17:46:44 +0000 Subject: [issue14551] imp.load_source docs removed from python3 docs...is this correct? In-Reply-To: <1334168911.32.0.490760920072.issue14551@psf.upfronthosting.co.za> Message-ID: <1334598404.1.0.682189803944.issue14551@psf.upfronthosting.co.za> Brett Cannon added the comment: To help refine this, so you would expect all of the usual import stuff (e.g. sys.modules use, generating bytecode, etc.), you just want a short-circuit to the loading when you happen to already know the name and desired file path? Basically I want to kill off the file argument to imp.load_source() since it buys you nothing as import is no longer structured to work off of already opened files, and especially files opened to return text instead of bytes (the only reason load_*() even takes an open file is because it directly exposes stuff part way through import.c's import process). And as for having an already opened file, don't count on load_module() sticking around since find_module() is going to go since, once again, it is only structured the way it is with its poor API because of how import.c's C code was structured. Thinking about it a little, would importlib.util.SourceFileLoader(name, path).load_source() be an okay API for you? Or do you really want a function instead of a convenience method on a loader instance? I basically want to gut imp down to only stuff that is required for backwards-compatibility for for really low-level stuff that normal people never touch and have common stuff like load_source() be in importlib somewhere. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 19:50:54 2012 From: report at bugs.python.org (Eric Snow) Date: Mon, 16 Apr 2012 17:50:54 +0000 Subject: [issue14593] PyErr_SetFromImportErrorWithNameAndPath lacks error checking In-Reply-To: <1334576324.57.0.944762137092.issue14593@psf.upfronthosting.co.za> Message-ID: <1334598654.17.0.863898442533.issue14593@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 19:51:45 2012 From: report at bugs.python.org (Jim Jewett) Date: Mon, 16 Apr 2012 17:51:45 +0000 Subject: [issue14567] http.server query string handling is incorrect and inefficient In-Reply-To: <1334260387.16.0.632012029633.issue14567@psf.upfronthosting.co.za> Message-ID: <1334598705.31.0.597199889574.issue14567@psf.upfronthosting.co.za> Changes by Jim Jewett : ---------- title: http.server query string handling incorrect and inefficient -> http.server query string handling is incorrect and inefficient _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 19:52:21 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 17:52:21 +0000 Subject: [issue14599] Windows test_import failure Message-ID: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> New submission from R. David Murray : Not sure which revision triggered this, so opening a new bug: http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6381/steps/test/logs/stdio There's also a test_reprlib failure, no idea if it is related. ---------- keywords: buildbot messages: 158489 nosy: brett.cannon, pitrou, r.david.murray priority: normal severity: normal stage: needs patch status: open title: Windows test_import failure type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 20:10:49 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 18:10:49 +0000 Subject: [issue14551] imp.load_source docs removed from python3 docs...is this correct? In-Reply-To: <1334168911.32.0.490760920072.issue14551@psf.upfronthosting.co.za> Message-ID: <1334599849.02.0.985236124135.issue14551@psf.upfronthosting.co.za> R. David Murray added the comment: Well, if you want backward compatibility, you pretty much have to keep it as is, don't you? This is the only time I've used load_source, and it was used because we didn't want to bother mucking with the path but did want to load the module whose file system location we knew. SourceFileLoader(name, path).load_source() is OK, but it does not qualify as an obvious API for loading a module not on the path whose file system path one knows. I'm OK with there not being an obvious API for that as long as there *is* an API for it. To be clear: importlib.import_module(name) lets you load a module that *is* on the path, so it seems logical that there would be a corresponding function (load_file?) that would take a complete path and thereby allow you to load a module *not* on sys.path. But there is by no means a *requirement* for such a function in my mind, as long as it can be done somehow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 20:15:51 2012 From: report at bugs.python.org (Alex Leach) Date: Mon, 16 Apr 2012 18:15:51 +0000 Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za> Message-ID: <1334600151.92.0.326929527599.issue4130@psf.upfronthosting.co.za> Alex Leach added the comment: Thanks for the assurance. I found it strange because compilation only fails when building shared binaries. My static build of Python-2.7.3, with icc seems to work fine, except for this libffi issue. Turns out I needed dejagnu to run the tests in libffi's `make check`, which is why it passed before when it shouldn't have. I'll liaise with the libffi authors to try and come up with a working solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 20:42:51 2012 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 16 Apr 2012 18:42:51 +0000 Subject: [issue14592] old-style (level=-1) importing broken after importlib changes In-Reply-To: <1334575981.92.0.820846886591.issue14592@psf.upfronthosting.co.za> Message-ID: <1334601771.71.0.14731589232.issue14592@psf.upfronthosting.co.za> Stefan Behnel added the comment: It turns out that it wasn't all that hard to work around. Calling __import__ twice seems to do the trick. It's more overhead, but if people want speed, they can just be explicit about what kind of import they actually mean. So I wouldn't mind considering this an accidental left-over, and given that this behaviour has officially been removed for source code imports in 3.0 and taken out of documentation since then, it should be enough to consider its (partial) support in __import__ a bug and document it as being fixed in 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 21:20:30 2012 From: report at bugs.python.org (Jim Jewett) Date: Mon, 16 Apr 2012 19:20:30 +0000 Subject: [issue14580] imp.reload can fail for sub-modules In-Reply-To: <1334429743.69.0.840922249937.issue14580@psf.upfronthosting.co.za> Message-ID: <1334604030.03.0.200402786089.issue14580@psf.upfronthosting.co.za> Jim Jewett added the comment: (Note that the two patches are not cumulative; both would need to be applied.) ---------- nosy: +Jim.Jewett stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 21:48:15 2012 From: report at bugs.python.org (Guy Taylor) Date: Mon, 16 Apr 2012 19:48:15 +0000 Subject: [issue14586] TypeError: truncate() takes no keyword arguments In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za> Message-ID: <1334605695.74.0.787635944115.issue14586@psf.upfronthosting.co.za> Guy Taylor added the comment: @murray The thing I would be worried at in both supporting truncate(0) and truncate(size=0) would be truncate(0, size=1). This could throw an exception but causes the need for extra sanity checks and introduces ambiguity in the otherwise 'only one way to do something' Python style. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 22:01:57 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 16 Apr 2012 20:01:57 +0000 Subject: [issue14586] TypeError: truncate() takes no keyword arguments In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za> Message-ID: <1334606517.36.0.351603813773.issue14586@psf.upfronthosting.co.za> R. David Murray added the comment: I think you misunderstand the way that python arguments work. If you have a function so: def func(size=None): Then func(0) and func(size=0) are equivalent, and func(0, size=0) is a TypeError because you've provided two arguments instead of just one. The C code *can* emulate this, but often doesn't (it just accepts positional arguments instead). An issue was raised about changing most C functions to support the keyword syntax, but I believe it was decided that while in general doing so is good we'd only do it on a case by case basis as they came up. See issue 8706 for more details. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 22:03:02 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 16 Apr 2012 20:03:02 +0000 Subject: [issue13579] string.Formatter doesn't understand the a conversion specifier In-Reply-To: <1323587450.48.0.625379374057.issue13579@psf.upfronthosting.co.za> Message-ID: <1334606582.61.0.898376330624.issue13579@psf.upfronthosting.co.za> ?ric Araujo added the comment: To be exact, the specifier is "a", without "!" which is a delimiter. :) ---------- nosy: +eric.araujo title: string.Formatter doesn't understand the !a conversion specifier -> string.Formatter doesn't understand the a conversion specifier _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 22:16:31 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Apr 2012 20:16:31 +0000 Subject: [issue14087] multiprocessing.Condition.wait_for missing In-Reply-To: <1329922885.58.0.881756065062.issue14087@psf.upfronthosting.co.za> Message-ID: <1334607391.1.0.0396243758454.issue14087@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Charles-Fran?ois, will you take this one? :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 23:13:45 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Apr 2012 21:13:45 +0000 Subject: [issue14551] imp.load_source docs removed from python3 docs...is this correct? In-Reply-To: <1334168911.32.0.490760920072.issue14551@psf.upfronthosting.co.za> Message-ID: <1334610825.15.0.928567560303.issue14551@psf.upfronthosting.co.za> Brett Cannon added the comment: Well, I want backwards-compatibility *now*, not forever. And no, it is not an obvious API as you are asking for what loaders are supposed to do; load a module, which is why the one-liner I gave you works today. Finder simply find a loader that can load something that they are asked to discover. Loader then load something that they are told to load, whether it was found through a finder for sys.path or explicitly pointed at something. Another option is to have SourceFileLoader.load_module() take no argument since its constructor already has everything needed to load a module passed in which simplifies the API a little bit. But that would be a non-standard broadening of the loader API and I don't know if people will like that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 23:14:29 2012 From: report at bugs.python.org (Brian Curtin) Date: Mon, 16 Apr 2012 21:14:29 +0000 Subject: [issue14600] Change ImportError reference handling, naming Message-ID: <1334610869.36.0.563738930515.issue14600@psf.upfronthosting.co.za> New submission from Brian Curtin : Antoine mentioned in email that the reference handling should be changed, so here's a shot at it. I also condensed and renamed the convenience functions - I was paying too much attention to the surrounding conventions and made this harder than it had to be. ---------- assignee: brian.curtin files: ImportError_changes.diff keywords: patch messages: 158499 nosy: brian.curtin, pitrou priority: high severity: normal stage: patch review status: open title: Change ImportError reference handling, naming type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file25245/ImportError_changes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 23:15:43 2012 From: report at bugs.python.org (Gustavo Arzola) Date: Mon, 16 Apr 2012 21:15:43 +0000 Subject: [issue13476] Simple exclusion filter for unittest autodiscovery In-Reply-To: <1322186223.31.0.112270498917.issue13476@psf.upfronthosting.co.za> Message-ID: <1334610943.82.0.127829562806.issue13476@psf.upfronthosting.co.za> Gustavo Arzola added the comment: I use netatalk so that I can edit my projects on my laptop (Mac) but run them on my server (Linux). Netatalk creates all kinds of .AppleDouble sub-directories that contain files with the same names as the parents, but generally hold icon, desktop location, and other meta information. When unittest tries to load this files, it generates a ValueError. I like using "python setup.py tests" on my pyramid projects, but this always fails the moment I look at a directory through my laptop (which creates the .AppleDouble subdirectory). A -x flag would be more useful if I could specify it on the "python setup.py tests" command line or in a config file or in an environment variable. I'm sure there are other software products that create hidden subdirectories that may contain file names that might confuse unittest. So I think a general mechanism rather than a specific one is a better solution. Also, it would be really nice if unittest printed the full path name of the file it was trying to import before spitting out the error -- it took a _lot_ of hunting and googling in order to understand what was going on. ---------- nosy: +gustavoarzola versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 23:17:29 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Apr 2012 21:17:29 +0000 Subject: [issue14599] Windows test_import failure In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: <1334611049.26.0.321100463807.issue14599@psf.upfronthosting.co.za> Brett Cannon added the comment: Issue #14581 covers the .PY failure (still looking for input on that one). The path failure is from http://hg.python.org/cpython/rev/f341b99bb370 which Brian committed. The test_reprlib failure is because of a race condition where an importlib.invalidate_caches() call is needed. ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 23:18:44 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 16 Apr 2012 21:18:44 +0000 Subject: [issue14592] old-style (level=-1) importing broken after importlib changes In-Reply-To: <1334575981.92.0.820846886591.issue14592@psf.upfronthosting.co.za> Message-ID: <1334611124.42.0.336084599084.issue14592@psf.upfronthosting.co.za> Brett Cannon added the comment: Yeah, the fix is dead-simple, import with level=1 and if that fails import with level=0. I plan to cover this specific issue in the "What's New" for Python 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 23:20:31 2012 From: report at bugs.python.org (Brian Curtin) Date: Mon, 16 Apr 2012 21:20:31 +0000 Subject: [issue14599] Windows test_import failure In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: <1334611231.84.0.321254086233.issue14599@psf.upfronthosting.co.za> Brian Curtin added the comment: Not sure why test_extension_import_fail is failing - not seeing that here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 23:36:05 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 16 Apr 2012 21:36:05 +0000 Subject: [issue8212] A tp_dealloc of a subclassed class cannot resurrect an object In-Reply-To: <1269350912.78.0.210466349131.issue8212@psf.upfronthosting.co.za> Message-ID: <1334612165.74.0.699758963229.issue8212@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Incidentally, Looking at this, I noticed code such as: (textio.c) static int _textiowrapper_clear(textio *self) { if (self->ok && _PyIOBase_finalize((PyObject *) self) < 0) return -1; This shows something scary: During a GC run, it is possible to invoke the "close()" method on a textio object. This is dangerous, and probably not allowed at all. Returning -1 from a tp_clear() slot has no particular meaning, and the return value appears to be ignored by gcmodule.c (also, it won't ever ber resurrected through that pathway, since it is incref'd first: Py_INCREF(op); clear(op); Py_DECREF(op); ) See Issue 9141 for more info. IMHO, this is another case where objects must tell GC that they cannot be collected but instead must be placed in gc.garbage. This probably requires a defect of its own. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 23:39:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 16 Apr 2012 21:39:27 +0000 Subject: [issue8212] A tp_dealloc of a subclassed class cannot resurrect an object In-Reply-To: <1334612165.74.0.699758963229.issue8212@psf.upfronthosting.co.za> Message-ID: <1334612308.3426.13.camel@localhost.localdomain> Antoine Pitrou added the comment: > static int > _textiowrapper_clear(textio *self) > { > if (self->ok && _PyIOBase_finalize((PyObject *) self) < 0) > return -1; > > This shows something scary: During a GC run, it is possible to invoke > the "close()" method on a textio object. This is dangerous, and > probably not allowed at all. How is it scary? This is not worse than invoking a __del__ method. > Returning -1 from a tp_clear() slot has no particular meaning, and the > return value appears to be ignored by gcmodule.c I don't think this is a problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 23:41:06 2012 From: report at bugs.python.org (Jim Jewett) Date: Mon, 16 Apr 2012 21:41:06 +0000 Subject: [issue14601] PEP sources not available as documented Message-ID: <1334612466.63.0.59561167474.issue14601@psf.upfronthosting.co.za> New submission from Jim Jewett : PEP 12 states: """ To get the source this (or any) PEP, look at the top of the HTML page and click on the date & time on the "Last-Modified" line. It is a link to the source text in the Python repository. """ Unfortunately, the link actually goes to SVN, which only works for (older copies of) older PEPs. Following that link in a newer PEP returns a 404. http://www.python.org/dev/peps/pep-0418/ ==> http://svn.python.org/view/*checkout*/peps/trunk/pep-0418.txt ---------- assignee: docs at python components: Documentation messages: 158506 nosy: Jim.Jewett, docs at python priority: normal severity: normal status: open title: PEP sources not available as documented type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 23:56:04 2012 From: report at bugs.python.org (Guy Taylor) Date: Mon, 16 Apr 2012 21:56:04 +0000 Subject: [issue14586] TypeError: truncate() takes no keyword arguments In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za> Message-ID: <1334613364.86.0.938020977252.issue14586@psf.upfronthosting.co.za> Guy Taylor added the comment: Looking through cpython and trying to form a patch I found several differing interpretations of truncate: Lib/_pyio.py def truncate(self, pos=None): Modules/_io/fileio.c PyDoc_STRVAR(truncate_doc, "truncate([size: int]) ..."); A first semi-working patch is attached. This will allow: truncate() truncate(x) truncate(size=x) and fail on: truncate(x, size=x) truncate(x, size=y) Thoughts? ps. fileio_truncate is defined as (PyCFunctionWithKeywords)fileio_truncate, METH_VARARGS | METH_KEYWORDS but fails with "takes no keyword arguments". How do I fix this? ---------- keywords: +patch Added file: http://bugs.python.org/file25246/truncate.ver1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 16 23:59:43 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 16 Apr 2012 21:59:43 +0000 Subject: [issue8212] A tp_dealloc of a subclassed class cannot resurrect an object In-Reply-To: <1269350912.78.0.210466349131.issue8212@psf.upfronthosting.co.za> Message-ID: <1334613583.28.0.205766378539.issue8212@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: __del__ methods are never invoked from GC. All objects that have finalizers, and all objects reachable from them _must_ be put in gc.garbage. If I'm not mistaken, this is a fundamental rule of python's gc module and it is not because of the unknown order of finalizers as some people seem to think, but because the state of the interpreter during the collection phase is so fragile, with objects being linked up in various lists, and so on, that it isn't permissable to run any dynamic code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 00:04:34 2012 From: report at bugs.python.org (Guy Taylor) Date: Mon, 16 Apr 2012 22:04:34 +0000 Subject: [issue14586] TypeError: truncate() takes no keyword arguments In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za> Message-ID: <1334613874.51.0.471655960935.issue14586@psf.upfronthosting.co.za> Guy Taylor added the comment: Sorry had not refreshed the page to pick up the last comment. After reading more the cpython code I get what you are saying now. Not a fan of that syntax but consistency is best. This is my first time working with cpython directly, I have only worked on small python to c modules before so please say if I am barking up the wrong tree. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 00:05:52 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 16 Apr 2012 22:05:52 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1334613952.18.0.205398524758.issue9141@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: I've stumbled upon further cases of this problem, and a possible serious bug in python 3. the _PyIOBase_finalize() will invoke a "close" method on the object if the object isn't closed. This is the same as the object having a __del__ method. Yet, these objects are not treated as having finalizers by the garbage collector, and indeed, _PyIOBase_finalize() is called by the tp_clear() slot of several derived types. Surely, if these objects define non-trivial 'close' members, they must not be called during garbage collection. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 00:36:13 2012 From: report at bugs.python.org (Andrew Thompson) Date: Mon, 16 Apr 2012 22:36:13 +0000 Subject: [issue14602] OSX Build Target Message-ID: <1334615773.44.0.468426555931.issue14602@psf.upfronthosting.co.za> New submission from Andrew Thompson : I could not get Python3 to build on my OSX 10.6.8 box as per the instructions on the website (or those in the README). It "configures" , but does not "make" : IOError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.4" but "10.5" during configure make: *** [Include/Python-ast.h] Error 1 I can fix this by issuing export MACOSX_DEPLOYMENT_TARGET=10.6 EXTRA WRINKLE: It then configures and makes. But if I select a new terminal (i.e. without the exported env variable, and "make clean ; configure ; make" it continues to make perfectly. Not sure what is going on here. IMPORTANT: **** To replicate this bug I had to get a fresh mercurial clone **** Q: Is this the correct setting for the TARGET ? Q: Does this happen for other OSX users (specifically !=10.6 users) ? Q: Should this be documented to save grief for other newbie OSX devs ? Full Stack Dump of error : gcc -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Python/_warnings.o Python/_warnings.c ./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site.py", line 553, in main() File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site.py", line 535, in main known_paths = addusersitepackages(known_paths) File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site.py", line 268, in addusersitepackages user_site = getusersitepackages() File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site.py", line 243, in getusersitepackages user_base = getuserbase() # this will also set USER_BASE File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site.py", line 233, in getuserbase USER_BASE = get_config_var('userbase') File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/sysconfig.py", line 535, in get_config_var return get_config_vars().get(name) File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/sysconfig.py", line 434, in get_config_vars _init_posix(_CONFIG_VARS) File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/sysconfig.py", line 313, in _init_posix raise IOError(msg) IOError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.4" but "10.5" during configure make: *** [Include/Python-ast.h] Error 1 ---------- components: Build, Devguide messages: 158511 nosy: aft, ezio.melotti priority: normal severity: normal status: open title: OSX Build Target _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 00:39:16 2012 From: report at bugs.python.org (Andrew Thompson) Date: Mon, 16 Apr 2012 22:39:16 +0000 Subject: [issue14602] OSX Build Target In-Reply-To: <1334615773.44.0.468426555931.issue14602@psf.upfronthosting.co.za> Message-ID: <1334615956.91.0.524694384246.issue14602@psf.upfronthosting.co.za> Changes by Andrew Thompson : ---------- assignee: -> ronaldoussoren components: +Macintosh nosy: +ronaldoussoren type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 00:56:58 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 16 Apr 2012 22:56:58 +0000 Subject: [issue8212] A tp_dealloc of a subclassed class cannot resurrect an object In-Reply-To: <1269350912.78.0.210466349131.issue8212@psf.upfronthosting.co.za> Message-ID: <1334617018.14.0.145543672362.issue8212@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Here is a patch with the suggested change. I put _PyObject_ResurrectFromDealloc into typeobject.c since it seems more at home there than in object.c, but I'm not sure. Also note that other types, that were calling _PyIOBase_finalize() from their tp_dealloc slots (bufferedio, fileio) will now also get the correct behavior with the incref'd ob_type slot, if the object is resurrected. ---------- Added file: http://bugs.python.org/file25247/resurrect.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 00:58:43 2012 From: report at bugs.python.org (Georg Brandl) Date: Mon, 16 Apr 2012 22:58:43 +0000 Subject: [issue14586] TypeError: truncate() takes no keyword arguments In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za> Message-ID: <1334617123.53.0.80308519999.issue14586@psf.upfronthosting.co.za> Georg Brandl added the comment: The patch is wrong: PyArg_ParseTupleAndKeywords already handles the correct assignment of positional and keyword args, and raises exceptions accordingly. Did you test that code? The question is also: why only truncate()? There are several other fileio_* methods that take VARARGS only. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 01:47:12 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 16 Apr 2012 23:47:12 +0000 Subject: [issue14601] PEP sources not available as documented In-Reply-To: <1334612466.63.0.59561167474.issue14601@psf.upfronthosting.co.za> Message-ID: <1334620032.5.0.681253002687.issue14601@psf.upfronthosting.co.za> STINNER Victor added the comment: The templates have been fixed 1 year ago, when we moved from SVN to HG. I suppose that the bot has an old local copy of the template (Python scripts to compile reST to HTML). But who owns the robot? :-) ---------- nosy: +haypo, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 01:52:59 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 16 Apr 2012 23:52:59 +0000 Subject: [issue14601] PEP sources not available as documented In-Reply-To: <1334612466.63.0.59561167474.issue14601@psf.upfronthosting.co.za> Message-ID: <1334620379.09.0.0673994938863.issue14601@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 02:30:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 17 Apr 2012 00:30:19 +0000 Subject: [issue14600] Change ImportError reference handling, naming In-Reply-To: <1334610869.36.0.563738930515.issue14600@psf.upfronthosting.co.za> Message-ID: <1334622619.55.0.143039055515.issue14600@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looks good on the principle. Implementation is a bit weird: you don't need to check name and path for NULL-ness? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 02:30:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 17 Apr 2012 00:30:48 +0000 Subject: [issue14600] Change ImportError reference handling, naming In-Reply-To: <1334610869.36.0.563738930515.issue14600@psf.upfronthosting.co.za> Message-ID: <1334622648.6.0.198652865009.issue14600@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Oh, and is PyErr_SetExcWithArgsKwargs still useful? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 02:42:26 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 17 Apr 2012 00:42:26 +0000 Subject: [issue14583] try/except import fails --without-threads In-Reply-To: <1334436331.01.0.461185960127.issue14583@psf.upfronthosting.co.za> Message-ID: <1334623346.11.0.890752139622.issue14583@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 02:48:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Apr 2012 00:48:57 +0000 Subject: [issue14599] Windows test_import failure In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset eae7cc54d28b by Brett Cannon in branch 'default': Issue #14599: Make test_reprlib robust against import cache race http://hg.python.org/cpython/rev/eae7cc54d28b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 02:50:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Apr 2012 00:50:43 +0000 Subject: [issue14599] Windows test_import failure In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 00a07720a570 by Brett Cannon in branch 'default': Issue #14599: Fix an import caching race condition. http://hg.python.org/cpython/rev/00a07720a570 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 02:51:58 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 17 Apr 2012 00:51:58 +0000 Subject: [issue14599] Windows test_import failure In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: <1334623918.0.0.315345178864.issue14599@psf.upfronthosting.co.za> Brett Cannon added the comment: I think the failure is from a cache race condition. Hopefully the invalidate_caches() call will fix things. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 03:26:17 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 17 Apr 2012 01:26:17 +0000 Subject: [issue14602] OSX Build Target In-Reply-To: <1334615773.44.0.468426555931.issue14602@psf.upfronthosting.co.za> Message-ID: <1334625977.65.0.875164663987.issue14602@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Please understand that the bug tracker is not a place to ask questions; use python-list at python.org for that. To still answer your last question: newbie OSX developers are advised to prefer released versions of Python, as they will have build issues fixed that occur during development. In the specific case, a released version wouldn't even attempt to run asdl_c.py. What README did you read, and what web page? What specific build steps did you then perform to produce this error? What specific revision did you try to build? ISTM that the error doesn't originate from the Python you are trying to build, but from Apple's Python build, which apparently cannot work with MACOSX_DEPLOYMENT_TARGET being set. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 04:11:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Apr 2012 02:11:33 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 3b5b4b4bb43c by Brett Cannon in branch 'default': Issue #13959: Re-implement imp.load_source() in imp.py. http://hg.python.org/cpython/rev/3b5b4b4bb43c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 04:43:08 2012 From: report at bugs.python.org (Brian Curtin) Date: Tue, 17 Apr 2012 02:43:08 +0000 Subject: [issue14600] Change ImportError reference handling, naming In-Reply-To: <1334610869.36.0.563738930515.issue14600@psf.upfronthosting.co.za> Message-ID: <1334630588.54.0.529341654347.issue14600@psf.upfronthosting.co.za> Brian Curtin added the comment: How about this patch? Adds NULL checking and merges PyErr_SetExcWithArgsKwargs inside PyErr_SetImportError since it's not needed by itself. Docs are also updated in line with these changes. ---------- Added file: http://bugs.python.org/file25248/issue14600.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 05:18:02 2012 From: report at bugs.python.org (Dum Dum) Date: Tue, 17 Apr 2012 03:18:02 +0000 Subject: [issue14603] List comprehension in zipfile.namelist Message-ID: <1334632682.19.0.839389777617.issue14603@psf.upfronthosting.co.za> New submission from Dum Dum : Use list comprehension in namelist() method of zipfile module. ---------- components: Library (Lib) files: zipfile.patch keywords: patch messages: 158524 nosy: Dum.Dum priority: normal severity: normal status: open title: List comprehension in zipfile.namelist type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25249/zipfile.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 05:23:14 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 17 Apr 2012 03:23:14 +0000 Subject: [issue14602] OSX Build Target In-Reply-To: <1334615773.44.0.468426555931.issue14602@psf.upfronthosting.co.za> Message-ID: <1334632994.99.0.272005289764.issue14602@psf.upfronthosting.co.za> Ned Deily added the comment: The problem you are seeing is due to two separate issues. (1) The first time you build Python 3 in a particular build directory, the Abstract Syntax Definition Language (asdl) parser build step may be unnecessarily run by "make" if the time stamps of the source files are not preserved, for example, for an initial clone of a repo using hg. The parser step requires the use of an existing Python on your system. It appears you a Python 2.7 installed and first on the your shell $PATH. Unfortunately, that causes you to run into the second issue, which was documented in Issue9516, a bug in the initial releases of Python 2.7.x. The fix for that issue is now released in Python 2.7.3, so that the interpreter on OS X is no longer incorrectly checking MACOSX_DEPLOYMENT_TARGET settings. So, among other solutions, you can either update to Python 2.7.3 or remove it from your PATH during the initial build (until the asdl target is up-to-date). ---------- assignee: ronaldoussoren -> nosy: +ned.deily resolution: -> out of date status: open -> closed versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 05:25:22 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 17 Apr 2012 03:25:22 +0000 Subject: [issue14602] Python build fails on OS X with "$MACOSX_DEPLOYMENT_TARGET mismatch" In-Reply-To: <1334615773.44.0.468426555931.issue14602@psf.upfronthosting.co.za> Message-ID: <1334633122.29.0.621559644.issue14602@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- assignee: -> ronaldoussoren components: -Devguide stage: -> committed/rejected title: OSX Build Target -> Python build fails on OS X with "$MACOSX_DEPLOYMENT_TARGET mismatch" versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 05:34:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Apr 2012 03:34:50 +0000 Subject: [issue14603] List comprehension in zipfile.namelist In-Reply-To: <1334632682.19.0.839389777617.issue14603@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset cac63f6ad252 by Ezio Melotti in branch 'default': #14603: use a listcomp in ZipFile.namelist. http://hg.python.org/cpython/rev/cac63f6ad252 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 05:35:45 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 17 Apr 2012 03:35:45 +0000 Subject: [issue14603] List comprehension in zipfile.namelist In-Reply-To: <1334632682.19.0.839389777617.issue14603@psf.upfronthosting.co.za> Message-ID: <1334633745.82.0.0652229290627.issue14603@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- assignee: -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 06:29:17 2012 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 17 Apr 2012 04:29:17 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1334636957.16.0.733543725393.issue2771@psf.upfronthosting.co.za> Ezio Melotti added the comment: Testing links: http://bugs.python.org/issue2771 http://bugs.python.org/issue2771. http://bugs.python.org/issue2771, http://bugs.python.org/issue2771; http://bugs.python.org/issue2771: http://bugs.python.org/issue2771! (http://bugs.python.org/issue2771) [http://bugs.python.org/issue2771] {http://bugs.python.org/issue2771} ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 07:24:45 2012 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 17 Apr 2012 05:24:45 +0000 Subject: [issue14592] old-style (level=-1) importing broken after importlib changes In-Reply-To: <1334611124.42.0.336084599084.issue14592@psf.upfronthosting.co.za> Message-ID: <4F8CFE9C.4050903@users.sourceforge.net> Stefan Behnel added the comment: > Yeah, the fix is dead-simple, import with level=1 and if that fails import with level=0. With one caveat: relative imports don't work outside of packages, so the importing code has to know when it's in a package or not. Otherwise, the relative import would raise an exception (not an ImportError). Interesting enough, I now get this when trying it at the prompt: Traceback (most recent call last): File "", line 1, in SystemError: error return without exception set ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 07:31:57 2012 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 17 Apr 2012 05:31:57 +0000 Subject: [issue14592] old-style (level=-1) importing broken after importlib changes In-Reply-To: <1334575981.92.0.820846886591.issue14592@psf.upfronthosting.co.za> Message-ID: <1334640717.63.0.232012551403.issue14592@psf.upfronthosting.co.za> Stefan Behnel added the comment: Hmm, interesting - it stripped the command from my e-mail. I was doing this: >>> __import__("sys", level=1) Traceback (most recent call last): File "", line 1, in SystemError: error return without exception set ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 07:57:46 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 17 Apr 2012 05:57:46 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1334642266.01.0.237643565625.issue13959@psf.upfronthosting.co.za> Eric Snow added the comment: This is a mostly-working sketch of find_module() in imp.py. I've run out of time tonight, but wanted to get it up in case it's useful to anyone else (a.k.a Brett). If nobody's touched it before then, I'll finish it up tomorrow. ---------- Added file: http://bugs.python.org/file25250/imp_find_module.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 08:05:07 2012 From: report at bugs.python.org (Glenn Linderman) Date: Tue, 17 Apr 2012 06:05:07 +0000 Subject: [issue10486] http.server doesn't set all CGI environment variables In-Reply-To: <1290325295.78.0.545647251788.issue10486@psf.upfronthosting.co.za> Message-ID: <1334642707.9.0.200978022226.issue10486@psf.upfronthosting.co.za> Glenn Linderman added the comment: Reading the CGI 1.1 spec, it says: The QUERY_STRING value provides the query-string part of the Script-URI. (See section 3.3). The server MUST set this variable; if the Script-URI does not include a query component, the QUERY_STRING MUST be defined as an empty string (""). Therefore the code in run_cgi that says: if query: env['QUERY_STRING'] = query should have the conditional removed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 09:32:52 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 17 Apr 2012 07:32:52 +0000 Subject: [issue14087] multiprocessing.Condition.wait_for missing In-Reply-To: <1334607391.1.0.0396243758454.issue14087@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Charles-Fran?ois, will you take this one? :) Yes :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 10:22:48 2012 From: report at bugs.python.org (clikkeb) Date: Tue, 17 Apr 2012 08:22:48 +0000 Subject: [issue14576] IDLE cannot connect to subprocess - New solution In-Reply-To: <1334400065.92.0.605072928338.issue14576@psf.upfronthosting.co.za> Message-ID: <1334650968.66.0.356919119236.issue14576@psf.upfronthosting.co.za> clikkeb added the comment: It is one of the possible solutions. In combination with the "writable flag" solution, you might create a class variable in IdleConf (e.g. "user_cfg") that contains the user's home directory; such variable will be initialized to an empty string by IdleConf.__init__. On each call, GetUserCfgDir tries to initialize "user_cfg" only if it is an empty string, otherwise it returns it's content. Anyway, keep in mind that in GetUserConfig there's an unhandled exception (AttributeError) that might be the cause of the "IDLE doesn't start..." issue reported by users. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 11:40:31 2012 From: report at bugs.python.org (Guy Taylor) Date: Tue, 17 Apr 2012 09:40:31 +0000 Subject: [issue14586] TypeError: truncate() takes no keyword arguments In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za> Message-ID: <1334655631.53.0.204372348534.issue14586@psf.upfronthosting.co.za> Guy Taylor added the comment: @Brandl truncate() was the issue I ran into, no other reason. I have started on the rest of the IO module tho. I know the patch is not working but I ran into problems with getting cpython to change functions from positional to keyword. @all cpython | Python | Status -----------------------+-------------------------------+------- iobase_readlines | readline(limit=-1) | patch v2 iobase_readline | readlines(hint=-1) | patch v2 iobase_seek | seek(offset, whence=SEEK_SET) | patch v2 iobase_truncate | truncate(size=None) | patch v2 fileio_seek | seek(offset, whence=SEEK_SET) | patch v2 fileio_read | read(n=-1) | patch v2 textiowrapper_read | read(n=-1) | ToDo textiowrapper_readline | readline(limit=-1) | ToDo textiowrapper_seek | seek(offset, whence=SEEK_SET) | ToDo textiowrapper_truncate | truncate(size=None) | ToDo textiobase_read | read(n=-1) | ToDo textiobase_readline | readline(limit=-1) | ToDo {bufferedio.c} | | ToDo {bytesio.c} | | ToDo {stringio.c} | | ToDo ps. I am using code from within other C files and http://docs.python.org/dev/extending/extending.html#keyword-parameters-for-extension-functions to base my patch on but I still get "x()" takes no keyword arguments". What have I missed/Are the docs correct? ---------- Added file: http://bugs.python.org/file25251/truncate.ver2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 12:21:55 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 17 Apr 2012 10:21:55 +0000 Subject: [issue14600] Change ImportError reference handling, naming In-Reply-To: <1334610869.36.0.563738930515.issue14600@psf.upfronthosting.co.za> Message-ID: <1334658115.33.0.914847191989.issue14600@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You probably want to check args and kwargs for NULL-ness too. Otherwise, looks good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 12:28:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 17 Apr 2012 10:28:54 +0000 Subject: [issue14593] PyErr_SetFromImportErrorWithNameAndPath lacks error checking In-Reply-To: <1334576324.57.0.944762137092.issue14593@psf.upfronthosting.co.za> Message-ID: <1334658534.19.0.624678882812.issue14593@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> duplicate status: open -> closed superseder: -> Change ImportError reference handling, naming _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 12:33:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 17 Apr 2012 10:33:13 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1334658793.36.0.990463551611.issue9141@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Surely, if these objects define non-trivial 'close' members, they must > not be called during garbage collection. Define "non-trivial". There are various tests for it in test_io. Not ending up in gc.garbage is *by design*. Making file objects uncollectable as soon as they appear in a reference cycle would be a serious regression. That's why the cleanup is done in tp_dealloc instead of having a __del__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 12:38:00 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 17 Apr 2012 10:38:00 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1334659080.54.0.88058540041.issue9141@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: I _think_ the only python related things you can do from tp_clear() is Py_DECREF(), this is what I mean by trivial. This is the reason, for example, that special care was done with generators. An IO object could of course do non-python operations such as closing files and freeing buffers. If file.close() can be an arbitrary python method, then it can no more be called from gc, than an object's __del__ method. This would not be a regression, this would be a fact of life. The point of _this_ defect (issue 9141) is to allow objects to be smarter about this, being able to tell gc if their finalizers are trivial or not. I will start a discussion on python-dev to see if anyone knows exactly why these limitations are in place, and what they are. They are not documented in the source code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 12:41:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 17 Apr 2012 10:41:08 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1334592136.72.0.358461405189.issue11750@psf.upfronthosting.co.za> Message-ID: <1334659208.3338.2.camel@localhost.localdomain> Antoine Pitrou added the comment: > sbt added the comment: > > s/_win32/_winapi/g Overlapped's naming is still lagging behind :-) Other than that, a comment: + def Close(self): + if not self.closed: + self.closed = True + _winapi.CloseHandle(self) Since Close() can be called at shutdown (through __del__), it should probably cache its references to globals (because of the unpredictable order of module cleanup), like this: + def Close(self, CloseHandle=_winapi.CloseHandle): + if not self.closed: + self.closed = True + CloseHandle(self) Otherwise, looks good (I haven't tested). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 12:48:31 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 17 Apr 2012 10:48:31 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1334659080.54.0.88058540041.issue9141@psf.upfronthosting.co.za> Message-ID: <1334659650.3338.9.camel@localhost.localdomain> Antoine Pitrou added the comment: > I _think_ the only python related things you can do from tp_clear() is > Py_DECREF(), this is what I mean by trivial. Well, Py_DECREF is not trivial at all, since it can invoke arbitrary Python code (through e.g. weakref callbacks, or by releasing the GIL). Therefore, I would say any code is allowed from tp_clear :-) > If file.close() can be an arbitrary python method, then it can no more > be called from gc, than an object's __del__ method. This would not be > a regression, this would be a fact of life. I don't believe it. I don't see what's magical about being called by the gc. Again, a Py_DECREF in tp_dealloc can invoke arbitrary Python code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 12:51:56 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 17 Apr 2012 10:51:56 +0000 Subject: [issue14551] imp.load_source docs removed from python3 docs...is this correct? In-Reply-To: <1334610825.15.0.928567560303.issue14551@psf.upfronthosting.co.za> Message-ID: <1334659856.3338.12.camel@localhost.localdomain> Antoine Pitrou added the comment: > Well, I want backwards-compatibility *now*, not forever. I don't think changing a function signature in an incompatible way is generally acceptable. You might make one of the arguments optional, though (but keeping the current semantics when the argument *is* passed). If it's not possible, you can add another function with the intended behaviour. The importlib bootstrapping has already had some (unavoidable) disruptive consequences. Let's keep them to a minimum. People *rely* on our APIs, even the less popular ones. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 12:58:03 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 17 Apr 2012 10:58:03 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za> Message-ID: <1334660283.07.0.773951515617.issue9141@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: >I don't believe it. I don't see what's magical about being called by the >gc. Again, a Py_DECREF in tp_dealloc can invoke arbitrary Python code. Look again. gcmodule specifically takes any objects reachable from ob_clear and sees if any of them have side effects when Py_DECREF'd. If any object has a finalizer, the entire cycle is put in gc.garbage. gcmodule is trickier than you might think. I've spent quite a time with it. Anyway, I've put the issue to python-dev, let's see if they have some autorative insight on the matter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 13:08:39 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 17 Apr 2012 11:08:39 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1334660283.07.0.773951515617.issue9141@psf.upfronthosting.co.za> Message-ID: <1334660859.3338.14.camel@localhost.localdomain> Antoine Pitrou added the comment: > Look again. gcmodule specifically takes any objects reachable from > ob_clear and sees if any of them have side effects when Py_DECREF'd. has_finalizer() in gcmodule.c doesn't check for weakref callbacks, so a weakref callback can still be invoked from tp_dealloc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 13:16:22 2012 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 17 Apr 2012 11:16:22 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1331932171.45.0.56771909125.issue14339@psf.upfronthosting.co.za> Message-ID: <1334661382.23.0.374064562909.issue14339@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 13:18:26 2012 From: report at bugs.python.org (Matthias Klose) Date: Tue, 17 Apr 2012 11:18:26 +0000 Subject: [issue12081] Remove distributed copy of libffi In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za> Message-ID: <1334661506.9.0.930186365793.issue12081@psf.upfronthosting.co.za> Matthias Klose added the comment: The last time I merged libffi, we were not able to build the MacOS X and Windows libffi from the upstream sources, but used the internal copy of the copy. Now that libffi 3.0.11 is released, we could - update to this new version, see if the MacOS X and Windows builds work (there are upstream related changes) - start defaulting to the system libffi for at least some targets (e.g. linux), for which we know that almost nobody will use the internal copy No, I don't volunteer to maintain ctypes itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 13:55:30 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Apr 2012 11:55:30 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334663730.64.0.66109856995.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: FreeBSD doesn't provide CLOCK_PROCESS_CPUTIME_ID, but CLOCK_PROF. CLOCK_PROF can be used instead of getrusage(), its precision can be read using clock_getres(). Something like "> #if defined(CLOCK_PROF) && defined(__FreeBSD__)" can be used. (By the way, "#if defined(__linux__)" may be enough) I read somewhere than CLOCK_PROF is the user+system CPU time of the *current thread* on OpenBSD. I can be checked by the following unit test: def test_process_time_threads(self): class BusyThread(threading.Thread): def run(self): timeout = monotonic() + 1.0 loops = 1 while monotonic() < timeout: i = 0 while i < loops: i += 1 loops *= 2 t1 = process_time() thread = BusyThread() thread.start() thread.join() t2 = process_time() self.assertGreater(t2 - t1, 0.9) -- perf_counter() should remember if win32_perf_counter() failed or not, as the pseudo-code of the PEP. I prefer to leave clock() unchanged to keep backward compatibility. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 13:58:52 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 17 Apr 2012 11:58:52 +0000 Subject: [issue14604] spurious stat() calls in importlib Message-ID: <1334663931.89.0.459058246046.issue14604@psf.upfronthosting.co.za> New submission from Antoine Pitrou : It seems importlib does multiple stat() calls on py files: stat("/home/antoine/cpython/opt/Lib", {st_mode=S_IFDIR|0775, st_size=12288, ...}) = 0 stat("/home/antoine/cpython/opt/Lib/_sysconfigdata.py", {st_mode=S_IFREG|0664, st_size=16032, ...}) = 0 stat("/home/antoine/cpython/opt/Lib/_sysconfigdata.py", {st_mode=S_IFREG|0664, st_size=16032, ...}) = 0 open("/home/antoine/cpython/opt/Lib/__pycache__/_sysconfigdata.cpython-33.pyc", O_RDONLY) = 3 It also does multiple stat() calls on some directories: stat("/home/antoine/cpython/opt/build/lib.linux-x86_64-3.3", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 stat("/home/antoine/.local/lib/python3.3/site-packages", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 stat("/home/antoine/.local/lib/python3.3/site-packages", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 stat("/home/antoine/.local/lib/python3.3/site-packages", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 open("/home/antoine/.local/lib/python3.3/site-packages", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 That said, the number of system calls issued by 3.3 at startup is now much lower than with 3.2: $ strace ./python -Sc pass 2>&1 | wc -l 512 $ strace python3.2 -Sc pass 2>&1 | wc -l 1018 ---------- components: Library (Lib) messages: 158546 nosy: brett.cannon, neologix, pitrou priority: low severity: normal status: open title: spurious stat() calls in importlib type: performance versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 14:13:31 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 17 Apr 2012 12:13:31 +0000 Subject: [issue14586] TypeError: truncate() takes no keyword arguments In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za> Message-ID: <1334664811.63.0.958330188955.issue14586@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, I'm glad someone else chimed in. I was going to say that I was pretty sure we had a macro for doing this, but I don't do much C level coding so I didn't have a reference handy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 14:14:04 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 17 Apr 2012 12:14:04 +0000 Subject: [issue14586] TypeError: truncate() takes no keyword arguments In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za> Message-ID: <1334664844.71.0.831273350855.issue14586@psf.upfronthosting.co.za> R. David Murray added the comment: macro, function...something automated, anyway :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 15:20:05 2012 From: report at bugs.python.org (sbt) Date: Tue, 17 Apr 2012 13:20:05 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: <1334668805.45.0.196222877845.issue11750@psf.upfronthosting.co.za> sbt added the comment: > Overlapped's naming is still lagging behind :-) Argh. And a string in winapi_module too. Yet another patch. ---------- Added file: http://bugs.python.org/file25252/winapi_module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 15:56:32 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 17 Apr 2012 13:56:32 +0000 Subject: [issue9762] PEP 3149 related build failures In-Reply-To: <1283542817.2.0.95523590272.issue9762@psf.upfronthosting.co.za> Message-ID: <1334670992.41.0.322215653787.issue9762@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Hi Barry, I stumbled upon this bug when trying to compile Python2.6 from source on Ubuntu 11.10. If this bug report or the related one issue11715 is a problem due to Ubuntu changes, I think, it is good inform in the download or news page. People try previous stable versions just to ensure that things are working fine. In this case, 2.7.x series work but 2.6.xx do not (I am not sure from which xx it started breaking). Thanks, Senthil ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 16:55:39 2012 From: report at bugs.python.org (luzakiru) Date: Tue, 17 Apr 2012 14:55:39 +0000 Subject: [issue13684] httplib tunnel infinite loop In-Reply-To: <1325260587.05.0.642107056326.issue13684@psf.upfronthosting.co.za> Message-ID: <1334674539.3.0.541855094542.issue13684@psf.upfronthosting.co.za> luzakiru added the comment: Although perhaps not optimal, the patch is consistent with the rest of the code and fixes the reasonably severe issue. Could this patch be applied in lieu of a better one that can come later? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 17:24:32 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 17 Apr 2012 15:24:32 +0000 Subject: [issue14604] spurious stat() calls in importlib In-Reply-To: <1334663931.89.0.459058246046.issue14604@psf.upfronthosting.co.za> Message-ID: <1334676272.21.0.250051110827.issue14604@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 17:58:05 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 17 Apr 2012 15:58:05 +0000 Subject: [issue14605] Make import machinery explicit Message-ID: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> New submission from Brett Cannon : There should no longer be any implicit part of import when there doesn't have to be. To make import fully explicit, some things need to happen (in context to importlib): * Expose FileLoader * Expose SourceFileLoader * Expose PathFinder * Expose the extension loader * Expose the default path hook * Explicitly set sys.meta_path with PathFinder * Explicitly set sys.path_hooks with the default path hook and zipimport * Make sys.path_importer_cache view None as no finder discovered * Insert None into sys.path_importer_cache instead of NullImporter I am not exposing SourcelessFileLoader because importlib publicly tries to discourage the shipping of .pyc files w/o their corresponding source files. Otherwise all objects as used by importlib for performing imports will become public. ---------- assignee: brett.cannon components: Interpreter Core messages: 158552 nosy: brett.cannon priority: release blocker severity: normal status: open title: Make import machinery explicit type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 18:03:25 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 17 Apr 2012 16:03:25 +0000 Subject: [issue14592] old-style (level=-1) importing broken after importlib changes In-Reply-To: <1334575981.92.0.820846886591.issue14592@psf.upfronthosting.co.za> Message-ID: <1334678605.39.0.278994652324.issue14592@psf.upfronthosting.co.za> Brett Cannon added the comment: Detecting if you are in a package is as simple as ``'.' in __name__ or hasattr(mod, '__path__')`` or alternatively for the last guard, ``__name__ == __package__``. As for the failure, I will have a look. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 18:03:53 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 17 Apr 2012 16:03:53 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1334678633.7.0.881854582209.issue14605@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 18:07:15 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 17 Apr 2012 16:07:15 +0000 Subject: [issue14551] imp.load_source docs removed from python3 docs...is this correct? In-Reply-To: <1334659856.3338.12.camel@localhost.localdomain> Message-ID: Brett Cannon added the comment: On Tue, Apr 17, 2012 at 06:51, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > > Well, I want backwards-compatibility *now*, not forever. > > I don't think changing a function signature in an incompatible way is > generally acceptable. I don't think it is either. > You might make one of the arguments optional, > though (but keeping the current semantics when the argument *is* > passed). If it's not possible, you can add another function with the > intended behaviour. > Right, which is why I'm thinking that I could make the module name argument optional for load_module() to avoid repeating yourself since that information is passed to the constructor. > > The importlib bootstrapping has already had some (unavoidable) > disruptive consequences. Let's keep them to a minimum. People *rely* on > our APIs, even the less popular ones. Which is unfortunate when the API is bad. Anyway, the deprecation can be a long one, but I don't want people having to look in two places for import-related stuff like urllib/urllib2 caused for URLs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 18:08:19 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 17 Apr 2012 16:08:19 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1334678899.62.0.141220255426.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: I doubt I will beat you to it, Eric, but I did want to say that your overall design was what I had in my head when I was thinking about how to re-implement the function, so keep at it! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 18:16:30 2012 From: report at bugs.python.org (Micah Friesen) Date: Tue, 17 Apr 2012 16:16:30 +0000 Subject: [issue1615] descriptor protocol bug In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za> Message-ID: <1334679390.83.0.779447817516.issue1615@psf.upfronthosting.co.za> Micah Friesen added the comment: I ran into this recently, as well, and have lost probably a day's worth of time debugging it. I submit that this is not a feature - I can't imagine a real-world scenario where you actually want to write debuggable code where a descriptor defers to __getattr__ (except perhaps for exception handling, in which case some re-factoring is in order), particularly because descriptors are effectively mix-ins and can be used on multiple classes. I worked around this by writing an ancestor descriptor that catches AttributeErrors and re-raises them as a user-defined exception. ---------- nosy: +Micah.Friesen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 18:46:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Apr 2012 16:46:50 +0000 Subject: [issue14087] multiprocessing.Condition.wait_for missing In-Reply-To: <1329922885.58.0.881756065062.issue14087@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 5606ee052783 by Charles-Fran?ois Natali in branch 'default': Issue #14087: multiprocessing: add Condition.wait_for(). Patch by sbt. http://hg.python.org/cpython/rev/5606ee052783 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 18:50:21 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 17 Apr 2012 16:50:21 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334681421.57.0.619553617371.issue14428@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Victor, can you let us know when you think the patch is ready for review? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 19:12:08 2012 From: report at bugs.python.org (Florent Xicluna) Date: Tue, 17 Apr 2012 17:12:08 +0000 Subject: [issue4600] __class__ assignment: new-style? heap? == confusing In-Reply-To: <1228771522.72.0.688992536212.issue4600@psf.upfronthosting.co.za> Message-ID: <1334682728.39.0.266626216098.issue4600@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 19:30:16 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 17 Apr 2012 17:30:16 +0000 Subject: [issue14087] multiprocessing.Condition.wait_for missing In-Reply-To: <1329922885.58.0.881756065062.issue14087@psf.upfronthosting.co.za> Message-ID: <1334683816.34.0.731001164685.issue14087@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Committed. Thanks for the patch, and sorry for the delay! ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 19:47:48 2012 From: report at bugs.python.org (Daniel Stutzbach) Date: Tue, 17 Apr 2012 17:47:48 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: <1334660859.3338.14.camel@localhost.localdomain> Message-ID: Daniel Stutzbach added the comment: On Tue, Apr 17, 2012 at 4:08 AM, Antoine Pitrou wrote: > has_finalizer() in gcmodule.c doesn't check for weakref callbacks, so a > weakref callback can still be invoked from tp_dealloc. Unless I'm mistaken, weakrefs will be handled and removed by handle_weakrefs() before delete_garbage() is called. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 19:56:40 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 17 Apr 2012 17:56:40 +0000 Subject: [issue14371] Add support for bzip2 compression to the zipfile module In-Reply-To: <1332243041.43.0.499117498297.issue14371@psf.upfronthosting.co.za> Message-ID: <1334685400.69.0.847023943355.issue14371@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 19:58:16 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 17 Apr 2012 17:58:16 +0000 Subject: [issue9141] Allow objects to decide if they can be collected by GC In-Reply-To: Message-ID: <1334685435.3418.3.camel@localhost.localdomain> Antoine Pitrou added the comment: > On Tue, Apr 17, 2012 at 4:08 AM, Antoine Pitrou wrote: > > has_finalizer() in gcmodule.c doesn't check for weakref callbacks, so a > > weakref callback can still be invoked from tp_dealloc. > > Unless I'm mistaken, weakrefs will be handled and removed by > handle_weakrefs() before delete_garbage() is called. Perhaps, but what does that change? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 19:59:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Apr 2012 17:59:31 +0000 Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 8a4c9a168d09 by Charles-Fran?ois Natali in branch '2.7': Issue #5113: Fix a test_posix failure on HP-UX, where non-root users can http://hg.python.org/cpython/rev/8a4c9a168d09 New changeset 428bece48029 by Charles-Fran?ois Natali in branch '3.2': Issue #5113: Fix a test_posix failure on HP-UX, where non-root users can http://hg.python.org/cpython/rev/428bece48029 New changeset 3d4922cf0d65 by Charles-Fran?ois Natali in branch 'default': Issue #5113: Fix a test_posix failure on HP-UX, where non-root users can http://hg.python.org/cpython/rev/3d4922cf0d65 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 20:03:16 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 17 Apr 2012 18:03:16 +0000 Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za> Message-ID: <1334685796.11.0.956495315413.issue5113@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Committed, thanks. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 20:19:15 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 17 Apr 2012 18:19:15 +0000 Subject: [issue14371] Add support for bzip2 compression to the zipfile module In-Reply-To: <1332243041.43.0.499117498297.issue14371@psf.upfronthosting.co.za> Message-ID: <1334686755.61.0.934292222098.issue14371@psf.upfronthosting.co.za> Martin v. L?wis added the comment: What's the status of your contrib form? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 20:56:02 2012 From: report at bugs.python.org (Roland) Date: Tue, 17 Apr 2012 18:56:02 +0000 Subject: [issue14606] Memory leak subprocess Message-ID: <1334688962.0.0.912468236102.issue14606@psf.upfronthosting.co.za> Changes by Roland : ---------- nosy: rfs priority: normal severity: normal status: open title: Memory leak subprocess type: resource usage versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 20:59:41 2012 From: report at bugs.python.org (Roland) Date: Tue, 17 Apr 2012 18:59:41 +0000 Subject: [issue14606] Memory leak subprocess Message-ID: <1334689181.81.0.435135933783.issue14606@psf.upfronthosting.co.za> New submission from Roland : subprocess leaks memory on win 7 64bit (Python 2.7.3 32bit). The following code snippet will fill up memory slowly but completely after running it multiple times. When python exits the memory is not freed. >>>>>>>>>> import subprocess import shlex for i in range(0, 10000): p = subprocess.Popen(shlex.split("ipconfig", posix=False)) result = p.communicate() print "end" <<<<<<<<<< ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 21:15:43 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 17 Apr 2012 19:15:43 +0000 Subject: [issue9762] Multiarch related build failures on Ubuntu >= 11.04 In-Reply-To: <1283542817.2.0.95523590272.issue9762@psf.upfronthosting.co.za> Message-ID: <1334690143.09.0.21429175306.issue9762@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- title: PEP 3149 related build failures -> Multiarch related build failures on Ubuntu >= 11.04 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 21:16:45 2012 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 17 Apr 2012 19:16:45 +0000 Subject: [issue9762] PEP 3149 related build failures In-Reply-To: <1334670992.41.0.322215653787.issue9762@psf.upfronthosting.co.za> Message-ID: <20120417151637.1f6610df@limelight.wooz.org> Barry A. Warsaw added the comment: On Apr 17, 2012, at 01:56 PM, Senthil Kumaran wrote: >I stumbled upon this bug when trying to compile Python2.6 from source on >Ubuntu 11.10. If this bug report or the related one issue11715 is a problem >due to Ubuntu changes, I think, it is good inform in the download or news >page. People try previous stable versions just to ensure that things are >working fine. In this case, 2.7.x series work but 2.6.xx do not (I am not >sure from which xx it started breaking). Hi Senthil. I added a note to the 2.6.8 download page and will carry this forward to future point releases should there be any. I also updated the title for this issue to better reflect the actual problem. ---------- title: Multiarch related build failures on Ubuntu >= 11.04 -> PEP 3149 related build failures _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 22:17:47 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 17 Apr 2012 20:17:47 +0000 Subject: [issue14548] garbage collection just after multiprocessing's fork causes exceptions In-Reply-To: <1334161952.16.0.996503370024.issue14548@psf.upfronthosting.co.za> Message-ID: <1334693867.85.0.404099833279.issue14548@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: > Alternative patch which records pid when Finalize object is created. Looks good to me. Note that it could eventually be rewritten to use an atfork() module, when we finally merge your patch for this other issue :-) ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 23:28:16 2012 From: report at bugs.python.org (Florent Xicluna) Date: Tue, 17 Apr 2012 21:28:16 +0000 Subject: [issue14607] method with special keyword-only argument gives error Message-ID: <1334698096.33.0.253940616413.issue14607@psf.upfronthosting.co.za> New submission from Florent Xicluna : This is probably a bug. >>> class A: ... def f(self, __a=42): ... pass ... >>> A().f() >>> class A: ... def f(self, *, __a=42): ... pass ... >>> A().f() Traceback (most recent call last): File "", line 1, in TypeError: f() needs keyword-only argument _A__a ---------- components: Interpreter Core messages: 158568 nosy: flox priority: normal severity: normal status: open title: method with special keyword-only argument gives error type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 23:31:27 2012 From: report at bugs.python.org (Eduard) Date: Tue, 17 Apr 2012 21:31:27 +0000 Subject: [issue14608] Python 2.7.3 x86 msi - msvcr90.dll version mismatch Message-ID: <1334698287.56.0.0123105112026.issue14608@psf.upfronthosting.co.za> New submission from Eduard : After installing Python 2.7.3, inside the Python folder I have version 9.0.30729.1 of msvcr90.dll, but it seems that the embeded redistributable package contains the 9.0.21022.8 version of msvcm90.dll, msvcp90.dll, and msvcr90.dll Is this the intended behavior? ---------- components: Installation messages: 158569 nosy: alexandrul priority: normal severity: normal status: open title: Python 2.7.3 x86 msi - msvcr90.dll version mismatch type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 23:34:26 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Apr 2012 21:34:26 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334698466.11.0.311355792511.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- hgrepos: +118 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 23:36:48 2012 From: report at bugs.python.org (Florent Xicluna) Date: Tue, 17 Apr 2012 21:36:48 +0000 Subject: [issue14608] Python 2.7.3 x86 msi - msvcr90.dll version mismatch In-Reply-To: <1334698287.56.0.0123105112026.issue14608@psf.upfronthosting.co.za> Message-ID: <1334698608.65.0.832336452497.issue14608@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- components: +Windows nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 17 23:57:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Apr 2012 21:57:31 +0000 Subject: [issue14600] Change ImportError reference handling, naming In-Reply-To: <1334610869.36.0.563738930515.issue14600@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 7a32b9380ffd by Brian Curtin in branch 'default': Fix #14600. Correct reference handling and naming of ImportError convenience function http://hg.python.org/cpython/rev/7a32b9380ffd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 00:04:04 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 17 Apr 2012 22:04:04 +0000 Subject: [issue14592] old-style (level=-1) importing broken after importlib changes In-Reply-To: <1334575981.92.0.820846886591.issue14592@psf.upfronthosting.co.za> Message-ID: <1334700244.84.0.243021757286.issue14592@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:05:21 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Apr 2012 23:05:21 +0000 Subject: [issue14592] old-style (level=-1) importing broken after importlib changes In-Reply-To: <1334575981.92.0.820846886591.issue14592@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 68f9ad6a3b13 by Brett Cannon in branch 'default': Issue #14592: A relative import will raise a KeyError if __package__ http://hg.python.org/cpython/rev/68f9ad6a3b13 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:06:00 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 17 Apr 2012 23:06:00 +0000 Subject: [issue14592] old-style (level=-1) importing broken after importlib changes In-Reply-To: <1334575981.92.0.820846886591.issue14592@psf.upfronthosting.co.za> Message-ID: <1334703960.49.0.50275532673.issue14592@psf.upfronthosting.co.za> Brett Cannon added the comment: SystemError fixed (stemming from a misunderstanding of what PyDict_GetItemWithError() did). ---------- assignee: -> brett.cannon resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:06:22 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 17 Apr 2012 23:06:22 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1334703982.93.0.810867281782.issue2377@psf.upfronthosting.co.za> Brett Cannon added the comment: Note: __import__('sys', level=1) no longer works; raises KeyError instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:06:25 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 17 Apr 2012 23:06:25 +0000 Subject: [issue14608] Python 2.7.3 x86 msi - msvcr90.dll version mismatch In-Reply-To: <1334698287.56.0.0123105112026.issue14608@psf.upfronthosting.co.za> Message-ID: <1334703985.19.0.641839687745.issue14608@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It's not explicitly intended, but a side effect of how Microsoft distributes patches. The redistributable package comes from %ProgramFiles%\Common Files\Merge Modules, whereas the separate copy comes from %VS90COMNTOOLS%\..\..\VC\redist. Apparently, the Windows Update process updated one and not the other. Apparently, an update to the merge modules is included in http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11895 I'll see whether this actually does update the merge modules. In general, while not being intended, this version difference is expected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:14:33 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Apr 2012 23:14:33 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 66bd85bcf916 by Brett Cannon in branch 'default': Issue #13959: Re-implement imp.load_compiled() in imp.py. http://hg.python.org/cpython/rev/66bd85bcf916 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:17:20 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Apr 2012 23:17:20 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334704640.33.0.843061827035.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file25253/aac59a3c11ef.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:18:16 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 17 Apr 2012 23:18:16 +0000 Subject: [issue2090] __import__ with fromlist= In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za> Message-ID: <1334704696.06.0.212726209447.issue2090@psf.upfronthosting.co.za> Brett Cannon added the comment: Importlib does away with this issue. ---------- resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:19:30 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Apr 2012 23:19:30 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334704770.28.0.459465163831.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file25254/384190bb0bd5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:20:08 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 17 Apr 2012 23:20:08 +0000 Subject: [issue12599] Use 'is not None' where appropriate in importlib In-Reply-To: <1311204866.94.0.868144642715.issue12599@psf.upfronthosting.co.za> Message-ID: <1334704808.45.0.378849470491.issue12599@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- components: +Library (Lib) keywords: +easy priority: normal -> low versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:20:45 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Apr 2012 23:20:45 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334704845.3.0.348416092823.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25253/aac59a3c11ef.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:23:02 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Apr 2012 23:23:02 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334704982.85.0.932146397233.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: > can you let us know when you think the patch is ready for review? Now! I created a repository for the PEP. I integrated my own last comments. I tested the PEP on Linux 3.3, FreeBSD 8, OpenBSD 5, OpenSolaris and Windows Seven. The implementation is ready for a review. The last patch is 384190bb0bd5.diff (presented as "Patch Set 12" in Rietveld). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:36:42 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 17 Apr 2012 23:36:42 +0000 Subject: [issue14607] method with special keyword-only argument gives error In-Reply-To: <1334698096.33.0.253940616413.issue14607@psf.upfronthosting.co.za> Message-ID: <1334705802.38.0.572421611171.issue14607@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:37:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 17 Apr 2012 23:37:20 +0000 Subject: [issue14606] Memory leak subprocess In-Reply-To: <1334689181.81.0.435135933783.issue14606@psf.upfronthosting.co.za> Message-ID: <1334705840.61.0.46370943252.issue14606@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brian.curtin, tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:37:28 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 17 Apr 2012 23:37:28 +0000 Subject: [issue14606] Memory leak subprocess In-Reply-To: <1334689181.81.0.435135933783.issue14606@psf.upfronthosting.co.za> Message-ID: <1334705848.16.0.70005816395.issue14606@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- components: +Library (Lib), Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:38:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 17 Apr 2012 23:38:11 +0000 Subject: [issue1615] descriptor protocol bug In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za> Message-ID: <1334705891.14.0.0312618612651.issue1615@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:54:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Apr 2012 23:54:31 +0000 Subject: [issue14607] method with special keyword-only argument gives error In-Reply-To: <1334698096.33.0.253940616413.issue14607@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f8540b8d076c by Benjamin Peterson in branch '3.2': mangle keyword-only argname when loading defaults (closes #14607) http://hg.python.org/cpython/rev/f8540b8d076c ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 01:54:41 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 17 Apr 2012 23:54:41 +0000 Subject: [issue14607] method with special keyword-only argument gives error In-Reply-To: <1334698096.33.0.253940616413.issue14607@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 22844ddce57b by Benjamin Peterson in branch 'default': merge 3.2 (#14607) http://hg.python.org/cpython/rev/22844ddce57b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 02:05:58 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 00:05:58 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1334707558.5.0.223958941119.issue14605@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 02:08:29 2012 From: report at bugs.python.org (Hugh Gibbons) Date: Wed, 18 Apr 2012 00:08:29 +0000 Subject: [issue14575] IDLE crashes after file open in OS X In-Reply-To: <1334439028.52.0.411774438491.issue14575@psf.upfronthosting.co.za> Message-ID: Hugh Gibbons added the comment: There were no errors when opening the file that way. On Apr 14, 2012, at 3:30 PM, Roger Serwy wrote: > > Roger Serwy added the comment: > > Hugh, Can you launch IDLE from the terminal and report the error message you receive? From a regular Terminal, enter: > > python -m idlelib.idle FILE_TO_OPEN.py > > ---------- > nosy: +serwy > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 02:14:04 2012 From: report at bugs.python.org (Hugh Gibbons) Date: Wed, 18 Apr 2012 00:14:04 +0000 Subject: [issue14575] IDLE crashes after file open in OS X In-Reply-To: <1334439028.52.0.411774438491.issue14575@psf.upfronthosting.co.za> Message-ID: <4480335E-965B-489A-BE72-B053938FF63A@gmail.com> Hugh Gibbons added the comment: No errors when opening the file that way. However, when I then go to the IDLE file menu and open a file using the file browser ( File -> Open.. ) IDLE terminates with a segmentation fault a few seconds after opening the file. Below, I pasted a copy of the messages that appear in the error report that appears when the program crashes. On Apr 14, 2012, at 3:30 PM, Roger Serwy wrote: > > Roger Serwy added the comment: > > Hugh, Can you launch IDLE from the terminal and report the error message you receive? From a regular Terminal, enter: > > python -m idlelib.idle FILE_TO_OPEN.py > > ---------- > nosy: +serwy > > _______________________________________ > Python tracker > > _______________________________________ ------ error report follows this line ------ Process: Python [5003] Path: /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python Identifier: org.python.python Version: 2.7.3 (2.7.3) Code Type: X86-64 (Native) Parent Process: bash [4992] Date/Time: 2012-04-17 18:08:57.920 -0600 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6 Interval Since Last Report: 31224 sec Crashes Since Last Report: 1 Per-App Interval Since Last Report: -421 sec Per-App Crashes Since Last Report: 1 Anonymous UUID: F3E76799-9CEF-4733-8775-57C2DCB2098E Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: objc_msgSend() selector name: release Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x00007fff83970f10 objc_msgSend + 44 1 com.apple.CoreFoundation 0x00007fff812891d6 _CFAutoreleasePoolPop + 230 2 com.apple.Foundation 0x00007fff85cd1110 -[NSAutoreleasePool drain] + 158 3 Tk 0x00000001010bba4f XQueryPointer + 2425 4 Tk 0x00000001010bbd3f Tk_MacOSXSetupTkNotifier + 614 5 Tcl 0x00000001006902ae Tcl_DoOneEvent + 297 6 _tkinter.so 0x000000010060e65d Tkapp_MainLoop + 413 7 org.python.python 0x00000001000c1e7d PyEval_EvalFrameEx + 25213 8 org.python.python 0x00000001000c4149 PyEval_EvalCodeEx + 2137 9 org.python.python 0x00000001000c1a3d PyEval_EvalFrameEx + 24125 10 org.python.python 0x00000001000c286d PyEval_EvalFrameEx + 27757 11 org.python.python 0x00000001000c4149 PyEval_EvalCodeEx + 2137 12 org.python.python 0x00000001000c376f PyEval_EvalFrameEx + 31599 13 org.python.python 0x00000001000c4149 PyEval_EvalCodeEx + 2137 14 org.python.python 0x00000001000c1a3d PyEval_EvalFrameEx + 24125 15 org.python.python 0x00000001000c4149 PyEval_EvalCodeEx + 2137 16 org.python.python 0x000000010003d910 function_call + 176 17 org.python.python 0x000000010000c362 PyObject_Call + 98 18 org.python.python 0x00000001000ff2ac RunModule + 124 19 org.python.python 0x00000001000ffd75 Py_Main + 2325 20 org.python.python 0x0000000100000f14 0x100000000 + 3860 Thread 1: Dispatch queue: com.apple.libdispatch-manager 0 libSystem.B.dylib 0x00007fff89e35c0a kevent + 10 1 libSystem.B.dylib 0x00007fff89e37add _dispatch_mgr_invoke + 154 2 libSystem.B.dylib 0x00007fff89e377b4 _dispatch_queue_invoke + 185 3 libSystem.B.dylib 0x00007fff89e372de _dispatch_worker_thread2 + 252 4 libSystem.B.dylib 0x00007fff89e36c08 _pthread_wqthread + 353 5 libSystem.B.dylib 0x00007fff89e36aa5 start_wqthread + 13 Thread 2: 0 libSystem.B.dylib 0x00007fff89e60932 select$DARWIN_EXTSN + 10 1 Tcl 0x00000001006c1d86 Tcl_InitNotifier + 1520 2 libSystem.B.dylib 0x00007fff89e55fd6 _pthread_start + 331 3 libSystem.B.dylib 0x00007fff89e55e89 thread_start + 13 Thread 3: 0 libSystem.B.dylib 0x00007fff89e36a2a __workq_kernreturn + 10 1 libSystem.B.dylib 0x00007fff89e36e3c _pthread_wqthread + 917 2 libSystem.B.dylib 0x00007fff89e36aa5 start_wqthread + 13 Thread 4: 0 libSystem.B.dylib 0x00007fff89e1cd7a mach_msg_trap + 10 1 libSystem.B.dylib 0x00007fff89e1d3ed mach_msg + 59 2 com.apple.CoreFoundation 0x00007fff812a0902 __CFRunLoopRun + 1698 3 com.apple.CoreFoundation 0x00007fff8129fd8f CFRunLoopRunSpecific + 575 4 com.apple.CoreFoundation 0x00007fff8129fb16 CFRunLoopRun + 70 5 com.apple.DesktopServices 0x00007fff8417d326 TSystemNotificationTask::SystemNotificationTaskProc(void*) + 514 6 ...ple.CoreServices.CarbonCore 0x00007fff8672c0d1 PrivateMPEntryPoint + 63 7 libSystem.B.dylib 0x00007fff89e55fd6 _pthread_start + 331 8 libSystem.B.dylib 0x00007fff89e55e89 thread_start + 13 Thread 5: 0 libSystem.B.dylib 0x00007fff89e36a2a __workq_kernreturn + 10 1 libSystem.B.dylib 0x00007fff89e36e3c _pthread_wqthread + 917 2 libSystem.B.dylib 0x00007fff89e36aa5 start_wqthread + 13 Thread 6: 0 libSystem.B.dylib 0x00007fff89e36a2a __workq_kernreturn + 10 1 libSystem.B.dylib 0x00007fff89e36e3c _pthread_wqthread + 917 2 libSystem.B.dylib 0x00007fff89e36aa5 start_wqthread + 13 Thread 7: com.apple.CFSocket.private 0 libSystem.B.dylib 0x00007fff89e60932 select$DARWIN_EXTSN + 10 1 com.apple.CoreFoundation 0x00007fff812c2468 __CFSocketManager + 824 2 libSystem.B.dylib 0x00007fff89e55fd6 _pthread_start + 331 3 libSystem.B.dylib 0x00007fff89e55e89 thread_start + 13 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000400 rbx: 0x00000001139c9e50 rcx: 0x00007fff71211650 rdx: 0x00000000000076f5 rdi: 0x00000001139c9e50 rsi: 0x00007fff84c53640 rbp: 0x00007fff5fbfe430 rsp: 0x00007fff5fbfe3f8 r8: 0x0000000000000000 r9: 0x000000011631c720 r10: 0x0000000000000001 r11: 0x000000011677919b r12: 0x0000000101934000 r13: 0x0000000100c8e600 r14: 0x00007fff7018a3c0 r15: 0x0000000000000000 rip: 0x00007fff83970f10 rfl: 0x0000000000010206 cr2: 0x0000000000000000 Binary Images: 0x100000000 - 0x100000fff +org.python.python 2.7.3 (2.7.3) /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python 0x100003000 - 0x10016dff7 +org.python.python 2.7.3, (c) 2004-2012 Python Software Foundation. (2.7.3) <4F9EF48A-7D0C-0C1A-670B-3BF4E72C8696> /Library/Frameworks/Python.framework/Versions/2.7/Python 0x1002ee000 - 0x1002f1ff7 +strop.so ??? (???) <6389C456-82E5-D58F-D87D-78445284CDEC> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/strop.so 0x1002f6000 - 0x1002f7ff7 +_functools.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_functools.so 0x1002fa000 - 0x1002fbfff +cStringIO.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cStringIO.so 0x1004f0000 - 0x1004f8fff +_socket.so ??? (???) <4B24FFF5-0303-2D87-BFB1-20A45E087B69> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_socket.so 0x100502000 - 0x100506ff7 +_ssl.so ??? (???) <51E5DA69-DE4B-7883-0F68-3AAD95D277B0> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_ssl.so 0x10050c000 - 0x10050efff +time.so ??? (???) <92709D00-9460-B5B6-B97F-100C3A055DBB> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/time.so 0x10060a000 - 0x100612ff7 +_tkinter.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so 0x10061b000 - 0x1006f9fff Tcl 8.5.7 (8.5.7) <58173834-8624-4846-6999-5823F9611D0E> /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl 0x100757000 - 0x10075bfff +_collections.so ??? (???) <9D150F88-A639-8D17-B4C1-B003ED64A825> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_collections.so 0x100761000 - 0x100765ff7 +operator.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/operator.so 0x10076c000 - 0x100773ff7 +itertools.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/itertools.so 0x10077e000 - 0x10077efff +_bisect.so ??? (???) <7C2E4AE4-BD2E-E0B1-ED49-C97797A87862> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_bisect.so 0x100781000 - 0x100782ff7 +_heapq.so ??? (???) <6E943E3D-86B8-E5B6-6469-4F37AB67DD0F> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_heapq.so 0x100786000 - 0x100789fff +select.so ??? (???) <4FAF1D70-ED6A-D278-4025-017E5690DD7A> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/select.so 0x10078f000 - 0x100790ff7 +fcntl.so ??? (???) <888D3D1A-9537-E266-ED0B-0626C1965FE5> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/fcntl.so 0x100793000 - 0x100797fff +_struct.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_struct.so 0x1007de000 - 0x1007e1fef +binascii.so ??? (???) <1D3A5AFB-4FDE-4B1D-7BAB-ED2E8B4DC3BF> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/binascii.so 0x1007e5000 - 0x1007eafef +math.so ??? (???) <72277351-515A-6D6A-556C-B863114DB023> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/math.so 0x1007f1000 - 0x1007f2fff +_hashlib.so ??? (???) /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_hashlib.so 0x1007f6000 - 0x1007f7fff +_random.so ??? (???) <959FCA12-F992-BD11-053D-4FA2E312ECBB> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_random.so 0x1007fa000 - 0x1007fcfff +_locale.so ??? (???) <8410BA87-ECC3-40D3-6540-25F3954A791B> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_locale.so 0x101000000 - 0x101108fef Tk 8.5.7 (8.5.7) /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk 0x1011c9000 - 0x1011d8ff7 +cPickle.so ??? (???) <2F2B7AB6-CB55-1343-A766-831844DEBF4C> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cPickle.so 0x117b20000 - 0x117cb3fe7 GLEngine ??? (???) /System/Library/Frameworks/OpenGL.framework/Resources/GLEngine.bundle/GLEngine 0x117ce4000 - 0x118100fff com.apple.ATIRadeonX2000GLDriver 1.6.36 (6.3.6) /System/Library/Extensions/ATIRadeonX2000GLDriver.bundle/Contents/MacOS/ATIRadeonX2000GLDriver 0x118164000 - 0x11818afff GLRendererFloat ??? (???) <38621D22-8F49-F937-851B-E21BD49A8A88> /System/Library/Frameworks/OpenGL.framework/Resources/GLRendererFloat.bundle/GLRendererFloat 0x118373000 - 0x118378fff com.apple.qldisplay.Text 2.3 (327.6) /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuickLookUI.framework/Versions/A/Resources/DisplayBundles/Text.qldisplay/Contents/MacOS/Text 0x11837f000 - 0x118384fff com.apple.qldisplay.Generic 2.3 (327.6) /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuickLookUI.framework/Versions/A/Resources/DisplayBundles/Generic.qldisplay/Contents/MacOS/Generic 0x7fff5fc00000 - 0x7fff5fc3be0f dyld 132.1 (???) <29DECB19-0193-2575-D838-CF743F0400B2> /usr/lib/dyld 0x7fff80104000 - 0x7fff80164fe7 com.apple.framework.IOKit 2.0 (???) <4F071EF0-8260-01E9-C641-830E582FA416> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x7fff80165000 - 0x7fff80167fff com.apple.print.framework.Print 6.1 (237.1) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print 0x7fff80168000 - 0x7fff80168ff7 com.apple.Cocoa 6.6 (???) <68B0BE46-6E24-C96F-B341-054CF9E8F3B6> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 0x7fff80169000 - 0x7fff801d5fe7 com.apple.CorePDF 1.4 (1.4) <06AE6D85-64C7-F9CC-D001-BD8BAE31B6D2> /System/Library/PrivateFrameworks/CorePDF.framework/Versions/A/CorePDF 0x7fff801d6000 - 0x7fff804f8fef com.apple.JavaScriptCore 6534.55 (6534.55.2) /System/Library/Frameworks/JavaScriptCore.framework/Versions/A/JavaScriptCore 0x7fff804f9000 - 0x7fff804fbfff libRadiance.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib 0x7fff804fc000 - 0x7fff804fcff7 com.apple.ApplicationServices 38 (38) <10A0B9E9-4988-03D4-FC56-DDE231A02C63> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices 0x7fff804fd000 - 0x7fff8050ffe7 libsasl2.2.dylib 3.15.0 (compatibility 3.0.0) <76B83C8D-8EFE-4467-0F75-275648AFED97> /usr/lib/libsasl2.2.dylib 0x7fff80510000 - 0x7fff80c0cff7 com.apple.CoreGraphics 1.545.0 (???) <58D597B1-EB3B-710E-0B8C-EC114D54E11B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x7fff80c0d000 - 0x7fff80c3efff libGLImage.dylib ??? (???) <562565E1-AA65-FE96-13FF-437410C886D0> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib 0x7fff80c51000 - 0x7fff80cc2ff7 com.apple.AppleVAFramework 4.10.27 (4.10.27) <6CDBA3F5-6C7C-A069-4716-2B6C3AD5001F> /System/Library/PrivateFrameworks/AppleVA.framework/Versions/A/AppleVA 0x7fff80cc3000 - 0x7fff80e33fff com.apple.QTKit 7.7 (1789) <212AE7F7-EFDB-275D-88FB-33B9CF809842> /System/Library/Frameworks/QTKit.framework/Versions/A/QTKit 0x7fff80e34000 - 0x7fff80e5cfff com.apple.DictionaryServices 1.1.2 (1.1.2) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices 0x7fff80e5d000 - 0x7fff80e9efef com.apple.CoreMedia 0.484.60 (484.60) <6B73A514-C4D5-8DC7-982C-4E4F0231ED77> /System/Library/PrivateFrameworks/CoreMedia.framework/Versions/A/CoreMedia 0x7fff80edd000 - 0x7fff811dbfff com.apple.HIToolbox 1.6.5 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x7fff811dc000 - 0x7fff81217fff com.apple.AE 496.5 (496.5) <208DF391-4DE6-81ED-C697-14A2930D1BC6> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE 0x7fff81254000 - 0x7fff813cbfe7 com.apple.CoreFoundation 6.6.6 (550.44) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff813cc000 - 0x7fff813fcfef com.apple.shortcut 1.1 (1.1) /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut 0x7fff8143c000 - 0x7fff81442ff7 com.apple.DiskArbitration 2.3 (2.3) <857F6E43-1EF4-7D53-351B-10DE0A8F992A> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x7fff81443000 - 0x7fff8148dff7 com.apple.Metadata 10.6.3 (507.15) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata 0x7fff81cbf000 - 0x7fff81d93fe7 com.apple.CFNetwork 454.12.4 (454.12.4) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x7fff81dde000 - 0x7fff81e03ff7 com.apple.CoreVideo 1.6.2 (45.6) /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo 0x7fff81e04000 - 0x7fff81e05fff liblangid.dylib ??? (???) /usr/lib/liblangid.dylib 0x7fff81e06000 - 0x7fff81e70fe7 libvMisc.dylib 268.0.1 (compatibility 1.0.0) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib 0x7fff81e71000 - 0x7fff81e7bfff com.apple.DisplayServicesFW 2.3.3 (289) <97F62F36-964A-3E17-2A26-A0EEF63F4BDE> /System/Library/PrivateFrameworks/DisplayServices.framework/Versions/A/DisplayServices 0x7fff81e7c000 - 0x7fff81e90ff7 com.apple.speech.synthesis.framework 3.10.35 (3.10.35) <63C87CF7-56B3-4038-8136-8C26E96AD42F> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x7fff81e91000 - 0x7fff81e9cff7 com.apple.speech.recognition.framework 3.11.1 (3.11.1) <3D65E89B-FFC6-4AAF-D5CC-104F967C8131> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition 0x7fff81e9d000 - 0x7fff81ebefff libresolv.9.dylib 41.1.0 (compatibility 1.0.0) <9410EC7F-4D24-6740-AFEE-90405750FAD7> /usr/lib/libresolv.9.dylib 0x7fff81ebf000 - 0x7fff81ecefef com.apple.opengl 1.6.14 (1.6.14) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 0x7fff81ecf000 - 0x7fff81f31fe7 com.apple.datadetectorscore 2.0 (80.7) <5B6AABCA-C75A-D28F-6A2F-59648F0ABFC8> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore 0x7fff81f32000 - 0x7fff82049fef libxml2.2.dylib 10.3.0 (compatibility 10.0.0) <1B27AFDD-DF87-2009-170E-C129E1572E8B> /usr/lib/libxml2.2.dylib 0x7fff82251000 - 0x7fff82267fef libbsm.0.dylib ??? (???) <83676D2E-23CD-45CD-BE5C-35FCFFBBBDBB> /usr/lib/libbsm.0.dylib 0x7fff82268000 - 0x7fff8226dff7 com.apple.CommonPanels 1.2.4 (91) <4D84803B-BD06-D80E-15AE-EFBE43F93605> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels 0x7fff8226e000 - 0x7fff82273fff libGIF.dylib ??? (???) <1888A176-22D5-C663-22D0-336D9D213BD6> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib 0x7fff82274000 - 0x7fff82282ff7 libkxld.dylib ??? (???) <8145A534-95CC-9F3C-B78B-AC9898F38C6F> /usr/lib/system/libkxld.dylib 0x7fff822db000 - 0x7fff82419fff com.apple.CoreData 102.1 (251) <9DFE798D-AA52-6A9A-924A-DA73CB94D81A> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData 0x7fff8241a000 - 0x7fff82430fe7 com.apple.MultitouchSupport.framework 207.11 (207.11) <8233CE71-6F8D-8B3C-A0E1-E123F6406163> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport 0x7fff82452000 - 0x7fff8246dff7 com.apple.openscripting 1.3.1 (???) <9D50701D-54AC-405B-CC65-026FCB28258B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting 0x7fff82497000 - 0x7fff8249aff7 libCoreVMClient.dylib ??? (???) <75819794-3B7A-8944-D004-7EA6DD7CE836> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib 0x7fff8249b000 - 0x7fff824dcfff com.apple.SystemConfiguration 1.10.8 (1.10.2) <78D48D27-A9C4-62CA-2803-D0BBED82855A> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 0x7fff824dd000 - 0x7fff824f6fff com.apple.CFOpenDirectory 10.6 (10.6) <401557B1-C6D1-7E1A-0D7E-941715C37BFA> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory 0x7fff824f7000 - 0x7fff8251afff com.apple.opencl 12.3.6 (12.3.6) <42FA5783-EB80-1168-4015-B8C68F55842F> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL 0x7fff8251b000 - 0x7fff82650fff com.apple.audio.toolbox.AudioToolbox 1.6.7 (1.6.7) /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 0x7fff82e31000 - 0x7fff82e48fff com.apple.ImageCapture 6.1 (6.1) <79AB2131-2A6C-F351-38A9-ED58B25534FD> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture 0x7fff82e49000 - 0x7fff82f53ff7 com.apple.MeshKitIO 1.1 (49.2) /System/Library/PrivateFrameworks/MeshKit.framework/Versions/A/Frameworks/MeshKitIO.framework/Versions/A/MeshKitIO 0x7fff82f54000 - 0x7fff82fd6fff com.apple.QuickLookUIFramework 2.3 (327.6) <9093682A-0E2D-7D27-5F22-C96FD00AE970> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuickLookUI.framework/Versions/A/QuickLookUI 0x7fff82ff2000 - 0x7fff831b0ff7 com.apple.ImageIO.framework 3.0.5 (3.0.5) <4CF96F2C-B7BB-4C57-E352-3C678CA2B2B1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x7fff831b1000 - 0x7fff831befe7 libCSync.A.dylib 545.0.0 (compatibility 64.0.0) <1C35FA50-9C70-48DC-9E8D-2054F7A266B1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib 0x7fff831bf000 - 0x7fff8369bfef com.apple.RawCamera.bundle 3.12.0 (614) /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera 0x7fff837d0000 - 0x7fff837d6ff7 IOSurface ??? (???) <8E302BB2-0704-C6AB-BD2F-C2A6C6A2E2C3> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface 0x7fff8380f000 - 0x7fff8380fff7 com.apple.CoreServices 44 (44) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x7fff83810000 - 0x7fff838d2fe7 libFontParser.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib 0x7fff838d3000 - 0x7fff8391ffff libauto.dylib ??? (???) /usr/lib/libauto.dylib 0x7fff8396c000 - 0x7fff83a22ff7 libobjc.A.dylib 227.0.0 (compatibility 1.0.0) <03140531-3B2D-1EBA-DA7F-E12CC8F63969> /usr/lib/libobjc.A.dylib 0x7fff83a23000 - 0x7fff83a6bff7 libvDSP.dylib 268.0.1 (compatibility 1.0.0) <98FC4457-F405-0262-00F7-56119CA107B6> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib 0x7fff83a6c000 - 0x7fff83aa9ff7 libssl.0.9.8.dylib 0.9.8 (compatibility 0.9.8) /usr/lib/libssl.0.9.8.dylib 0x7fff83aaa000 - 0x7fff83bc9fe7 libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8) <14115D29-432B-CF02-6B24-A60CC533A09E> /usr/lib/libcrypto.0.9.8.dylib 0x7fff83c1a000 - 0x7fff83c1bff7 com.apple.audio.units.AudioUnit 1.6.7 (1.6.7) <49B723D1-85F8-F86C-2331-F586C56D68AF> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit 0x7fff83c1c000 - 0x7fff83c1ffff com.apple.help 1.3.2 (41.1) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help 0x7fff83c20000 - 0x7fff83c6fff7 com.apple.DirectoryService.PasswordServerFramework 6.1 (6.1) <0731C40D-71EF-B417-C83B-54C3527A36EA> /System/Library/PrivateFrameworks/PasswordServer.framework/Versions/A/PasswordServer 0x7fff83d2b000 - 0x7fff83de0fe7 com.apple.ink.framework 1.3.3 (107) <8C36373C-5473-3A6A-4972-BC29D504250F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink 0x7fff84125000 - 0x7fff8417aff7 com.apple.framework.familycontrols 2.0.2 (2020) <8807EB96-D12D-8601-2E74-25784A0DE4FF> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls 0x7fff8417b000 - 0x7fff84260fef com.apple.DesktopServices 1.5.11 (1.5.11) <39FAA3D2-6863-B5AB-AED9-92D878EA2438> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv 0x7fff84460000 - 0x7fff844a5fff com.apple.CoreMediaIOServices 140.0 (1496) /System/Library/PrivateFrameworks/CoreMediaIOServices.framework/Versions/A/CoreMediaIOServices 0x7fff8451b000 - 0x7fff84f15ff7 com.apple.AppKit 6.6.8 (1038.36) <4CFBE04C-8FB3-B0EA-8DDB-7E7D10E9D251> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x7fff84f16000 - 0x7fff84f57fef com.apple.QD 3.36 (???) <5DC41E81-32C9-65B2-5528-B33E934D5BB4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD 0x7fff84f58000 - 0x7fff84f6cfff libGL.dylib ??? (???) <2ECE3B0F-39E1-3938-BF27-7205C6D0358B> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib 0x7fff84f7a000 - 0x7fff84fcdff7 com.apple.HIServices 1.8.3 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x7fff84fce000 - 0x7fff85001ff7 libTrueTypeScaler.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib 0x7fff85008000 - 0x7fff85053fef com.apple.ImageCaptureCore 1.1 (1.1) /System/Library/Frameworks/ImageCaptureCore.framework/Versions/A/ImageCaptureCore 0x7fff85054000 - 0x7fff85069ff7 com.apple.LangAnalysis 1.6.6 (1.6.6) <1AE1FE8F-2204-4410-C94E-0E93B003BEDA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0x7fff8506a000 - 0x7fff850fafff com.apple.SearchKit 1.3.0 (1.3.0) <3403E658-A54E-A79A-12EB-E090E8743984> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit 0x7fff850fb000 - 0x7fff85135fff libcups.2.dylib 2.8.0 (compatibility 2.0.0) <539EBFDD-96D6-FB07-B128-40232C408757> /usr/lib/libcups.2.dylib 0x7fff85136000 - 0x7fff854d3fe7 com.apple.QuartzCore 1.6.3 (227.37) <16DFF6CD-EA58-CE62-A1D7-5F6CE3D066DD> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore 0x7fff854d4000 - 0x7fff854d7ff7 com.apple.securityhi 4.0 (36638) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI 0x7fff854fc000 - 0x7fff8550bfff com.apple.NetFS 3.2.2 (3.2.2) <7CCBD70E-BF31-A7A7-DB98-230687773145> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS 0x7fff8550c000 - 0x7fff8550cff7 com.apple.quartzframework 1.5 (1.5) /System/Library/Frameworks/Quartz.framework/Versions/A/Quartz 0x7fff85510000 - 0x7fff85779fff com.apple.QuartzComposer 4.2 ({156.30}) /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuartzComposer.framework/Versions/A/QuartzComposer 0x7fff8578a000 - 0x7fff8580fff7 com.apple.print.framework.PrintCore 6.3 (312.7) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x7fff85810000 - 0x7fff85821ff7 libz.1.dylib 1.2.3 (compatibility 1.0.0) <97019C74-161A-3488-41EC-A6CA8738418C> /usr/lib/libz.1.dylib 0x7fff85822000 - 0x7fff85c66fef libLAPACK.dylib 219.0.0 (compatibility 1.0.0) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib 0x7fff85c67000 - 0x7fff85caafef libtidy.A.dylib ??? (???) <2F4273D3-418B-668C-F488-7E659D3A8C23> /usr/lib/libtidy.A.dylib 0x7fff85cab000 - 0x7fff85f2dfff com.apple.Foundation 6.6.8 (751.63) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x7fff85f2e000 - 0x7fff85f75fff com.apple.QuickLookFramework 2.3 (327.6) <11DFB135-24A6-C0BC-5B97-ECE352A4B488> /System/Library/Frameworks/QuickLook.framework/Versions/A/QuickLook 0x7fff85f76000 - 0x7fff85ff4ff7 com.apple.CoreText 151.12 (???) <5BE797B7-C903-B664-ADD9-7514B1A6EF9E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText 0x7fff85ff5000 - 0x7fff85ffbfff libCGXCoreImage.A.dylib 545.0.0 (compatibility 64.0.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXCoreImage.A.dylib 0x7fff86071000 - 0x7fff862abfef com.apple.imageKit 2.0.3 (1.0) <9EA216AF-82D6-201C-78E5-D027D85B51D6> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/ImageKit.framework/Versions/A/ImageKit 0x7fff862ac000 - 0x7fff8632bfe7 com.apple.audio.CoreAudio 3.2.6 (3.2.6) <79E256EB-43F1-C7AA-6436-124A4FFB02D0> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 0x7fff86499000 - 0x7fff864d2ff7 com.apple.MeshKit 1.1 (49.2) <832A074D-7601-F7C9-6D3A-E1C58965C3A1> /System/Library/PrivateFrameworks/MeshKit.framework/Versions/A/MeshKit 0x7fff86725000 - 0x7fff86a59fef com.apple.CoreServices.CarbonCore 861.39 (861.39) <1386A24D-DD15-5903-057E-4A224FAF580B> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x7fff86a5a000 - 0x7fff86f60ff7 com.apple.VideoToolbox 0.484.60 (484.60) /System/Library/PrivateFrameworks/VideoToolbox.framework/Versions/A/VideoToolbox 0x7fff86f94000 - 0x7fff870aefff libGLProgrammability.dylib ??? (???) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib 0x7fff87179000 - 0x7fff87179ff7 com.apple.Accelerate 1.6 (Accelerate 1.6) <15DF8B4A-96B2-CB4E-368D-DEC7DF6B62BB> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 0x7fff8717a000 - 0x7fff8723bfef com.apple.ColorSync 4.6.8 (4.6.8) <7DF1D175-6451-51A2-DBBF-40FCA78C0D2C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync 0x7fff8723c000 - 0x7fff8724dfff com.apple.DSObjCWrappers.Framework 10.6 (134) <3C08225D-517E-2822-6152-F6EB13A4ADF9> /System/Library/PrivateFrameworks/DSObjCWrappers.framework/Versions/A/DSObjCWrappers 0x7fff8724e000 - 0x7fff874d8fe7 com.apple.security 6.1.2 (55002) /System/Library/Frameworks/Security.framework/Versions/A/Security 0x7fff874fa000 - 0x7fff87594fff com.apple.ApplicationServices.ATS 275.19 (???) <2DE8987F-4563-4D8E-45C3-2F6F786E120D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS 0x7fff87595000 - 0x7fff87d9ffe7 libBLAS.dylib 219.0.0 (compatibility 1.0.0) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 0x7fff87da0000 - 0x7fff87da0ff7 com.apple.Accelerate.vecLib 3.6 (vecLib 3.6) <4CCE5D69-F1B3-8FD3-1483-E0271DB2CCF3> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib 0x7fff88e2e000 - 0x7fff88e6cfe7 libFontRegistry.dylib ??? (???) <395D7C0D-36B5-B353-0DC8-51ABC0B1C030> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib 0x7fff88ea4000 - 0x7fff88eedfef libGLU.dylib ??? (???) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib 0x7fff89087000 - 0x7fff89088ff7 com.apple.TrustEvaluationAgent 1.1 (1) <5952A9FA-BC2B-16EF-91A7-43902A5C07B6> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent 0x7fff89089000 - 0x7fff890d0ff7 com.apple.coreui 2 (114) <923E33CC-83FC-7D35-5603-FB8F348EE34B> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI 0x7fff892a3000 - 0x7fff892c0ff7 libPng.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib 0x7fff892c1000 - 0x7fff892c2fff com.apple.MonitorPanelFramework 1.3.0 (1.3.0) <5062DACE-FCE7-8E41-F5F6-58821778629C> /System/Library/PrivateFrameworks/MonitorPanel.framework/Versions/A/MonitorPanel 0x7fff892c3000 - 0x7fff89363fff com.apple.LaunchServices 362.3 (362.3) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices 0x7fff89364000 - 0x7fff893e1fef libstdc++.6.dylib 7.9.0 (compatibility 7.0.0) <35ECA411-2C08-FD7D-11B1-1B7A04921A5C> /usr/lib/libstdc++.6.dylib 0x7fff894bb000 - 0x7fff894c0fff libGFXShared.dylib ??? (???) <6BBC351E-40B3-F4EB-2F35-05BDE52AF87E> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib 0x7fff894eb000 - 0x7fff895a8fff com.apple.CoreServices.OSServices 359.2 (359.2) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices 0x7fff89607000 - 0x7fff89656fef libTIFF.dylib ??? (???) <2DDC5A18-35EE-5B59-10D8-0F6925DB3858> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib 0x7fff897c9000 - 0x7fff897e9ff7 com.apple.DirectoryService.Framework 3.6 (621.12) /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService 0x7fff89812000 - 0x7fff898a1fff com.apple.PDFKit 2.5.1 (2.5.1) <38BEE9BB-3716-49BA-7E14-687FE9E066EB> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/PDFKit.framework/Versions/A/PDFKit 0x7fff898a2000 - 0x7fff898d1ff7 com.apple.quartzfilters 1.6.0 (1.6.0) <9CECB4FC-1CCF-B8A2-B935-5888B21CBEEF> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuartzFilters.framework/Versions/A/QuartzFilters 0x7fff898d2000 - 0x7fff89915ff7 libRIP.A.dylib 545.0.0 (compatibility 64.0.0) <5FF3D7FD-84D8-C5FA-D640-90BB82EC651D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib 0x7fff89916000 - 0x7fff89941ff7 libxslt.1.dylib 3.24.0 (compatibility 3.0.0) <8AB4CA9E-435A-33DA-7041-904BA7FA11D5> /usr/lib/libxslt.1.dylib 0x7fff89985000 - 0x7fff89989ff7 libCGXType.A.dylib 545.0.0 (compatibility 64.0.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib 0x7fff899b3000 - 0x7fff89adbff7 com.apple.MediaToolbox 0.484.60 (484.60) /System/Library/PrivateFrameworks/MediaToolbox.framework/Versions/A/MediaToolbox 0x7fff89bee000 - 0x7fff89c7bfff com.apple.iLifeMediaBrowser 2.5.5 (468.2.2) <0A7B422E-5D79-9980-2477-05DC2CB5CF7C> /System/Library/PrivateFrameworks/iLifeMediaBrowser.framework/Versions/A/iLifeMediaBrowser 0x7fff89c7c000 - 0x7fff89d08fef SecurityFoundation ??? (???) <3F1F2727-C508-3630-E2C1-38361841FCE4> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation 0x7fff89d09000 - 0x7fff89d09ff7 com.apple.vecLib 3.6 (vecLib 3.6) <96FB6BAD-5568-C4E0-6FA7-02791A58B584> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib 0x7fff89d6b000 - 0x7fff89e1bfff edu.mit.Kerberos 6.5.11 (6.5.11) <085D80F5-C9DC-E252-C21B-03295E660C91> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos 0x7fff89e1c000 - 0x7fff89fddfef libSystem.B.dylib 125.2.11 (compatibility 1.0.0) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib 0x7fff89ffc000 - 0x7fff8a003fff com.apple.OpenDirectory 10.6 (10.6) <4FF6AD25-0916-B21C-9E88-2CC42D90EAC7> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory 0x7fff8a0d3000 - 0x7fff8a0d9ff7 com.apple.CommerceCore 1.0 (9.1) <3691E9BA-BCF4-98C7-EFEC-78DA6825004E> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore 0x7fff8a2bd000 - 0x7fff8a376fff libsqlite3.dylib 9.6.0 (compatibility 9.0.0) <2C5ED312-E646-9ADE-73A9-6199A2A43150> /usr/lib/libsqlite3.dylib 0x7fff8a377000 - 0x7fff8a37bff7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib 0x7fff8a37c000 - 0x7fff8a3a3ff7 libJPEG.dylib ??? (???) <921A3A14-A69B-F393-1678-5A5D32D4BDF2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib 0x7fff8a3fe000 - 0x7fff8a409ff7 com.apple.HelpData 2.0.5 (34.1.1) <24DC6CD3-02B7-9332-FF6D-F0C545857B55> /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData 0x7fff8a40a000 - 0x7fff8a472fff com.apple.MeshKitRuntime 1.1 (49.2) <4D3045D0-0D50-7053-3A05-0AECE86E39F8> /System/Library/PrivateFrameworks/MeshKit.framework/Versions/A/Frameworks/MeshKitRuntime.framework/Versions/A/MeshKitRuntime 0x7fff8a4a8000 - 0x7fff8a585fff com.apple.vImage 4.1 (4.1) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage 0x7fff8a586000 - 0x7fff8a586ff7 com.apple.Carbon 150 (152) <23704665-E9F4-6B43-1115-2E69F161FC45> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 0x7fff8a587000 - 0x7fff8a745fff libicucore.A.dylib 40.0.0 (compatibility 1.0.0) <4274FC73-A257-3A56-4293-5968F3428854> /usr/lib/libicucore.A.dylib 0x7fffffe00000 - 0x7fffffe01fff libSystem.B.dylib ??? (???) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib Model: iMac10,1, BootROM IM101.00CC.B00, 2 processors, Intel Core 2 Duo, 3.33 GHz, 4 GB, SMC 1.52f9 Graphics: ATI Radeon HD 4670, ATI Radeon HD 4670, PCIe, 256 MB Memory Module: global_name AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x8F), Atheros 9280: 2.1.14.6 Bluetooth: Version 2.4.5f3, 2 service, 19 devices, 1 incoming serial ports Network Service: Ethernet, Ethernet, en0 Serial ATA Device: Hitachi HDE721010SLA330, 931.51 GB Serial ATA Device: OPTIARC DVD RW AD-5680H USB Device: Built-in iSight, 0x05ac (Apple Inc.), 0x8502, 0x24400000 / 2 USB Device: Internal Memory Card Reader, 0x05ac (Apple Inc.), 0x8403, 0x26500000 / 2 USB Device: IR Receiver, 0x05ac (Apple Inc.), 0x8242, 0x04500000 / 2 USB Device: BRCM2046 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0x06100000 / 2 USB Device: Bluetooth USB Host Controller, 0x05ac (Apple Inc.), 0x8215, 0x06110000 / 4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 02:16:29 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 00:16:29 +0000 Subject: [issue12599] Use 'is not None' where appropriate in importlib In-Reply-To: <1311204866.94.0.868144642715.issue12599@psf.upfronthosting.co.za> Message-ID: <1334708189.66.0.536934416124.issue12599@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 02:26:32 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 18 Apr 2012 00:26:32 +0000 Subject: [issue14575] IDLE crashes after file open in OS X In-Reply-To: <1334378092.39.0.081519751274.issue14575@psf.upfronthosting.co.za> Message-ID: <1334708792.12.0.49360889545.issue14575@psf.upfronthosting.co.za> Ned Deily added the comment: The crash dump confirms that the buggy Apple Tcl/Tk 8.5 frameworks are being used (/System/Library/Frameworks/Tk.framework/Versions/8.5/Tk). As I mentioned, the easiest solution is to install the most recent ActiveState Tcl/Tk 8.5. The python.org Python 2.7.3 will automatically use it if it is available at run time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 02:51:08 2012 From: report at bugs.python.org (Ned Deily) Date: Wed, 18 Apr 2012 00:51:08 +0000 Subject: [issue14575] IDLE crashes after file open in OS X In-Reply-To: <1334378092.39.0.081519751274.issue14575@psf.upfronthosting.co.za> Message-ID: <1334710268.31.0.133167205056.issue14575@psf.upfronthosting.co.za> Ned Deily added the comment: By the way, you should have been seeing a warning message in the IDLE shell window when using 2.7.3 with the buggy Apple Tcl/TK 8.5, telling you to check the information at http://www.python.org/download/mac/tcltk/. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 03:42:17 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 18 Apr 2012 01:42:17 +0000 Subject: [issue12599] Use 'is not None' where appropriate in importlib In-Reply-To: <1311204866.94.0.868144642715.issue12599@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset c1399cf7bd6a by Brett Cannon in branch 'default': Issue #12599: Be more strict in accepting None vs. a false-like object http://hg.python.org/cpython/rev/c1399cf7bd6a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 03:43:15 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 18 Apr 2012 01:43:15 +0000 Subject: [issue12599] Use 'is not None' where appropriate in importlib In-Reply-To: <1311204866.94.0.868144642715.issue12599@psf.upfronthosting.co.za> Message-ID: <1334713395.74.0.345621706118.issue12599@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 05:34:36 2012 From: report at bugs.python.org (Eduard) Date: Wed, 18 Apr 2012 03:34:36 +0000 Subject: [issue14608] Python 2.7.3 x86 msi - msvcr90.dll version mismatch In-Reply-To: <1334698287.56.0.0123105112026.issue14608@psf.upfronthosting.co.za> Message-ID: <1334720076.35.0.480671964575.issue14608@psf.upfronthosting.co.za> Eduard added the comment: I was reading about py2exe and found this old thread: https://groups.google.com/d/msg/wxpython-users/fwHt9zSbnsE/IV3aryIBrd8J I'm not familiar with C++ and redists and stuff, but I find it strange that the manifest from the Python folder requires a specific version, and the installed runtime is another version. Would it be ok if I'll just install the 9.0.30729.1 runtime by hand? Or any 9.0.30729.xxxx version is good enough? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 05:41:36 2012 From: report at bugs.python.org (Eduard) Date: Wed, 18 Apr 2012 03:41:36 +0000 Subject: [issue14608] Python 2.7.3 x86 msi - msvcr90.dll version mismatch In-Reply-To: <1334698287.56.0.0123105112026.issue14608@psf.upfronthosting.co.za> Message-ID: <1334720496.92.0.490717878565.issue14608@psf.upfronthosting.co.za> Eduard added the comment: There is a newer redist available: 9.0.30729.6161 from http://www.microsoft.com/download/en/details.aspx?id=26368 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 05:58:37 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 18 Apr 2012 03:58:37 +0000 Subject: [issue14609] can't modify sys.modules during import with importlib Message-ID: <1334721517.01.0.954208594605.issue14609@psf.upfronthosting.co.za> New submission from Benjamin Peterson : $ cat > x.py import sys sys.modules["x"] = 42 benjamin at localhost ~/dev/python/py3k $ python3 Python 3.2.2 (default, Feb 18 2012, 09:16:28) [GCC 4.5.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import x >>> x 42 $ ./python Python 3.3.0a2+ (default:6762b943ee59, Apr 17 2012, 23:57:13) [GCC 4.5.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import x >>> x It's not clear to me whether it's the loader's responsibilty to handle this or __import__. ---------- assignee: brett.cannon components: Interpreter Core messages: 158587 nosy: benjamin.peterson, brett.cannon priority: high severity: normal status: open title: can't modify sys.modules during import with importlib versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 06:48:21 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 18 Apr 2012 04:48:21 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1334724501.36.0.572156064832.issue3561@psf.upfronthosting.co.za> Brian Curtin added the comment: Here's a patch with better wording, and here's a screenshot of what the feature selection looks like with that text: http://i.imgur.com/k7e12.png ---------- Added file: http://bugs.python.org/file25255/issue3561_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 06:50:26 2012 From: report at bugs.python.org (Philip Jenvey) Date: Wed, 18 Apr 2012 04:50:26 +0000 Subject: [issue14609] can't modify sys.modules during import with importlib In-Reply-To: <1334721517.01.0.954208594605.issue14609@psf.upfronthosting.co.za> Message-ID: <1334724626.01.0.821866967397.issue14609@psf.upfronthosting.co.za> Philip Jenvey added the comment: __import__ needs the actual module on hand so it can e.g. attach it to its parent module ---------- nosy: +pjenvey _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 07:06:03 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 05:06:03 +0000 Subject: [issue14609] can't modify sys.modules during import with importlib In-Reply-To: <1334721517.01.0.954208594605.issue14609@psf.upfronthosting.co.za> Message-ID: <1334725563.46.0.700630671481.issue14609@psf.upfronthosting.co.za> Eric Snow added the comment: Loaders are in charge of adding the module to sys.modules (per PEP 302). importlib codifies this in the module_for_loader() decorator, which the default loaders use. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 07:12:41 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 05:12:41 +0000 Subject: [issue14609] can't modify sys.modules during import with importlib In-Reply-To: <1334721517.01.0.954208594605.issue14609@psf.upfronthosting.co.za> Message-ID: <1334725961.53.0.0499381725384.issue14609@psf.upfronthosting.co.za> Eric Snow added the comment: 3.3.0a2+: >>> import x >>> x >>> import sys >>> sys.modules['x'] 5 >>> x 5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 07:30:06 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 05:30:06 +0000 Subject: [issue14609] can't modify sys.modules during import with importlib In-Reply-To: <1334721517.01.0.954208594605.issue14609@psf.upfronthosting.co.za> Message-ID: <1334727006.21.0.124338259079.issue14609@psf.upfronthosting.co.za> Eric Snow added the comment: _find_and_load() in importlib._bootstrap returns whatever the loader returns, which is the new module object. The old code in import.c pulled it from sys.modules rather than using what the loader returned. In both cases the respective object is what eventually gets bound to the name in the eval loop. FWIW, the language reference says, "The first form of import statement binds the module name in the local namespace to the module object". This looks like a corner case where backwards-compatibility breaks (when we finally start enforcing the rules). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 07:51:58 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 05:51:58 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1334728318.57.0.228985278368.issue13959@psf.upfronthosting.co.za> Eric Snow added the comment: 2 "problems" with that last patch: * the types of the loaders that get returned by _bootstrap._find_module() are not the classes in _bootstrap (e.g. _frozen_importlib._SourceFileLoader). That doesn't smell right. * tokenize.get_encoding? is saying that Lib/test/badsyntax_pep3120.py has an encoding of utf-8, when test_find_module_encoding is expecting it to not. So does PyTokenizer_FindEncodingFilename (which the old import code used) behaving differently than tokenize.get_encoding()? FYI, tokenize.get_encoding() is what importlib uses... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 07:54:42 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 05:54:42 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1334728482.74.0.631784589005.issue13959@psf.upfronthosting.co.za> Eric Snow added the comment: rather, tokenize.detect_encoding() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 08:56:50 2012 From: report at bugs.python.org (Eduard) Date: Wed, 18 Apr 2012 06:56:50 +0000 Subject: [issue14608] Python 2.7.3 x86 msi - msvcr90.dll version mismatch In-Reply-To: <1334698287.56.0.0123105112026.issue14608@psf.upfronthosting.co.za> Message-ID: <1334732210.75.0.299437501298.issue14608@psf.upfronthosting.co.za> Eduard added the comment: OTOH, the manifest embedded in python.exe references version 9.0.21022.8 I'm going to delete Microsoft.VC90.CRT.manifest and msvcr90.dll from Python installation folder and postpone py2exe experiments a bit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 09:15:52 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 18 Apr 2012 07:15:52 +0000 Subject: [issue14608] Python 2.7.3 x86 msi - msvcr90.dll version mismatch In-Reply-To: <1334698287.56.0.0123105112026.issue14608@psf.upfronthosting.co.za> Message-ID: <1334733352.22.0.276463673947.issue14608@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Eduard: is all this causing *actual* problems? Any version should be fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 09:40:10 2012 From: report at bugs.python.org (Raphael Cruzeiro) Date: Wed, 18 Apr 2012 07:40:10 +0000 Subject: [issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu Message-ID: <1334734810.54.0.87567518387.issue14610@psf.upfronthosting.co.za> New submission from Raphael Cruzeiro : While installing Python 2.7.3 on my Ubuntu server the configure script hanged on the verification for pthread, I then proceded to alter the script to aways return true for pthread and it hanged again checking for PTHREAD_SCOPE_SYSTEM, which I also bypassed by altering the script and only then was I able to successfully install Python 2.7.3 ---------- components: Installation messages: 158597 nosy: Raphael.Cruzeiro priority: normal severity: normal status: open title: configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 10:15:04 2012 From: report at bugs.python.org (Eduard) Date: Wed, 18 Apr 2012 08:15:04 +0000 Subject: [issue14608] Python 2.7.3 x86 msi - msvcr90.dll version mismatch In-Reply-To: <1334698287.56.0.0123105112026.issue14608@psf.upfronthosting.co.za> Message-ID: <1334736904.92.0.0387245185268.issue14608@psf.upfronthosting.co.za> Eduard added the comment: > Any version should be fine. This is all I need to know. It's just one less place to check in case of troubles. Thank you for your time and patience. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 10:35:09 2012 From: report at bugs.python.org (Stefano Taschini) Date: Wed, 18 Apr 2012 08:35:09 +0000 Subject: [issue14611] inspect.getargs fails on some anonymous tuples Message-ID: <1334738109.2.0.700206080535.issue14611@psf.upfronthosting.co.za> New submission from Stefano Taschini : How to reproduce ---------------- Take the following two functions: >>> def f(l, (x, y)): ... sup = max(u*x + v*y for u, v in l) ... return ((u, v) for u, v in l if u*x + v*y == sup) >>> def g((x, y)): ... def h(): ... return x + y ... return h Inspect.getargs will throw an exception on the former and return a wrong result on the latter:: >>> import inspect >>> inspect.getargs(f.__code__) Traceback (most recent call last): ... IndexError: list index out of range >>> inspect.getargs(g.__code__) Arguments(args=['h'], varargs=None, keywords=None) # h is most definitely not an argument of g! Analysis -------- If you disassemble the two functions, you'll see that in both cases the anonymous tuples are unpacked using STORE_DEREF:: >>> import dis >>> dis.disassemble(f.__code__) 1 0 LOAD_FAST 1 (.1) 3 UNPACK_SEQUENCE 2 6 STORE_DEREF 0 (x) 9 STORE_DEREF 2 (y) 2 12 LOAD_GLOBAL 0 (max) ... >>> dis.disassemble(g.__code__) 1 0 LOAD_FAST 0 (.0) 3 UNPACK_SEQUENCE 2 6 STORE_DEREF 0 (x) 9 STORE_DEREF 1 (y) 2 12 LOAD_CLOSURE 1 (y) 15 LOAD_CLOSURE 0 (x) 18 BUILD_TUPLE 2 21 LOAD_CONST 1 () 24 MAKE_CLOSURE 0 27 STORE_FAST 3 (h) 4 30 LOAD_FAST 3 (h) 33 RETURN_VALUE \ However, the implementation of inspect.getargs only looks for UNPACK_TUPLE, UNPACK_SEQUENCE, STORE_FAST. Notes ----- The version of Python used is:: >>> import sys >>> sys.version_info[:3] (2, 7, 3) ---------- components: Library (Lib) messages: 158599 nosy: taschini priority: normal severity: normal status: open title: inspect.getargs fails on some anonymous tuples type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 10:55:01 2012 From: report at bugs.python.org (Stefano Taschini) Date: Wed, 18 Apr 2012 08:55:01 +0000 Subject: [issue12947] Examples in library/doctest.html lack the flags In-Reply-To: <1315588954.16.0.979263107509.issue12947@psf.upfronthosting.co.za> Message-ID: <1334739301.06.0.953247289767.issue12947@psf.upfronthosting.co.za> Stefano Taschini added the comment: Concrete examples can be seen in the section http://docs.python.org/library/doctest.html#option-flags-and-directives For instance at http://docs.python.org/library/doctest.html#doctest.IGNORE_EXCEPTION_DETAIL The doctest flags present in the sources in http://docs.python.org/_sources/library/doctest.txt are all stripped. ---------- nosy: +taschini _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 12:51:24 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 18 Apr 2012 10:51:24 +0000 Subject: [issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu In-Reply-To: <1334734810.54.0.87567518387.issue14610@psf.upfronthosting.co.za> Message-ID: <1334746284.97.0.369128838854.issue14610@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 12:51:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 18 Apr 2012 10:51:54 +0000 Subject: [issue14611] inspect.getargs fails on some anonymous tuples In-Reply-To: <1334738109.2.0.700206080535.issue14611@psf.upfronthosting.co.za> Message-ID: <1334746314.9.0.0668135036948.issue14611@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +michael.foord, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 13:13:14 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 18 Apr 2012 11:13:14 +0000 Subject: [issue14598] _cursesmodule.c fails with ncurses-5.9 on Linux In-Reply-To: <1334593853.62.0.710921461264.issue14598@psf.upfronthosting.co.za> Message-ID: <1334747594.74.0.633805387198.issue14598@psf.upfronthosting.co.za> STINNER Victor added the comment: You should remove the old code instead of comment it. +/* NOTE configure check if ncurses require such definition #define NCURSES_OPAQUE 0 +*/ +/* NOTE configure check for existence of flags + * Also flags are visible only if WINDOW structure is not opaque #ifndef WINDOW_HAS_FLAGS #define WINDOW_HAS_FLAGS 1 #endif +*/ ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 13:16:14 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 18 Apr 2012 11:16:14 +0000 Subject: [issue14606] Memory leak subprocess on Windows In-Reply-To: <1334689181.81.0.435135933783.issue14606@psf.upfronthosting.co.za> Message-ID: <1334747774.7.0.240759358899.issue14606@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't see any leak on Linux with Python 2.7 or Python 3.3. How much KB does subprocess leak per process? ---------- nosy: +haypo title: Memory leak subprocess -> Memory leak subprocess on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 13:20:32 2012 From: report at bugs.python.org (Massimiliano Tomassoli) Date: Wed, 18 Apr 2012 11:20:32 +0000 Subject: [issue14612] Crash after modifying f_lineno Message-ID: <1334748032.28.0.116760449462.issue14612@psf.upfronthosting.co.za> New submission from Massimiliano Tomassoli : Debugging script.py and jumping to line 3 makes Python crash. For instance: python -m pdb script.py (Pdb) j 3 ---------- components: Interpreter Core files: script.py messages: 158603 nosy: mtomassoli priority: normal severity: normal status: open title: Crash after modifying f_lineno versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file25256/script.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 13:20:58 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 18 Apr 2012 11:20:58 +0000 Subject: [issue14591] Value returned by random.random() out of valid range In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1334748058.32.0.334733049094.issue14591@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 13:22:27 2012 From: report at bugs.python.org (Massimiliano Tomassoli) Date: Wed, 18 Apr 2012 11:22:27 +0000 Subject: [issue14612] Crash after modifying f_lineno In-Reply-To: <1334748032.28.0.116760449462.issue14612@psf.upfronthosting.co.za> Message-ID: <1334748147.3.0.163598192948.issue14612@psf.upfronthosting.co.za> Changes by Massimiliano Tomassoli : ---------- type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 13:23:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 18 Apr 2012 11:23:05 +0000 Subject: [issue14612] Crash after modifying f_lineno In-Reply-To: <1334748032.28.0.116760449462.issue14612@psf.upfronthosting.co.za> Message-ID: <1334748185.61.0.971760186184.issue14612@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 13:41:48 2012 From: report at bugs.python.org (Roland) Date: Wed, 18 Apr 2012 11:41:48 +0000 Subject: [issue14606] Memory leak subprocess on Windows In-Reply-To: <1334689181.81.0.435135933783.issue14606@psf.upfronthosting.co.za> Message-ID: <1334749308.14.0.123783171011.issue14606@psf.upfronthosting.co.za> Roland added the comment: 20kb exactly, I can confirm it is only on Windows. I'm currently running some tests to make sure it isn't a general Windows problem. I'll post an update as soon as done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 13:48:49 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 18 Apr 2012 11:48:49 +0000 Subject: [issue14606] Memory leak subprocess on Windows In-Reply-To: <1334749308.14.0.123783171011.issue14606@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > 20kb exactly, I can confirm it is only on Windows. I'm currently running some tests to make sure it isn't a general Windows problem. I'll post an update as soon as done. Oh, that's a lot. Can you please also try with Python 3.2? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 13:54:08 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 18 Apr 2012 11:54:08 +0000 Subject: [issue14385] Support other types than dict for __builtins__ In-Reply-To: <1332380135.46.0.264363154256.issue14385@psf.upfronthosting.co.za> Message-ID: <1334750048.42.0.880786301025.issue14385@psf.upfronthosting.co.za> STINNER Victor added the comment: - assert(!builtins || PyDict_Check(builtins)); + assert(!builtins); Oops, the assert must be replaced with assert(builtins != NULL) -> fixed in patch version 4. ---------- Added file: http://bugs.python.org/file25257/builtins-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 14:00:11 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 18 Apr 2012 12:00:11 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1334704982.85.0.932146397233.issue14428@psf.upfronthosting.co.za> Message-ID: <4F8EACC5.3080806@egenix.com> Marc-Andre Lemburg added the comment: Please leave the pybench default timers unchanged in case the new APIs are not available. The perf_counter_process_time.patch currently changes them, even though the new APIs are not available on older Python releases, thus breaking pybench for e.g. Python 3.2 or earlier releases. Ditto for the resolution changes: these need to be optional and not cause a break when used in Python 3.1/3.2. Thanks, -- Marc-Andre Lemburg eGenix.com ________________________________________________________________________ 2012-04-28: PythonCamp 2012, Cologne, Germany 10 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 14:26:28 2012 From: report at bugs.python.org (Michael Foord) Date: Wed, 18 Apr 2012 12:26:28 +0000 Subject: [issue14613] time.time can return None or NaN Message-ID: <1334751988.35.0.313625977941.issue14613@psf.upfronthosting.co.za> New submission from Michael Foord : time.time() can return None, or sometimes NaN. If it can't get a "proper" value from the OS then I would expect it to throw an exception. The docs don't mention anything about error conditions. This was originally reported to Ubuntu One and there has been discussion / attempts to reproduce (it affects several people and so wasn't an isolated case): https://bugs.launchpad.net/ubuntu/+source/ubuntuone-control-panel/+bug/844435 The issue is that with the unexpected response from time.time(), a ValueError was caused later when converting the time: https://launchpadlibrarian.net/79283418/Traceback.txt Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/ubuntuone-control-panel/ubuntuone/controlpanel/web_client/libsoup.py", line 55, in _handler msg.status_code, msg.get_uri().to_string(False)) File "/usr/lib/python2.7/logging/__init__.py", line 1120, in debug self._log(DEBUG, msg, args, **kwargs) File "/usr/lib/python2.7/logging/__init__.py", line 1249, in _log record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info, func, extra) File "/usr/lib/python2.7/logging/__init__.py", line 1223, in makeRecord rv = LogRecord(name, level, fn, lno, msg, args, exc_info, func) File "/usr/lib/python2.7/logging/__init__.py", line 280, in __init__ self.msecs = (ct - long(ct)) * 1000 ValueError: cannot convert float NaN to integer ---------- assignee: haypo messages: 158608 nosy: haypo, michael.foord priority: normal severity: normal status: open title: time.time can return None or NaN _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 14:28:21 2012 From: report at bugs.python.org (Michael Foord) Date: Wed, 18 Apr 2012 12:28:21 +0000 Subject: [issue14613] time.time can return None or NaN In-Reply-To: <1334751988.35.0.313625977941.issue14613@psf.upfronthosting.co.za> Message-ID: <1334752101.65.0.0588790191998.issue14613@psf.upfronthosting.co.za> Changes by Michael Foord : ---------- stage: -> test needed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 14:30:32 2012 From: report at bugs.python.org (Michael Foord) Date: Wed, 18 Apr 2012 12:30:32 +0000 Subject: [issue14613] time.time can return None or NaN In-Reply-To: <1334751988.35.0.313625977941.issue14613@psf.upfronthosting.co.za> Message-ID: <1334752232.17.0.746379630215.issue14613@psf.upfronthosting.co.za> Changes by Michael Foord : ---------- versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 14:31:21 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 18 Apr 2012 12:31:21 +0000 Subject: [issue14613] time.time can return None or NaN In-Reply-To: <1334751988.35.0.313625977941.issue14613@psf.upfronthosting.co.za> Message-ID: <1334752281.07.0.0727479013551.issue14613@psf.upfronthosting.co.za> Mark Dickinson added the comment: Issue 14028 is related. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 14:32:00 2012 From: report at bugs.python.org (Roman) Date: Wed, 18 Apr 2012 12:32:00 +0000 Subject: [issue14613] time.time can return None or NaN In-Reply-To: <1334751988.35.0.313625977941.issue14613@psf.upfronthosting.co.za> Message-ID: <1334752320.06.0.65855900342.issue14613@psf.upfronthosting.co.za> Changes by Roman : ---------- nosy: +rye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 14:47:59 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 18 Apr 2012 12:47:59 +0000 Subject: [issue14611] inspect.getargs fails on some anonymous tuples In-Reply-To: <1334738109.2.0.700206080535.issue14611@psf.upfronthosting.co.za> Message-ID: <1334753279.4.0.377868117556.issue14611@psf.upfronthosting.co.za> R. David Murray added the comment: Formal parameter tuple unpacking was removed in Python3, so this is a Python2-only issue. Would you like to submit a patch for Python2? ---------- nosy: +r.david.murray priority: normal -> low stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 14:48:50 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 18 Apr 2012 12:48:50 +0000 Subject: [issue14613] time.time can return None or NaN In-Reply-To: <1334751988.35.0.313625977941.issue14613@psf.upfronthosting.co.za> Message-ID: <1334753330.91.0.347368727965.issue14613@psf.upfronthosting.co.za> Martin v. L?wis added the comment: What exact version of Python was used? What's the complete list of patches that was applied to this Python version? As discussed in #14028, this behavior doesn't correspond to the code at all. So hardware error, compiler error, and downstream patches are likely sources of the problem. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 14:49:52 2012 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Wed, 18 Apr 2012 12:49:52 +0000 Subject: [issue14590] ConfigParser doesn't strip inline comment when delimiter occurs earlier without preceding space. In-Reply-To: <1334541468.07.0.833607995836.issue14590@psf.upfronthosting.co.za> Message-ID: <1334753392.84.0.563241010339.issue14590@psf.upfronthosting.co.za> ?ukasz Langa added the comment: While this bug is real, I'm hesitant to fix it for 2.7 and 3.2. I can imagine someone using the current behaviour unintentionally, and getting burned by the fix. This would be a real PITA to debug. Is it fine by you if I just fix it for 3.3 and update the backport? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 14:51:13 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 18 Apr 2012 12:51:13 +0000 Subject: [issue14612] Crash after modifying f_lineno In-Reply-To: <1334748032.28.0.116760449462.issue14612@psf.upfronthosting.co.za> Message-ID: <1334753473.32.0.229745766815.issue14612@psf.upfronthosting.co.za> R. David Murray added the comment: For reference, here is the crash: rdmurray at hey:~/python/p33>./python -m pdb script.py > /home/rdmurray/python/p33/script.py(1)() -> with open('test') as f: (Pdb) j 3 python: Objects/frameobject.c:207: frame_setlineno: Assertion `blockstack_top > 0' failed. zsh: abort ./python -m pdb script.py ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 14:57:17 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 18 Apr 2012 12:57:17 +0000 Subject: [issue14609] can't modify sys.modules during import with importlib In-Reply-To: <1334721517.01.0.954208594605.issue14609@psf.upfronthosting.co.za> Message-ID: <1334753837.71.0.770863538685.issue14609@psf.upfronthosting.co.za> Benjamin Peterson added the comment: This is a really important usecase for many packages including py.test and twisted, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 14:58:08 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 18 Apr 2012 12:58:08 +0000 Subject: [issue14613] time.time can return None or NaN In-Reply-To: <1334751988.35.0.313625977941.issue14613@psf.upfronthosting.co.za> Message-ID: <1334753888.3.0.257360506338.issue14613@psf.upfronthosting.co.za> STINNER Victor added the comment: > time.time() can return None, or sometimes NaN It is possible that it returns NaN, but it cannot return None. time.time() implementation of Python 2.7: static PyObject * time_time(PyObject *self, PyObject *unused) { double secs; secs = floattime(); if (secs == 0.0) { PyErr_SetFromErrno(PyExc_IOError); return NULL; } return PyFloat_FromDouble(secs); } FYI I removed the (secs == 0.0) check in Python 3.3 (issue #14368, changeset 206c45f45236), it was a bug. time.time() *cannot* fail, it always return a float. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 15:07:09 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 18 Apr 2012 13:07:09 +0000 Subject: [issue14612] Crash after modifying f_lineno In-Reply-To: <1334748032.28.0.116760449462.issue14612@psf.upfronthosting.co.za> Message-ID: <1334754429.9.0.0489127514614.issue14612@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- assignee: -> benjamin.peterson nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 15:12:28 2012 From: report at bugs.python.org (Michael Foord) Date: Wed, 18 Apr 2012 13:12:28 +0000 Subject: [issue14613] time.time can return None or NaN In-Reply-To: <1334751988.35.0.313625977941.issue14613@psf.upfronthosting.co.za> Message-ID: <1334754748.35.0.220461179397.issue14613@psf.upfronthosting.co.za> Michael Foord added the comment: So NaN is a possible result from time.time()? Perhaps that should be mentioned in the docs. Is returning NaN preferable to failing with an exception? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 15:14:26 2012 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 18 Apr 2012 13:14:26 +0000 Subject: [issue14613] time.time can return None or NaN In-Reply-To: <1334751988.35.0.313625977941.issue14613@psf.upfronthosting.co.za> Message-ID: <1334754866.07.0.680253122123.issue14613@psf.upfronthosting.co.za> Mark Dickinson added the comment: > It is possible that it returns NaN How is that possible? I can't see any way that the Python 2.7 implementation of floattime could return a NaN. In each case, floattime appears to be extracting integer fields from some suitable struct, and then combining them to produce a double; I can't see any scope for producing a NaN in any of the formulas used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 15:23:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 18 Apr 2012 13:23:48 +0000 Subject: [issue14371] Add support for bzip2 compression to the zipfile module In-Reply-To: <1332243041.43.0.499117498297.issue14371@psf.upfronthosting.co.za> Message-ID: <1334755428.26.0.697893413736.issue14371@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > `buf += data` is noticeably faster `b''.join()` in CPython. Perhaps because your system's memory allocator is extremely good (or buf is always very small), but b''.join() is far more robust. Another alternative is accumulating in a bytearray, since it uses overallocation for linear time appending. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 15:37:14 2012 From: report at bugs.python.org (Peter Otten) Date: Wed, 18 Apr 2012 13:37:14 +0000 Subject: [issue14612] Crash after modifying f_lineno In-Reply-To: <1334748032.28.0.116760449462.issue14612@psf.upfronthosting.co.za> Message-ID: <1334756234.86.0.720988728462.issue14612@psf.upfronthosting.co.za> Peter Otten <__peter__ at web.de> added the comment: frame_setlineno() doesn't keep track of with blocks. Here's a patch. ---------- keywords: +patch nosy: +potten Added file: http://bugs.python.org/file25258/frame_setlineno.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 15:52:08 2012 From: report at bugs.python.org (Stefano Taschini) Date: Wed, 18 Apr 2012 13:52:08 +0000 Subject: [issue14611] inspect.getargs fails on some anonymous tuples In-Reply-To: <1334738109.2.0.700206080535.issue14611@psf.upfronthosting.co.za> Message-ID: <1334757128.04.0.514072214504.issue14611@psf.upfronthosting.co.za> Stefano Taschini added the comment: I'll give it a try. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 15:52:24 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 18 Apr 2012 13:52:24 +0000 Subject: [issue12947] Examples in library/doctest.html lack the flags In-Reply-To: <1315588954.16.0.979263107509.issue12947@psf.upfronthosting.co.za> Message-ID: <1334757144.39.0.1751632519.issue12947@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thank you. I think it?s clear that for the docs of the doctest flags we need to display snippets with the flags. ---------- resolution: invalid -> stage: committed/rejected -> test needed status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 16:25:40 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 18 Apr 2012 14:25:40 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1334759140.74.0.429846647846.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: You could change Lib/imp.py to have ``import _frozen_importlib as _bootstrap`` if you want the same modules coming from imp, but I would argue against changing importlib itself being changed as that complicates development since if you screw up importlib._bootstrap when you compile it becomes a major pain to revert the importlib.h change, recompile, and continue to do that until you get it right. Plus you would only care about this if you are doing isinstance() checks on what kind of loader you have which you shouldn't care about since we have clearly defined ABCs to test against. As for Lib/test/badsyntax_pep3120.py, it *does* have a source encoding of UTF-8 since it does not explicitly specify an encoding. Based on the name I'm assuming the file itself has bad UTF-8 characters, but that doesn't mean that the file is not supposed to be interpreted as UTF-8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 16:27:32 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 14:27:32 +0000 Subject: [issue14609] can't modify sys.modules during import with importlib In-Reply-To: <1334721517.01.0.954208594605.issue14609@psf.upfronthosting.co.za> Message-ID: <1334759252.49.0.483910827293.issue14609@psf.upfronthosting.co.za> Eric Snow added the comment: that's a pretty sneaky hack, but I can see the (weak) point of it. So, to keep backward compatibility, importlib._bootstrap._find_and_load() would have to return sys.modules[fullname] instead of the module returned by loader.load_module(fullname). My inclination is to break the backward compatibility and work with py.test/twisted/etc. to set things right. If we don't, then we should consider changing the spec of the import statement in the language reference. The hash randomization case for breaking backward compatibility relied on "everyone know better" and "there aren't any big use cases" (for dependence on dict key order). Here it's not so cut and dry. Still, it seems like a candidate for breaking "backward compatibility", as long as the (legitimate) alternative is easy and a faithful substitute. I was considering bringing this up on python-dev, but I'd rather hear Brett's point of view first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 16:29:20 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 18 Apr 2012 14:29:20 +0000 Subject: [issue14609] can't modify sys.modules during import with importlib In-Reply-To: <1334721517.01.0.954208594605.issue14609@psf.upfronthosting.co.za> Message-ID: <1334759360.33.0.760018900428.issue14609@psf.upfronthosting.co.za> Brett Cannon added the comment: I honestly don't care enough to argue over this one (I was trying to save a dict lookup but unfortunately too many people have codified the behaviour already). Just revert http://hg.python.org/cpython/rev/005fd1fe31ab to get back the original behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 16:32:26 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 18 Apr 2012 14:32:26 +0000 Subject: [issue14609] can't modify sys.modules during import with importlib In-Reply-To: <1334721517.01.0.954208594605.issue14609@psf.upfronthosting.co.za> Message-ID: <1334759546.52.0.00295882537847.issue14609@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I would advocate breaking any compatability. In fact, I think it can be documented. This is a useful feature, and not hard to maintain. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 16:34:16 2012 From: report at bugs.python.org (Berker Peksag) Date: Wed, 18 Apr 2012 14:34:16 +0000 Subject: [issue14585] Have test_import run more importlib tests In-Reply-To: <1334453245.9.0.0799360762368.issue14585@psf.upfronthosting.co.za> Message-ID: <1334759656.95.0.340713923367.issue14585@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 16:42:58 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 14:42:58 +0000 Subject: [issue14609] can't modify sys.modules during import with importlib In-Reply-To: <1334721517.01.0.954208594605.issue14609@psf.upfronthosting.co.za> Message-ID: <1334760178.66.0.438012087269.issue14609@psf.upfronthosting.co.za> Eric Snow added the comment: > I would advocate breaking any compatability. Did you mean "against breaking any compatability"? The problem is that it's just one more sticky little detail that adds to the complexity of understanding the import system. It's things like this that turn people off to diving into hacking imports (for better or worse ). I'm fine with maintaining the status quo, as Nick would say, and documenting the behavior. But I don't have to like it! ;) -eric ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 16:44:47 2012 From: report at bugs.python.org (Roland) Date: Wed, 18 Apr 2012 14:44:47 +0000 Subject: [issue14606] Memory leak subprocess on Windows In-Reply-To: <1334689181.81.0.435135933783.issue14606@psf.upfronthosting.co.za> Message-ID: <1334760287.14.0.453429078397.issue14606@psf.upfronthosting.co.za> Roland added the comment: Yes, ok, my sincere apologies, I should've tested more thoroughly before filing a report here. It seems to be a Windows problem. I could replicate the issue using a batch script (and Python 3.2 for that matter). I'm still in the dark about what it causes, but here's a more detailed problem description for those interested. http://tinyurl.com/cgbf4u2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 16:49:29 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 14:49:29 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1334760569.85.0.59210811731.issue13959@psf.upfronthosting.co.za> Eric Snow added the comment: On the _frozen_importlib point, I'm fine with that. It was just counter-intuitive that the importlib._bootstrap functions were returning loaders whose classes weren't also defined there. I'll have another look at that test tonight and run the patch through the full test suite, but otherwise I think find_module() is basically done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 16:52:29 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 18 Apr 2012 14:52:29 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1334760749.69.0.743898523397.issue10142@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- hgrepos: +119 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 16:52:54 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 18 Apr 2012 14:52:54 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1334760774.77.0.501905942548.issue10142@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Removed file: http://bugs.python.org/file19566/z.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 16:54:03 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 18 Apr 2012 14:54:03 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1334760843.66.0.470429734103.issue10142@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Added file: http://bugs.python.org/file25259/d6aeff63fa5e.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 16:55:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 18 Apr 2012 14:55:52 +0000 Subject: [issue14582] Have importlib use return value from a loader's load_module() In-Reply-To: <1334435501.08.0.930274319662.issue14582@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset db5e3431ee4c by Benjamin Peterson in branch 'default': rollback 005fd1fe31ab (see #14609 and #14582) http://hg.python.org/cpython/rev/db5e3431ee4c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 16:55:57 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 18 Apr 2012 14:55:57 +0000 Subject: [issue14609] can't modify sys.modules during import with importlib In-Reply-To: <1334721517.01.0.954208594605.issue14609@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset db5e3431ee4c by Benjamin Peterson in branch 'default': rollback 005fd1fe31ab (see #14609 and #14582) http://hg.python.org/cpython/rev/db5e3431ee4c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 16:56:12 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 18 Apr 2012 14:56:12 +0000 Subject: [issue14609] can't modify sys.modules during import with importlib In-Reply-To: <1334721517.01.0.954208594605.issue14609@psf.upfronthosting.co.za> Message-ID: <1334760972.59.0.259239175944.issue14609@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 17:00:08 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 18 Apr 2012 15:00:08 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1334761208.69.0.314612273622.issue10142@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Removed file: http://bugs.python.org/file25259/d6aeff63fa5e.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 17:00:36 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 18 Apr 2012 15:00:36 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1334761236.53.0.369524517209.issue10142@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Added file: http://bugs.python.org/file25260/3f967e00e267.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 17:02:55 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 18 Apr 2012 15:02:55 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1334761375.61.0.618463622408.issue10142@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Victor, internally Python uses 0, 1 and 2 as wired values independently of the platform values. This is probably an historic accident. Please, review. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 17:03:34 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 18 Apr 2012 15:03:34 +0000 Subject: [issue14614] PyTuple_SET_ITEM could check bounds in debug mode Message-ID: <1334761414.21.0.756614621806.issue14614@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Which it doesn't, as exemplified in e8c87226bcb3 :-) ---------- components: Interpreter Core messages: 158632 nosy: benjamin.peterson, ncoghlan, pitrou priority: low severity: normal status: open title: PyTuple_SET_ITEM could check bounds in debug mode type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 17:23:11 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 18 Apr 2012 15:23:11 +0000 Subject: [issue14614] PyTuple_SET_ITEM could check bounds in debug mode In-Reply-To: <1334761414.21.0.756614621806.issue14614@psf.upfronthosting.co.za> Message-ID: <1334762591.25.0.194316481343.issue14614@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Also, PyList_SET_ITEM and friends. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 17:24:41 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 18 Apr 2012 15:24:41 +0000 Subject: [issue14612] Crash after modifying f_lineno In-Reply-To: <1334748032.28.0.116760449462.issue14612@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 6a0a073e8461 by Benjamin Peterson in branch '3.2': SETUP_WITH acts like SETUP_FINALLY for the purposes of setting f_lineno (closes #14612) http://hg.python.org/cpython/rev/6a0a073e8461 New changeset 0695f5d028a7 by Benjamin Peterson in branch 'default': merge 3.2 (#14612) http://hg.python.org/cpython/rev/0695f5d028a7 New changeset 67be12ab8948 by Benjamin Peterson in branch '2.7': SETUP_WITH acts like SETUP_FINALLY for the purposes of setting f_lineno (closes #14612) http://hg.python.org/cpython/rev/67be12ab8948 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 17:34:44 2012 From: report at bugs.python.org (Hugh Gibbons) Date: Wed, 18 Apr 2012 15:34:44 +0000 Subject: [issue14575] IDLE crashes after file open in OS X In-Reply-To: <1334708792.12.0.49360889545.issue14575@psf.upfronthosting.co.za> Message-ID: <000001cd1d78$c5b0ed00$5112c700$@com> Hugh Gibbons added the comment: Thanks. I will try that and see if everything is OK with the updated Tcl/Tk. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 18:29:57 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 16:29:57 +0000 Subject: [issue12633] sys.modules doc entry should reflect restrictions In-Reply-To: <1311569390.98.0.906064511142.issue12633@psf.upfronthosting.co.za> Message-ID: <1334766597.04.0.551720613775.issue12633@psf.upfronthosting.co.za> Eric Snow added the comment: The original motivator: http://mail.python.org/pipermail/python-dev/2011-July/112497.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 18:32:28 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 16:32:28 +0000 Subject: [issue12598] Move sys variable initialization from import.c to sysmodule.c In-Reply-To: <1311204284.83.0.766064550687.issue12598@psf.upfronthosting.co.za> Message-ID: <1334766748.63.0.155552707338.issue12598@psf.upfronthosting.co.za> Eric Snow added the comment: The patch is out of date, but the question is still somewhat applicable. ---------- versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 18:32:42 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 16:32:42 +0000 Subject: [issue14615] pull some import state out of the interpreter state Message-ID: <1334766762.33.0.320325938554.issue14615@psf.upfronthosting.co.za> New submission from Eric Snow : Once the dust clears from the issue 2377 and issue 13959, we should consider what import-state-related members of PyInterpreterState (Include/pystate.h) can be removed. This is in the interest of simplifying the interpreter state. The most straightforward candidate is 'modules_reloading' (since reload() will likely become pure python), but we'll have to make sure we do not introduce any race conditions. Another candidate that could probably go away, regardless of the import work, is 'modules_by_index'. As far as I can see, there is only one use of interp->modules_by_index in the cpython code-base: PyState_FindModule() in Python/pystate.c. Likewise there is only one use of PyState_FindModule(): atexit_callfuncs() in Modules/atexitmodule.c. Ultimately I'd love it if modules were also removed from the interpreter state, but doing that is not so cut-and-dry. ---------- components: Interpreter Core messages: 158638 nosy: brett.cannon, eric.snow priority: normal severity: normal status: open title: pull some import state out of the interpreter state versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 18:34:16 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 16:34:16 +0000 Subject: [issue12633] sys.modules doc entry should reflect restrictions In-Reply-To: <1311569390.98.0.906064511142.issue12633@psf.upfronthosting.co.za> Message-ID: <1334766856.25.0.109424863322.issue12633@psf.upfronthosting.co.za> Eric Snow added the comment: also, issue 14615 is related to making sys.modules authoritative. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 18:48:01 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 18 Apr 2012 16:48:01 +0000 Subject: [issue14615] pull some import state out of the interpreter state In-Reply-To: <1334766762.33.0.320325938554.issue14615@psf.upfronthosting.co.za> Message-ID: <1334767681.12.0.804454959737.issue14615@psf.upfronthosting.co.za> Brett Cannon added the comment: So PyState_FindModule() is an (undocumented) part of the public API, which means that it has to somehow be supported to keep ABI compatibility (unless I am reading PEP 384 incorrectly). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 19:12:37 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 18 Apr 2012 17:12:37 +0000 Subject: [issue14616] subprocess docs should mention pipes.quote/shlex.quote Message-ID: <1334769157.78.0.557014485739.issue14616@psf.upfronthosting.co.za> New submission from ?ric Araujo : The warning at http://docs.python.org/library/subprocess#frequently-used-arguments should IMO recommend using shlex.quote. Even if it strongly advises against using shell=True, there are people who need or want to use it, so let?s give them a pointer to the quote function. For older versions, I think we should talk about pipes.quote; even if it?s not documented in library/pipes, it is there, it is known and it is used, so I see no harm in mentioning it (with due mention that it?s only semi-official and that it becomes public in 3.3). ---------- assignee: docs at python components: Documentation messages: 158641 nosy: docs at python, eric.araujo priority: normal severity: normal status: open title: subprocess docs should mention pipes.quote/shlex.quote versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 19:13:06 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 18 Apr 2012 17:13:06 +0000 Subject: [issue9723] Add shlex.quote In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za> Message-ID: <1334769186.87.0.947552088849.issue9723@psf.upfronthosting.co.za> ?ric Araujo added the comment: See #14616 for a doc edition related to this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 19:54:17 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 17:54:17 +0000 Subject: [issue14615] pull some import state out of the interpreter state In-Reply-To: <1334766762.33.0.320325938554.issue14615@psf.upfronthosting.co.za> Message-ID: <1334771657.92.0.353903332037.issue14615@psf.upfronthosting.co.za> Eric Snow added the comment: Curse you, undocumented API that we have to support! It could still wrap a simple get() on sys.modules, roughly like this: PyObject* PyState_FindModule(struct PyModuleDef* m) { PyObject* modules, module; modules = PyImport_GetModuleDict(); if (modules == NULL) return NULL; module = PyDict_GetItemString(sys_modules, m->m_name); return module==Py_None ? NULL : module; } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 19:55:28 2012 From: report at bugs.python.org (Ethan Furman) Date: Wed, 18 Apr 2012 17:55:28 +0000 Subject: [issue14617] confusing docs with regard to __hash__ Message-ID: <1334771728.14.0.513778784524.issue14617@psf.upfronthosting.co.za> New submission from Ethan Furman : >From http://docs.python.org/py3k/reference/datamodel.html#object.__hash__ ----------------------------------------------------------------------- Classes which inherit a __hash__() method from a parent class but change the meaning of __eq__() such that the hash value returned is no longer appropriate (e.g. by switching to a value-based concept of equality instead of the default identity based equality) can explicitly flag themselves as being unhashable by setting __hash__ = None in the class definition. Doing so means that not only will instances of the class raise an appropriate TypeError when a program attempts to retrieve their hash value, but they will also be correctly identified as unhashable when checking isinstance(obj, collections.Hashable) (unlike classes which define their own __hash__() to explicitly raise TypeError). If a class that overrides __eq__() needs to retain the implementation of __hash__() from a parent class, the interpreter must be told this explicitly by setting __hash__ = .__hash__. Otherwise the inheritance of __hash__() will be blocked, just as if __hash__ had been explicitly set to None. ----------------------------------------------------------------------- The first paragraph says the user has to change __hash__ if it's different because of changes to __eq__, the second paragraph says __hash__ is automatically removed if __eq__ is changed; the second paragraph reflects reality. Proposed change: ----------------------------------------------------------------------- Classes which change the meaning of __eq__() (thus losing automatic delegation to the parent class' __hash__) can explicitly flag themselves as being unhashable by setting __hash__ = None in the class definition (which is otherwise done implicity). Having __hash__ set to None, either explicitly or implicitly, means that not only will instances of the class raise an appropriate TypeError when a program attempts to retrieve their hash value, but they will also be correctly identified as unhashable when checking isinstance(obj, collections.Hashable) (unlike classes which define their own __hash__() to explicitly raise TypeError). If a class that overrides __eq__() needs to retain the implementation of __hash__() from a parent class, the interpreter must be told this explicitly by setting __hash__ = .__hash__. ----------------------------------------------------------------------- Patch attached. ---------- assignee: docs at python components: Documentation, Interpreter Core files: __hash__.diff keywords: patch messages: 158644 nosy: docs at python, stoneleaf priority: normal severity: normal status: open title: confusing docs with regard to __hash__ type: behavior versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25261/__hash__.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 20:16:44 2012 From: report at bugs.python.org (Joe Peterson) Date: Wed, 18 Apr 2012 18:16:44 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1334773004.66.0.456771820987.issue10941@psf.upfronthosting.co.za> Joe Peterson added the comment: It's been over a year since any activity on this bug, and it is still in the "patch review" stage. Any news? Anything else I can provide to help to get this moved to the next stage? Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 20:26:52 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 18 Apr 2012 18:26:52 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1334773612.01.0.384517360257.issue10941@psf.upfronthosting.co.za> R. David Murray added the comment: Someone needs to find time to review it. You could try recruiting reviewers on python-list. Anyone can do a review. Obviously the more knowledge they have in this area the better, but any good review is likely to move the issue along. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 20:43:07 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 18 Apr 2012 18:43:07 +0000 Subject: [issue14615] pull some import state out of the interpreter state In-Reply-To: <1334766762.33.0.320325938554.issue14615@psf.upfronthosting.co.za> Message-ID: <1334774587.03.0.394452993915.issue14615@psf.upfronthosting.co.za> Brett Cannon added the comment: Right, so the question is why wasn't that done in the first place? Who decided this modules_by_index concept was even worth it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 20:52:23 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 18 Apr 2012 18:52:23 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f3a27d11101a by Antoine Pitrou in branch 'default': Issue #11750: The Windows API functions scattered in the _subprocess and http://hg.python.org/cpython/rev/f3a27d11101a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 20:53:10 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 18 Apr 2012 18:53:10 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: <1334775190.53.0.171353122882.issue11750@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks a lot for doing this! Patch now committed to 3.3 (after testing under Windows 7 64 bits). ---------- assignee: brian.curtin -> components: -Windows resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 20:53:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 18 Apr 2012 18:53:40 +0000 Subject: [issue11750] Mutualize win32 functions In-Reply-To: <1301856629.83.0.865133251957.issue11750@psf.upfronthosting.co.za> Message-ID: <1334775220.85.0.95747533842.issue11750@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- components: +Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 20:55:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 18 Apr 2012 18:55:09 +0000 Subject: [issue14615] pull some import state out of the interpreter state In-Reply-To: <1334766762.33.0.320325938554.issue14615@psf.upfronthosting.co.za> Message-ID: <1334775309.69.0.378667951871.issue14615@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 21:13:43 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 18 Apr 2012 19:13:43 +0000 Subject: [issue14617] confusing docs with regard to __hash__ In-Reply-To: <1334771728.14.0.513778784524.issue14617@psf.upfronthosting.co.za> Message-ID: <1334776423.05.0.0260660152578.issue14617@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- versions: +Python 2.7 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 21:17:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 18 Apr 2012 19:17:09 +0000 Subject: [issue12598] Move sys variable initialization from import.c to sysmodule.c In-Reply-To: <1311204284.83.0.766064550687.issue12598@psf.upfronthosting.co.za> Message-ID: <1334776629.15.0.534918431721.issue12598@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This looks sensible. ---------- components: +Interpreter Core nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 21:30:05 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 18 Apr 2012 19:30:05 +0000 Subject: [issue14617] confusing docs with regard to __hash__ In-Reply-To: <1334771728.14.0.513778784524.issue14617@psf.upfronthosting.co.za> Message-ID: <1334777405.07.0.146200683659.issue14617@psf.upfronthosting.co.za> ?ric Araujo added the comment: Some of the sentence phrasing still sounds a bit awkward to me (?[...], means that not only will instances? for example, and I would also remove the parens at the end), but globally I think this is an improvement. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 21:32:29 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 18 Apr 2012 19:32:29 +0000 Subject: [issue14615] pull some import state out of the interpreter state In-Reply-To: <1334766762.33.0.320325938554.issue14615@psf.upfronthosting.co.za> Message-ID: <4F8F16CB.5040204@v.loewis.de> Martin v. L?wis added the comment: > Another candidate that could probably go away, regardless of the > import work, is 'modules_by_index'. As far as I can see, there is > only one use of interp->modules_by_index in the cpython code-base: > PyState_FindModule() in Python/pystate.c. Likewise there is only one > use of PyState_FindModule(): atexit_callfuncs() in > Modules/atexitmodule.c. There will be certainly many more uses of PySteate_FindModule in the future. I fail to see what is gained by this kind of change, and am firmly -1 on removing variables arbitrarily. ---------- title: pull some import state out of the interpreter state -> pull some import state out of the interpreter state _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 21:33:54 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 18 Apr 2012 19:33:54 +0000 Subject: [issue12598] Move sys variable initialization from import.c to sysmodule.c In-Reply-To: <1311204284.83.0.766064550687.issue12598@psf.upfronthosting.co.za> Message-ID: <1334777634.59.0.739927008477.issue12598@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I don't see the point. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 22:06:21 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 18 Apr 2012 20:06:21 +0000 Subject: [issue8536] Support new features of ZLIB 1.2.4 In-Reply-To: <1272302591.08.0.11918516326.issue8536@psf.upfronthosting.co.za> Message-ID: <1334779581.64.0.602872509925.issue8536@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Nadeem Vawda: > Jes?s, did you have any particular idea about exactly where these new > features would be useful? Or was your idea that someone needs to read > through the code and check whether the features can be used at all? Yes, my idea was for somebody to evaluate new features in ZLIB and make them accessible from Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 22:06:45 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 18 Apr 2012 20:06:45 +0000 Subject: [issue8536] Support new features of ZLIB 1.2.6 In-Reply-To: <1272302591.08.0.11918516326.issue8536@psf.upfronthosting.co.za> Message-ID: <1334779605.83.0.646495398846.issue8536@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- title: Support new features of ZLIB 1.2.4 -> Support new features of ZLIB 1.2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 22:08:03 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 18 Apr 2012 20:08:03 +0000 Subject: [issue14518] Add bcrypt $2a$ to crypt.py In-Reply-To: <1333741347.69.0.597224923936.issue14518@psf.upfronthosting.co.za> Message-ID: <1334779683.39.0.654989415045.issue14518@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 22:09:17 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 18 Apr 2012 20:09:17 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1334779757.31.0.365996132264.issue14596@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 22:13:21 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 18 Apr 2012 20:13:21 +0000 Subject: [issue14601] PEP sources not available as documented In-Reply-To: <1334612466.63.0.59561167474.issue14601@psf.upfronthosting.co.za> Message-ID: <1334780001.63.0.466403842439.issue14601@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 22:20:53 2012 From: report at bugs.python.org (Pauli Rikula) Date: Wed, 18 Apr 2012 20:20:53 +0000 Subject: [issue9030] ctypes variable limits In-Reply-To: <1276892210.09.0.679201213154.issue9030@psf.upfronthosting.co.za> Message-ID: <1334780453.95.0.623401851653.issue9030@psf.upfronthosting.co.za> Pauli Rikula added the comment: This enchantment overlaps with sys -module's sys.float_info (new in 2.6) and sys.long_info (new in 2.7). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 22:22:18 2012 From: report at bugs.python.org (Jon Oberheide) Date: Wed, 18 Apr 2012 20:22:18 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334780538.29.0.212998514403.issue14532@psf.upfronthosting.co.za> Jon Oberheide added the comment: v3 patch, based on feedback from the review here: http://bugs.python.org/review/14532/show ---------- Added file: http://bugs.python.org/file25262/hmac-time-independent-v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 22:26:21 2012 From: report at bugs.python.org (sbt) Date: Wed, 18 Apr 2012 20:26:21 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1334780781.2.0.818647827457.issue14310@psf.upfronthosting.co.za> sbt added the comment: Can this issue be reclosed now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 22:29:37 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 18 Apr 2012 20:29:37 +0000 Subject: [issue14310] Socket duplication for windows In-Reply-To: <1331775486.86.0.119356098147.issue14310@psf.upfronthosting.co.za> Message-ID: <1334780977.77.0.70925667187.issue14310@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 22:34:49 2012 From: report at bugs.python.org (Ethan Furman) Date: Wed, 18 Apr 2012 20:34:49 +0000 Subject: [issue14617] confusing docs with regard to __hash__ In-Reply-To: <1334776423.1.0.0212691003677.issue14617@psf.upfronthosting.co.za> Message-ID: <4F8F27A8.206@stoneleaf.us> Ethan Furman added the comment: ?ric Araujo wrote: > Changes by ?ric Araujo : > > > ---------- > versions: +Python 2.7 -Python 3.1 The docs for 2.7 are correct, as __hash__ is not automatically suppressed in that version. -- ~Ethan~ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 22:42:28 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 20:42:28 +0000 Subject: [issue14615] pull some import state out of the interpreter state In-Reply-To: <1334766762.33.0.320325938554.issue14615@psf.upfronthosting.co.za> Message-ID: <1334781748.99.0.166942014228.issue14615@psf.upfronthosting.co.za> Eric Snow added the comment: Sorry, Martin, for not looking at PEP 3121 before. I was thinking modules_by_index was a lot older. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 22:50:33 2012 From: report at bugs.python.org (Daniel Urban) Date: Wed, 18 Apr 2012 20:50:33 +0000 Subject: [issue14588] PEP 3115 compliant dynamic class creation In-Reply-To: <1334535798.87.0.826104374353.issue14588@psf.upfronthosting.co.za> Message-ID: <1334782233.71.0.211046947511.issue14588@psf.upfronthosting.co.za> Daniel Urban added the comment: I've attached a patch with more tests. I simply copied and modified the tests about metaclass calculation and __prepare__ in test_descr.py, to create the tested classes with operator.build_class (and not the class statement). Although, there is one thing I'm not sure I like about the API in the current patch: the dictionary corresponding to the keyword arguments of the class statement cannot be passed as keyword arguments. For example, I can't write this: C = operator.build_class('C', (A, B), metaclass=MyMeta) I have to write this: C = operator.build_class('C', (A, B), {'metaclass': MyMeta}) (The reason for this is that the eval_body argument is the last.) What would you think about the following signature for build_class? build_class(name, bases=(), eval_body=None, **kwargs) The fist 3 argument could be positional only, and all keyword arguments would go into the dict. A downside is that the user would have to explicitly pass None as the 3rd argument, if they don't need an eval_body, but need keyword-arguments. Also, the 'bases' and the keyword arguments wouldn't be close to each other as in the class statement... ---------- Added file: http://bugs.python.org/file25263/operator_build_class_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 22:53:44 2012 From: report at bugs.python.org (Joe Peterson) Date: Wed, 18 Apr 2012 20:53:44 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1334782424.12.0.702649841399.issue10941@psf.upfronthosting.co.za> Joe Peterson added the comment: Ah. I figured that one of the Python devs would be who would review it. Is this the normal path for bugs? Not to question the process, but I find it surprising, since I would think that it would cause a lot of bugs to stall out. Also, I had no idea it was the submitter's responsibility to recruit reviewers. And I am not quite sure how to go about this. I do care about this bug (as it's pretty serious that it returns wrong results), so I am willing to do it. Any wiki page or anything that describes the recruiting process or has more info? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 22:59:44 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 18 Apr 2012 20:59:44 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1334782424.12.0.702649841399.issue10941@psf.upfronthosting.co.za> Message-ID: <18AE1EFD-9081-416C-98EB-4C374CF041E2@gmail.com> Alexander Belopolsky added the comment: I'll review your patch. On Apr 18, 2012, at 4:53 PM, Joe Peterson wrote: > > Joe Peterson added the comment: > > Ah. I figured that one of the Python devs would be who would review it. Is this the normal path for bugs? Not to question the process, but I find it surprising, since I would think that it would cause a lot of bugs to stall out. Also, I had no idea it was the submitter's responsibility to recruit reviewers. And I am not quite sure how to go about this. I do care about this bug (as it's pretty serious that it returns wrong results), so I am willing to do it. Any wiki page or anything that describes the recruiting process or has more info? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- nosy: +Alexander.Belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 23:01:21 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 18 Apr 2012 21:01:21 +0000 Subject: [issue14617] confusing docs with regard to __hash__ In-Reply-To: <1334771728.14.0.513778784524.issue14617@psf.upfronthosting.co.za> Message-ID: <1334782881.74.0.772990239103.issue14617@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 23:05:20 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 18 Apr 2012 21:05:20 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1334783120.28.0.255077393481.issue10941@psf.upfronthosting.co.za> R. David Murray added the comment: I see Alexander is going to take care of this. But to clarify what I suggested for your information: In an ideal world it would be a committer doing the patch review, followed by a checkin. But in the real world there aren't enough of us with enough time to get to all the bugs with patches. You asked how to move it along and I suggested one way: get someone else to do a review. I wouldn't say that the submitter recruiting a reviewer was a "normal" process, but it is a way to get bugs unstuck. And we get reviews from non-committers frequently (it is a step along the path to becoming a committer...quality reviews are as important as quality patches). I don't think there's anything in the devguide about this particular nuance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 23:05:21 2012 From: report at bugs.python.org (Joe Peterson) Date: Wed, 18 Apr 2012 21:05:21 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1334783121.58.0.92810769872.issue10941@psf.upfronthosting.co.za> Joe Peterson added the comment: Thanks!! :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 23:16:52 2012 From: report at bugs.python.org (Joe Peterson) Date: Wed, 18 Apr 2012 21:16:52 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1334783812.97.0.438871195495.issue10941@psf.upfronthosting.co.za> Joe Peterson added the comment: David, I understand - thanks for the details. Hopefully I can return the favor and review one in the future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 23:36:21 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 18 Apr 2012 21:36:21 +0000 Subject: [issue14615] pull some import state out of the interpreter state In-Reply-To: <1334766762.33.0.320325938554.issue14615@psf.upfronthosting.co.za> Message-ID: <1334784981.8.0.989521181812.issue14615@psf.upfronthosting.co.za> Eric Snow added the comment: Rather than being arbitrary, the motivation here is to limit amount of the import state that is specific to CPython. I apologize that that wasn't clear. The three import-related members of PyInterpreterState (modules, modules_reloading, and modules_by_index), are implementation-specific. Regarding each of them: modules_by_index was explicitly designed for C extension modules, which are (mostly) CPython-specific. It's essentially a behind-the-scenes optimization. Martin's right that we should leave it alone. modules_reloading is an artifact of the C import implementation, and (like modules_by_index) doesn't have extra bearing on the import state. However, if the importlib bootstrap renders it superfluous, why not yank it? Finally, modules (the biggie) is accessible as sys.modules. importlib uses sys.modules. The C import implementation used interp->modules directly. [1] Most (all) of that usage is going away. Again, _if_ that is the case, why keep it around? Granted, the C implementation takes advantage of interp->modules as an optimized path for getting a module (vs. the extra step of grabbing sys.modules directly), so perhaps the intention is to keep that fast path for C extension modules, etc. However, I'm naively skeptical of how much performance that buys you when all is said and done. Just to be clear, I do _not_ want to make changes willy-nilly. (I've even grown more conservative in what discussion topics I bring up.) This issue has no urgency attached to it, in my mind. It is the result of an actionable conversation that I didn't want to lose track of. If anything here is doable for 3.3, great! If not, that's fine too. If people think it's a bad idea, I'll accept that gladly, but I think consideration of the idea is justifiable. I'm glad there are plenty of sensible minds around to keep Python on a good track. :) [1] This causes a problem in a corner case (see issue 12633), but it's easy to deal with. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 23:38:08 2012 From: report at bugs.python.org (Ethan Furman) Date: Wed, 18 Apr 2012 21:38:08 +0000 Subject: [issue14617] confusing docs with regard to __hash__ In-Reply-To: <1334771728.14.0.513778784524.issue14617@psf.upfronthosting.co.za> Message-ID: <1334785088.38.0.358672769776.issue14617@psf.upfronthosting.co.za> Ethan Furman added the comment: More re-writing... ---------- Added file: http://bugs.python.org/file25264/__hash__2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 18 23:58:01 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 18 Apr 2012 21:58:01 +0000 Subject: [issue12081] Remove distributed copy of libffi In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za> Message-ID: <1334786281.97.0.346857884229.issue12081@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +amaury.forgeotdarc, belopolsky, eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 00:03:39 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 18 Apr 2012 22:03:39 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334786619.75.0.664152149208.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: > Please leave the pybench default timers unchanged in case the > new APIs are not available. Ok, done in the new patch: perf_counter_process_time-2.patch. ---------- Added file: http://bugs.python.org/file25265/perf_counter_process_time-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 00:04:07 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 18 Apr 2012 22:04:07 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334786647.89.0.8875471812.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25210/pep418-9.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 00:04:13 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 18 Apr 2012 22:04:13 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334786653.73.0.926268343725.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25202/perf_counter_process_time.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 00:05:28 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 18 Apr 2012 22:05:28 +0000 Subject: [issue14600] Change ImportError reference handling, naming In-Reply-To: <1334610869.36.0.563738930515.issue14600@psf.upfronthosting.co.za> Message-ID: <1334786728.63.0.451487708884.issue14600@psf.upfronthosting.co.za> ?ric Araujo added the comment: As was pointed on python-dev for the first commit: args = PyTuple_New(1); if (args == NULL) return NULL; kwargs = PyDict_New(); if (args == NULL) return NULL; It looks like the second block has a copy-paste typo and should check kwargs, not args. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 00:06:28 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 18 Apr 2012 22:06:28 +0000 Subject: [issue12598] Move sys variable initialization from import.c to sysmodule.c In-Reply-To: <1311204284.83.0.766064550687.issue12598@psf.upfronthosting.co.za> Message-ID: <1334786788.24.0.728671121253.issue12598@psf.upfronthosting.co.za> Nick Coghlan added the comment: It's about navigability/discovery of the source - to find out how the sys module gets initialised, you currently have to look in multiple places. The idea of the patch is to simplify that to the one logical place: sysmodule.c However, I'm not sure it's right to actually *move* the full import state initialisation. A simple *indirection* (pythonrun.c -> sysmodule.c -> import.c) would solve the navigability problem while also retaining some level of encapsulation for the import state initialisation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 00:07:08 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 18 Apr 2012 22:07:08 +0000 Subject: [issue1615] descriptor protocol bug In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za> Message-ID: <1334786828.38.0.837847054455.issue1615@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo versions: +Python 3.2, Python 3.3 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 00:07:09 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 18 Apr 2012 22:07:09 +0000 Subject: [issue14615] pull some import state out of the interpreter state In-Reply-To: <1334784981.8.0.989521181812.issue14615@psf.upfronthosting.co.za> Message-ID: <4F8F3B0B.8@v.loewis.de> Martin v. L?wis added the comment: > Rather than being arbitrary, the motivation here is to limit amount > of the import state that is specific to CPython. What is gained by doing that? > Finally, modules (the biggie) is accessible as sys.modules. > importlib uses sys.modules. The C import implementation used > interp->modules directly. [1] Most (all) of that usage is going > away. Again, _if_ that is the case, why keep it around? I think each of them should be considered on a case-by-case basis. Feel free to submit a patch that eliminates ->modules. People may find reasons not to do so when they see an actual patch. I suggest to close this issue, and encourage people who have the desire to eliminate certain state as individual patches. > Just to be clear, I do _not_ want to make changes willy-nilly. (I've > even grown more conservative in what discussion topics I bring up.) > This issue has no urgency attached to it, in my mind. It is the > result of an actionable conversation that I didn't want to lose track > of. Then I think it doesn't belong in this bug tracker. I have five or ten "grand plans" of things that should change in Python at some point; putting them into a bug tracker is only confusing people, though, since no implementation might be coming forward (for some of the things, I have been pondering for the last eight years). For many of the things, I ended up writing PEPs since they were significant changes. So if this is one of your grand plans, feel free to mention it on python-dev. Putting it on the bug tracker asks for specific action. If I had to act on this issue, I'd outright reject it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 00:08:36 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 18 Apr 2012 22:08:36 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1334786916.03.0.335924457084.issue3561@psf.upfronthosting.co.za> ?ric Araujo added the comment: A minor thing: The capitalization of the feature names is inconsistent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 00:09:22 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 18 Apr 2012 22:09:22 +0000 Subject: [issue14588] PEP 3115 compliant dynamic class creation In-Reply-To: <1334535798.87.0.826104374353.issue14588@psf.upfronthosting.co.za> Message-ID: <1334786962.39.0.0153921073623.issue14588@psf.upfronthosting.co.za> Nick Coghlan added the comment: I thought about that, and I'd prefer a dedicated dictionary to avoid questions of name conflicts. Wrapping the keyword args in a dict() call is still pretty clean: C = operator.build_class('C', (A, B), dict(metaclass=MyMeta)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 00:11:04 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 18 Apr 2012 22:11:04 +0000 Subject: [issue14590] ConfigParser doesn't strip inline comment when delimiter occurs earlier without preceding space. In-Reply-To: <1334541468.07.0.833607995836.issue14590@psf.upfronthosting.co.za> Message-ID: <1334787064.87.0.609535234438.issue14590@psf.upfronthosting.co.za> ?ric Araujo added the comment: I don?t remember if the doc is precise or not about this behavior, but I?m convince people used trial-and-error to see what exactly configparser would do, and rely on that knowledge know. I think I had to do that once. Thus it is not clear to me that changing the default behavior in 3.3 is a good idea. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 00:13:02 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 18 Apr 2012 22:13:02 +0000 Subject: [issue14601] PEP sources not available as documented In-Reply-To: <1334612466.63.0.59561167474.issue14601@psf.upfronthosting.co.za> Message-ID: <1334787182.87.0.761612947075.issue14601@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the report. www.python.org is not in a python-dev repository, so there is nothing the developers following bugs.python.org can do. Could you repost the problem to the pydotorg mailing list? ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 00:18:48 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 18 Apr 2012 22:18:48 +0000 Subject: [issue13476] Simple exclusion filter for unittest autodiscovery In-Reply-To: <1322186223.31.0.112270498917.issue13476@psf.upfronthosting.co.za> Message-ID: <1334787528.76.0.247840693614.issue13476@psf.upfronthosting.co.za> ?ric Araujo added the comment: > A -x flag would be more useful if I could specify it on the "python setup.py tests" command line The most common distutils test command is part of setuptools, not the standard library. Other people have also written other test, tests or nosetests commands. The only test command in the standard library is in packaging (distutils2), so you could open another bug report to request a new option for ?pysetup run test?, which would simply pass the option to unittest. ---------- nosy: +eric.araujo versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 00:21:05 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 18 Apr 2012 22:21:05 +0000 Subject: [issue14601] PEP sources not available as documented In-Reply-To: <1334612466.63.0.59561167474.issue14601@psf.upfronthosting.co.za> Message-ID: <1334787665.61.0.849710614587.issue14601@psf.upfronthosting.co.za> Benjamin Peterson added the comment: It's fine now, anyway. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 00:23:27 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 18 Apr 2012 22:23:27 +0000 Subject: [issue14601] PEP sources not available as documented In-Reply-To: <1334612466.63.0.59561167474.issue14601@psf.upfronthosting.co.za> Message-ID: <1334787807.31.0.285332989418.issue14601@psf.upfronthosting.co.za> ?ric Araujo added the comment: How so? Links still point to the old Subversion server. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 00:26:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 18 Apr 2012 22:26:40 +0000 Subject: [issue14385] Support other types than dict for __builtins__ In-Reply-To: <1332380135.46.0.264363154256.issue14385@psf.upfronthosting.co.za> Message-ID: <1334788000.53.0.19290681022.issue14385@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This looks fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 00:43:54 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 18 Apr 2012 22:43:54 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1334789034.1.0.685452668796.issue3561@psf.upfronthosting.co.za> Brian Curtin added the comment: The attached patch changes the feature text to "Add python.exe to Path". I'm not sure the word "search" adds much there anyway. An additional change here that I think would be beneficial is a better description text, immediately covering the benefit of this feature. I had to do some minor resizing of the relevant text boxes, but the description is now... Prepend C:\Python33 to the system Path variable. This allows you to type 'python' into a command prompt without needing the full path. ---------- Added file: http://bugs.python.org/file25266/issue3561_v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 01:00:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 18 Apr 2012 23:00:20 +0000 Subject: [issue14385] Support other types than dict for __builtins__ In-Reply-To: <1332380135.46.0.264363154256.issue14385@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e3ab8aa0216c by Victor Stinner in branch 'default': Issue #14385: Support other types than dict for __builtins__ http://hg.python.org/cpython/rev/e3ab8aa0216c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 01:02:25 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 18 Apr 2012 23:02:25 +0000 Subject: [issue14385] Support other types than dict for __builtins__ In-Reply-To: <1332380135.46.0.264363154256.issue14385@psf.upfronthosting.co.za> Message-ID: <1334790145.53.0.818164518174.issue14385@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 01:10:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 18 Apr 2012 23:10:41 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1334790641.2.0.598757165447.issue4892@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Could you regenerate your patch now that the win32 -> _winapi changes have been applied? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 01:10:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 18 Apr 2012 23:10:46 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1334790646.25.0.547418494151.issue4892@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 01:28:38 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 18 Apr 2012 23:28:38 +0000 Subject: [issue14331] Python/import.c uses a lot of stack space due to MAXPATHLEN In-Reply-To: <1331858549.21.0.813321528381.issue14331@psf.upfronthosting.co.za> Message-ID: <1334791718.07.0.130825905083.issue14331@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Patch ad030571e6c0 introduces a compilation warning in Python 2.7. See ---------- nosy: +jcea versions: +Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 01:31:24 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 18 Apr 2012 23:31:24 +0000 Subject: [issue14331] Python/import.c uses a lot of stack space due to MAXPATHLEN In-Reply-To: <1331858549.21.0.813321528381.issue14331@psf.upfronthosting.co.za> Message-ID: <1334791884.71.0.613745714749.issue14331@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: In fact, the compilation warning seems to expose a far more serious issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 01:33:49 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 18 Apr 2012 23:33:49 +0000 Subject: [issue14331] Python/import.c uses a lot of stack space due to MAXPATHLEN In-Reply-To: <1331858549.21.0.813321528381.issue14331@psf.upfronthosting.co.za> Message-ID: <1334792029.53.0.756061818318.issue14331@psf.upfronthosting.co.za> Gregory P. Smith added the comment: That warning is correct, there's a bug in the code. but given this is only a bug when PyMem_MALLOC returns NULL I do not expect this to be an issue for anyone who does not already have issues. Regardless, I'm fixing it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 01:42:19 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 18 Apr 2012 23:42:19 +0000 Subject: [issue14331] Python/import.c uses a lot of stack space due to MAXPATHLEN In-Reply-To: <1331858549.21.0.813321528381.issue14331@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b82a471d2c5e by Gregory P. Smith in branch '2.7': Fix compiler warning related to issue #14331. harmless. http://hg.python.org/cpython/rev/b82a471d2c5e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 02:03:05 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 19 Apr 2012 00:03:05 +0000 Subject: [issue14331] Python/import.c uses a lot of stack space due to MAXPATHLEN In-Reply-To: <1331858549.21.0.813321528381.issue14331@psf.upfronthosting.co.za> Message-ID: <1334793785.23.0.482570207994.issue14331@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: "PyErr_NoMemory()" returns always NULL, but it is declared as returning "PyObject *". Could we change "return PyErr_NoMemory();" to "PyErr_NoMemory(); return NULL;"?. Maybe with some comment... A cast would silence the compiler but could be unclear. What do you think? This is not a problem in 3.2 because the function patched returns a "PyObject *". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 02:06:43 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 19 Apr 2012 00:06:43 +0000 Subject: [issue14331] Python/import.c uses a lot of stack space due to MAXPATHLEN In-Reply-To: <1331858549.21.0.813321528381.issue14331@psf.upfronthosting.co.za> Message-ID: <1334794003.8.0.574887016893.issue14331@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Gregory patching was faster than my writing :-). Thanks for taking the effort :-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 02:07:59 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 19 Apr 2012 00:07:59 +0000 Subject: [issue14331] Python/import.c uses a lot of stack space due to MAXPATHLEN In-Reply-To: <1331858549.21.0.813321528381.issue14331@psf.upfronthosting.co.za> Message-ID: <1334794079.48.0.980721694135.issue14331@psf.upfronthosting.co.za> Gregory P. Smith added the comment: already fixed, I just manually returned NULL. :) I suppose we could change PyErr_NoMemory's definition in 3.3 to return a "void *" instead of "PyObject *" but I'd rather not. In this case the warning caused me to examine the code and determine if it was in fact intended to do the right Python exception raising thing when NULL was returned from this non Python C API function. In this case it was, but not all code can assume that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 03:06:52 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 19 Apr 2012 01:06:52 +0000 Subject: [issue14615] pull some import state out of the interpreter state In-Reply-To: <1334766762.33.0.320325938554.issue14615@psf.upfronthosting.co.za> Message-ID: <1334797612.54.0.126290001343.issue14615@psf.upfronthosting.co.za> Brett Cannon added the comment: Eric put this in the bug tracker because I asked him to; I'm getting more emails about stuff about importlib that it's a little hard to keep track of everything. But originally this was about exposing what is left of the C-level APIs so it no longer was hidden. I'm fine with rescoping this bug to only looking at modules_reloading. ---------- title: pull some import state out of the interpreter state -> pull some import state out of the interpreter state _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 03:22:38 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 19 Apr 2012 01:22:38 +0000 Subject: [issue14381] Intern certain integral floats for memory savings and performance In-Reply-To: <1332352043.3.0.236525644282.issue14381@psf.upfronthosting.co.za> Message-ID: <1334798558.42.0.87548988394.issue14381@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 03:32:27 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 19 Apr 2012 01:32:27 +0000 Subject: [issue14618] remove modules_reloading from the interpreter state Message-ID: <1334799147.41.0.250628519615.issue14618@psf.upfronthosting.co.za> New submission from Eric Snow : Once imp.reload() is moved to imp.py, and the code is stripped from Python/import.c, we can see where modules_reloading stands. I expect that it will have become entirely superfluous at that point. ---------- components: Interpreter Core messages: 158691 nosy: brett.cannon, eric.snow priority: normal severity: normal status: open title: remove modules_reloading from the interpreter state versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 03:33:05 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 19 Apr 2012 01:33:05 +0000 Subject: [issue14615] pull some import state out of the interpreter state In-Reply-To: <1334766762.33.0.320325938554.issue14615@psf.upfronthosting.co.za> Message-ID: <1334799185.63.0.17185125484.issue14615@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks for your feedback, Martin. I'll go ahead and make a new issue for modules_reloading (and one for interp->modules when appropriate). ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 03:33:29 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 19 Apr 2012 01:33:29 +0000 Subject: [issue14615] pull some import state out of the interpreter state In-Reply-To: <1334766762.33.0.320325938554.issue14615@psf.upfronthosting.co.za> Message-ID: <1334799209.67.0.169663451075.issue14615@psf.upfronthosting.co.za> Eric Snow added the comment: for modules_reloading, issue14618 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 03:34:57 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 19 Apr 2012 01:34:57 +0000 Subject: [issue14618] remove modules_reloading from the interpreter state In-Reply-To: <1334799147.41.0.250628519615.issue14618@psf.upfronthosting.co.za> Message-ID: <1334799297.41.0.558126190983.issue14618@psf.upfronthosting.co.za> Eric Snow added the comment: see issue14615 for the broader picture ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 03:36:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 19 Apr 2012 01:36:31 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 36c901fcfcda by Ezio Melotti in branch '2.7': #14538: HTMLParser can now parse correctly start tags that contain a bare /. http://hg.python.org/cpython/rev/36c901fcfcda New changeset ba4baaddac8d by Ezio Melotti in branch '3.2': #14538: HTMLParser can now parse correctly start tags that contain a bare /. http://hg.python.org/cpython/rev/ba4baaddac8d New changeset 0f837071fd97 by Ezio Melotti in branch 'default': #14538: merge with 3.2. http://hg.python.org/cpython/rev/0f837071fd97 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 03:45:31 2012 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 19 Apr 2012 01:45:31 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334799931.04.0.0221484938376.issue14538@psf.upfronthosting.co.za> Ezio Melotti added the comment: This is now fixed, thanks for the report! Regarding the documentation feel free to open another issue, but at some point I'll probably update it anyway and/or write down somewhere what the future plans for HTMLParser and its goals. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 06:35:55 2012 From: report at bugs.python.org (cooyeah) Date: Thu, 19 Apr 2012 04:35:55 +0000 Subject: [issue14308] '_DummyThread' object has no attribute '_Thread__block' In-Reply-To: <1331768900.76.0.717773710833.issue14308@psf.upfronthosting.co.za> Message-ID: <1334810155.62.0.299188608445.issue14308@psf.upfronthosting.co.za> cooyeah added the comment: I saw the similar problem on Ubuntu 12.04 with django development server with mediageneartor. As Dustin suggested, I don't think this is related to the "del _Thread__block" statement. I hacked the __getattribute__ of DummyThread class def __getattribute__(self, name): if name == '_Thread__block': import traceback traceback.print_stack() raise AttributeError return Thread.__getattribute__(self, name) And I got the following stacktrace: File "/tmp/ve/local/lib/python2.7/site-packages/mediagenerator/filters/coffeescript.py", line 54, in _compile shell=shell, universal_newlines=True) File "/usr/lib/python2.7/subprocess.py", line 679, in __init__ errread, errwrite) File "/usr/lib/python2.7/subprocess.py", line 1143, in _execute_child self.pid = os.fork() File "/usr/lib/python2.7/threading.py", line 907, in _after_fork thread._Thread__stop() File "/usr/lib/python2.7/threading.py", line 608, in __stop self.__block.acquire() File "/usr/lib/python2.7/threading.py", line 827, in __getattribute__ traceback.print_stack() ---------- nosy: +cooyeah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 07:14:55 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 19 Apr 2012 05:14:55 +0000 Subject: [issue14619] Enhanced variable substitution for databases Message-ID: <1334812495.3.0.737876206598.issue14619@psf.upfronthosting.co.za> New submission from Raymond Hettinger : I suggest adding a ?? placeholder for variable length substitutions in SQL statements: vars = 'Knight', ('Gwain', 'Gallahad', 'Lancelot'), 30 c.execute('''SELECT * FROM loyalsubjects WHERE rank = ? AND name IN (??) AND age >= ? ''', vars) ---------- components: Extension Modules messages: 158698 nosy: rhettinger priority: low severity: normal status: open title: Enhanced variable substitution for databases type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 07:42:32 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 19 Apr 2012 05:42:32 +0000 Subject: [issue14591] Value returned by random.random() out of valid range In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1334814152.54.0.647629544428.issue14591@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This needs a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 08:54:31 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 19 Apr 2012 06:54:31 +0000 Subject: [issue14591] Value returned by random.random() out of valid range In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1334818471.59.0.443763064726.issue14591@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's a modification of Serhiy's patch that assures that the new state is nonzero. (Just to clarify the nonzero requirement: the MT state is formed from bit 31 of mt[0] together with all the bits of mt[i], 1 <= i < 624. At least one of these 19937 bits must be nonzero.) ---------- Added file: http://bugs.python.org/file25267/random_jumpahead_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 09:16:56 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 19 Apr 2012 07:16:56 +0000 Subject: [issue14591] Value returned by random.random() out of valid range In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1334819816.84.0.26828775277.issue14591@psf.upfronthosting.co.za> Mark Dickinson added the comment: The latest patch has the disadvantage that it'll often change the behaviour of jumpahead for people on 32-bit platforms, which may lead to unnecessary breakage. Here's a better version that only fixes mt[0] in the unlikely (but possible) event that mt[1] through mt[623] are all zero. That should mean that users on 32-bit machines who are depending on jumpahead being reproducible won't notice (unless they're very unlucky indeed). ---------- Added file: http://bugs.python.org/file25268/random_jumpahead_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 09:27:10 2012 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Thu, 19 Apr 2012 07:27:10 +0000 Subject: [issue14590] ConfigParser doesn't strip inline comment when delimiter occurs earlier without preceding space. In-Reply-To: <1334541468.07.0.833607995836.issue14590@psf.upfronthosting.co.za> Message-ID: <1334820430.12.0.573853336513.issue14590@psf.upfronthosting.co.za> ?ukasz Langa added the comment: INI files won't go away and there will come a time where 3.3 is old. Since 3.2 inline comments are turned off by default which mitigates the problem. Fixing this parser bug for the 3.3 release seems safe enough for me as long as you clearly state in NEWS and the docs that it changed. I'll leave 2.7 and 3.2 behind as to my doubts stated in the previous comment. ---------- versions: -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 09:42:08 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 19 Apr 2012 07:42:08 +0000 Subject: [issue14619] Enhanced variable substitution for databases In-Reply-To: <1334812495.3.0.737876206598.issue14619@psf.upfronthosting.co.za> Message-ID: <1334821328.01.0.499800399262.issue14619@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I agree this would be very handy, but the database engines I know which accept "bind variables" (Oracle, MySQL, JDBC) only accept simple types. So to handle ?? it would be necessary to modify the SQL statement passed to the database server: "name in (?, ?, ?)". This has some drawbacks IMO: - One advantage of bind variables is that the SQL server sees the same statement for different invocations of execute() and thus can reuse computed data (parsed query, execution plan, etc) . The "??" placeholder would silently kill this optimization. - cursor.executemany() would have to format and pass a different statement for each row, which would break the implementations that prepare the statement once and pass all the rows in a single call. - cx_Oracle has a cursor.prepare(stmt) function which explicitly exposes the above mechanism; it could not work with "??". Yes, the IN operator in SQL is difficult to address. I've tried several approaches to this, one of them was to create a temporary table and joint it in the main query... ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 09:53:23 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 19 Apr 2012 07:53:23 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1334822003.13.0.853324072845.issue13959@psf.upfronthosting.co.za> Eric Snow added the comment: Looking it over, I'm confident that tokenizer.detect_encoding() does not raise a SyntaxError where PyTokenizer_FindEncodingFilename() does. I've run out of time tonight, but I'll look at it more tomorrow. Once find_module() is done, I'd like to move on to reload(), which I expect will be pretty straightforward at this point. Then the feasibility of issue14618 should be clear. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 10:39:37 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 19 Apr 2012 08:39:37 +0000 Subject: [issue14601] PEP sources not available as documented In-Reply-To: <1334612466.63.0.59561167474.issue14601@psf.upfronthosting.co.za> Message-ID: <1334824777.01.0.171476140676.issue14601@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Not sure how it was supposed to be fixed in the past, as the docutils formatter would happily use whatever URL the docutils release had in place. I now fixed it for real (I hope) in 34076bfed420 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 10:51:39 2012 From: report at bugs.python.org (Florian Bruhin) Date: Thu, 19 Apr 2012 08:51:39 +0000 Subject: [issue14620] Fatal Python error: Cannot recover from stack overflow. Message-ID: <1334825499.76.0.44489005416.issue14620@psf.upfronthosting.co.za> New submission from Florian Bruhin : Hey, I just got the error message in the title when trying to run a script with python. You can find the coredump, stacktrace, and the scripts I ran at http://the-compiler.org/tmp/pythoncrash/ The command line I ran: python -u pythonomegle.py Running Python 3.2.2 on Archlinux. ---------- components: None messages: 158706 nosy: The-Compiler priority: normal severity: normal status: open title: Fatal Python error: Cannot recover from stack overflow. type: crash versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 10:54:22 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 19 Apr 2012 08:54:22 +0000 Subject: [issue14619] Enhanced variable substitution for databases In-Reply-To: <1334812495.3.0.737876206598.issue14619@psf.upfronthosting.co.za> Message-ID: <1334825662.72.0.0970867681489.issue14619@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Raymond, the variable substitution is normally done by the database and not the Python database modules, so you'd have to ask the database maintainers for assistance. The qmark ('?') parameter style is part of the ODBC standard, so it's unlikely that this will get changed any time soon unless you have good contacts with Microsoft :-) The ODBC standard also doesn't support multi-value substitutions in the API, so there's no way to pass the array to the database driver. BTW: Such things are better discussed on the DB-SIG mailing list than the Python tracker. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 11:07:31 2012 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Thu, 19 Apr 2012 09:07:31 +0000 Subject: [issue7980] time.strptime not thread safe In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za> Message-ID: <1334826451.34.0.371546529296.issue7980@psf.upfronthosting.co.za> Changes by C?dric Krier : ---------- nosy: +ced _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 11:13:11 2012 From: report at bugs.python.org (Stefano Taschini) Date: Thu, 19 Apr 2012 09:13:11 +0000 Subject: [issue14611] inspect.getargs fails on some anonymous tuples In-Reply-To: <1334738109.2.0.700206080535.issue14611@psf.upfronthosting.co.za> Message-ID: <1334826791.05.0.718971485705.issue14611@psf.upfronthosting.co.za> Stefano Taschini added the comment: I think this should do. inspect.getargs is now looking for STORE_DEREF besides STORE_FAST, and is making sure that the appropriate namespace (locals vs cell + free vars) is selected depending on the opcode. The only changes to the test suite are three additional tests, based on the two examples above. ---------- keywords: +patch Added file: http://bugs.python.org/file25269/issue_14611.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 11:19:03 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 19 Apr 2012 09:19:03 +0000 Subject: [issue14381] Intern certain integral floats for memory savings and performance In-Reply-To: <1332352043.3.0.236525644282.issue14381@psf.upfronthosting.co.za> Message-ID: <1334827143.25.0.26790027533.issue14381@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Why do you think it isn't safe, Antoine? It violates C's strict aliasing rules; Google for 'C strict aliasing' or 'C type punning' for more information. This isn't just a theoretical concern: gcc is known to make optimizations based on the assumption that strict aliasing isn't violated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 11:27:07 2012 From: report at bugs.python.org (=?utf-8?q?Esben_Agerb=C3=A6k_Black?=) Date: Thu, 19 Apr 2012 09:27:07 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: <1332849673.66.0.0828799259938.issue14423@psf.upfronthosting.co.za> Message-ID: <1334827627.54.0.705307140122.issue14423@psf.upfronthosting.co.za> Esben Agerb?k Black added the comment: >> 2) I get errors for all my test when I build "my" python and run >> "./python.exe -m test.datetimetester -j3" >> I asume this is because I have yet to implement the c version in >> Modules/_datetimemodule.c >> is this the correct assumption? >You should probably run "./python.exe -m test -v test_datetime" instead. >Not sure that will fix your test failures, though :) Ok so now i only get errors for "_Fast" tests am I correct in assuming that this is because i lack a C implementation? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 11:44:46 2012 From: report at bugs.python.org (sbt) Date: Thu, 19 Apr 2012 09:44:46 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1334828686.34.0.360185093948.issue4892@psf.upfronthosting.co.za> sbt added the comment: Up to date patch. ---------- Added file: http://bugs.python.org/file25270/mp_pickle_conn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 12:20:12 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 19 Apr 2012 10:20:12 +0000 Subject: [issue14381] Intern certain integral floats for memory savings and performance In-Reply-To: <1332352043.3.0.236525644282.issue14381@psf.upfronthosting.co.za> Message-ID: <1334830812.66.0.873115734121.issue14381@psf.upfronthosting.co.za> Mark Dickinson added the comment: > We only support IEEE platforms. I don't think that's true, BTW. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 12:26:52 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 19 Apr 2012 10:26:52 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1334831212.38.0.0763932225169.issue11618@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Here is a new patch. This uses critical sections and condition variables to avoid kernel mode switches for locks. Windows mutexes are expensive and for uncontented locks, this offers a big win. It also adds an internal set of critical section/condition variable structures, that can be used on windows to do other such things without resorting to explicit kernel objects. This code works on XP and newer, since it relies on the "semaphore" kernel object being present. In addition, if compiled to target Vista or greater, it will use the built-in critical section primitives and the FRWLock objects (which are faster still than CriticalSection objects and more robust) ---------- status: pending -> open Added file: http://bugs.python.org/file25271/ntlocks.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 12:57:38 2012 From: report at bugs.python.org (sbt) Date: Thu, 19 Apr 2012 10:57:38 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1334833058.77.0.669203408706.issue4892@psf.upfronthosting.co.za> sbt added the comment: A couple of minor changes based on Antoine's earlier review (which I did not notice till now). ---------- Added file: http://bugs.python.org/file25272/mp_pickle_conn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 13:01:34 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 19 Apr 2012 11:01:34 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1334786619.75.0.664152149208.issue14428@psf.upfronthosting.co.za> Message-ID: <4F8FF088.8080705@egenix.com> Marc-Andre Lemburg added the comment: STINNER Victor wrote: > > STINNER Victor added the comment: > >> Please leave the pybench default timers unchanged in case the >> new APIs are not available. > > Ok, done in the new patch: perf_counter_process_time-2.patch. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 13:19:02 2012 From: report at bugs.python.org (Zeev Rotshtein) Date: Thu, 19 Apr 2012 11:19:02 +0000 Subject: [issue5118] '%.2f' % 2.545 doesn't round correctly In-Reply-To: <1233406671.56.0.693255150937.issue5118@psf.upfronthosting.co.za> Message-ID: <1334834342.6.0.629494710439.issue5118@psf.upfronthosting.co.za> Zeev Rotshtein added the comment: Well this IS a bug. There is a certain globally accepted manner in which rounding work and python does something else. P.S.: A bug is when something doesn't do what it's supposed to do the way it's supposed to do it. This definition does not depend on "internal representation" or any such things. ---------- nosy: +Zeev.Rotshtein _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 13:54:12 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 19 Apr 2012 11:54:12 +0000 Subject: [issue5118] '%.2f' % 2.545 doesn't round correctly In-Reply-To: <1233406671.56.0.693255150937.issue5118@psf.upfronthosting.co.za> Message-ID: <1334836452.95.0.823863099523.issue5118@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Well this IS a bug. I assume that you're referring to behaviour like this: Python 2.7.2 (default, Jan 13 2012, 17:11:09) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> x = 2.545 >>> round(x, 2) 2.54 To explain again, what happens here is: (1) After the assignment 'x = 2.545', what's stored for x is not the precise decimal value 2.545, but a binary approximation to it. That binary approximation just happens to be very slightly less than 2.545. (2) Now when rounding, the usual rules are applies (values less than half get rounded down), to give 2.54. Which part(s) of the above do you think should be changed? Should the 'round' function incorrectly round some numbers up even though they fall below the halfway case? ---------- assignee: -> mark.dickinson versions: +Python 2.7 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 13:55:30 2012 From: report at bugs.python.org (Michel Leunen) Date: Thu, 19 Apr 2012 11:55:30 +0000 Subject: [issue14538] HTMLParser: parsing error In-Reply-To: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za> Message-ID: <1334836530.18.0.3108576246.issue14538@psf.upfronthosting.co.za> Michel Leunen added the comment: Thanks guys for your comments and for solving this issue. Great work! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 14:23:15 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 19 Apr 2012 12:23:15 +0000 Subject: [issue14032] test_cmd_line_script prints undefined 'data' variable In-Reply-To: <1329409071.29.0.619315923648.issue14032@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset c4c67c2d8ffc by Nick Coghlan in branch '3.2': Close #14032: fix incorrect variable reference in test_cmd_line_script http://hg.python.org/cpython/rev/c4c67c2d8ffc ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 14:30:39 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 19 Apr 2012 12:30:39 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1334838639.32.0.34029815589.issue11618@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > This uses critical sections and condition variables to avoid kernel > mode switches for locks. Windows mutexes are expensive and for > uncontented locks, this offers a big win. Can you post some numbers? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 14:34:24 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 19 Apr 2012 12:34:24 +0000 Subject: [issue14098] provide public C-API for reading/setting sys.exc_info() In-Reply-To: <1329983921.26.0.0291312337524.issue14098@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 9fdec1354af4 by Martin v. L?wis in branch 'default': Issue #14098: New functions PyErr_GetExcInfo and PyErr_SetExcInfo. http://hg.python.org/cpython/rev/9fdec1354af4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 14:35:04 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 19 Apr 2012 12:35:04 +0000 Subject: [issue14098] provide public C-API for reading/setting sys.exc_info() In-Reply-To: <1329983921.26.0.0291312337524.issue14098@psf.upfronthosting.co.za> Message-ID: <1334838904.12.0.418043687011.issue14098@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the patch! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 14:36:14 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 19 Apr 2012 12:36:14 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1334838974.96.0.790714392636.issue13903@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Mark, can you please submit a contributor form? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 14:41:20 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 19 Apr 2012 12:41:20 +0000 Subject: [issue2470] Need fixer for dl (removed) -> ctypes module In-Reply-To: <1206339875.66.0.189262293555.issue2470@psf.upfronthosting.co.za> Message-ID: <1334839280.7.0.293949812513.issue2470@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Being open for four years, this is hardly critical. ---------- priority: critical -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 15:19:38 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 19 Apr 2012 13:19:38 +0000 Subject: [issue14308] '_DummyThread' object has no attribute '_Thread__block' In-Reply-To: <1331768900.76.0.717773710833.issue14308@psf.upfronthosting.co.za> Message-ID: <1334841578.13.0.578193901771.issue14308@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, could you try applying the following patch to threading.py? diff --git a/Lib/threading.py b/Lib/threading.py --- a/Lib/threading.py +++ b/Lib/threading.py @@ -887,7 +887,7 @@ def _after_fork(): ident = _get_ident() thread._Thread__ident = ident new_active[ident] = thread - else: + elif not isinstance(thread, _DummyThread): # All the others are already stopped. thread._Thread__stop() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 15:36:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 19 Apr 2012 13:36:06 +0000 Subject: [issue14308] '_DummyThread' object has no attribute '_Thread__block' In-Reply-To: <1331768900.76.0.717773710833.issue14308@psf.upfronthosting.co.za> Message-ID: <1334842566.4.0.0925842143456.issue14308@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a complete patch + tests for 2.7. ---------- Added file: http://bugs.python.org/file25273/dummythreadafterfork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 15:38:46 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 19 Apr 2012 13:38:46 +0000 Subject: [issue14601] PEP sources not available as documented In-Reply-To: <1334612466.63.0.59561167474.issue14601@psf.upfronthosting.co.za> Message-ID: <1334842726.77.0.451451026206.issue14601@psf.upfronthosting.co.za> ?ric Araujo added the comment: Confirmed, thanks! ---------- components: -Documentation stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 15:40:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 19 Apr 2012 13:40:50 +0000 Subject: [issue14308] '_DummyThread' object has no attribute '_Thread__block' In-Reply-To: <1331768900.76.0.717773710833.issue14308@psf.upfronthosting.co.za> Message-ID: <1334842850.67.0.0960823171471.issue14308@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file25273/dummythreadafterfork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 15:40:57 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 19 Apr 2012 13:40:57 +0000 Subject: [issue14308] '_DummyThread' object has no attribute '_Thread__block' In-Reply-To: <1331768900.76.0.717773710833.issue14308@psf.upfronthosting.co.za> Message-ID: <1334842857.1.0.755920952823.issue14308@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Added file: http://bugs.python.org/file25274/dummythreadafterfork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 15:51:24 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 19 Apr 2012 13:51:24 +0000 Subject: [issue14601] PEP sources not available as documented In-Reply-To: <1334842726.77.0.451451026206.issue14601@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Martin> I now fixed it for real (I hope) in 34076bfed420 Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 15:58:25 2012 From: report at bugs.python.org (Jason Killen) Date: Thu, 19 Apr 2012 13:58:25 +0000 Subject: [issue8536] Support new features of ZLIB 1.2.6 In-Reply-To: <1272302591.08.0.11918516326.issue8536@psf.upfronthosting.co.za> Message-ID: <1334843905.04.0.564298850247.issue8536@psf.upfronthosting.co.za> Jason Killen added the comment: Given I'm new I wouldn't say I "evaluated" the usefulness of the new functions but I have given them a look and didn't see anything obvious. If thats good enough great, if not then hopefully someone with a little more experience will take a look. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 16:11:25 2012 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 19 Apr 2012 14:11:25 +0000 Subject: [issue14098] provide public C-API for reading/setting sys.exc_info() In-Reply-To: <1329983921.26.0.0291312337524.issue14098@psf.upfronthosting.co.za> Message-ID: <1334844685.96.0.46678694309.issue14098@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The documentation does not explain how this new API is different from PyErr_Fetch/PyErr_Restore. In particular the documentation doesn't mention that PyErr_Fetch and PyErr_GetExcInfo access different bits of the error state (curexc_* vs. exc_* in the thread state). Because of this it is not clear why there are two sets of functions, and why you want to use one set or the other. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 16:19:08 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 19 Apr 2012 14:19:08 +0000 Subject: [issue14614] PyTuple_SET_ITEM could check bounds in debug mode In-Reply-To: <1334761414.21.0.756614621806.issue14614@psf.upfronthosting.co.za> Message-ID: <1334845148.46.0.0410008423702.issue14614@psf.upfronthosting.co.za> Brett Cannon added the comment: Should we limit ourselves to bound errors? Couldn't we make the macros aliases for their full-fledged function equivalents (e.g. PyTuple_SetItem()) which trigger Py_FatalError() on error so we also get argument type checking? ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 16:32:44 2012 From: report at bugs.python.org (Stefano Taschini) Date: Thu, 19 Apr 2012 14:32:44 +0000 Subject: [issue12947] Examples in library/doctest.html lack the flags In-Reply-To: <1315588954.16.0.979263107509.issue12947@psf.upfronthosting.co.za> Message-ID: <1334845964.17.0.0394879643568.issue12947@psf.upfronthosting.co.za> Stefano Taschini added the comment: As far as I can see, Sphinx has a global setting for trim_doctest_flags but lacks the possibility of locally disabling the trimming. A quick workaround would be to have the following sphinx extension added: class ProxyLexer(object): def __init__(self, underlying): self.__underlying = underlying def __getattr__(self, attr): return getattr(self.__underlying, attr) def setup(app): from sphinx.highlighting import lexers if lexers is not None: lexers['pycon-literal'] = ProxyLexer(lexers['pycon']) lexers['pycon3-literal'] = ProxyLexer(lexers['pycon3']) That would allow blocks marked as .. code-block:: pycon-literal or preceded by .. highlight:: pycon-literal to escape the trimming of doctest flags. If that's of any interest I can submit a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 17:14:28 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 19 Apr 2012 15:14:28 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1334848468.49.0.175031472872.issue10941@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Joe, Your changes to the test suit don't apply cleanly anymore. I can probably fix the conflicts, but if you could post an updated patch it will help. Thanks. ---------- nosy: -Alexander.Belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 17:24:38 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 19 Apr 2012 15:24:38 +0000 Subject: [issue13684] httplib tunnel infinite loop In-Reply-To: <1325260587.05.0.642107056326.issue13684@psf.upfronthosting.co.za> Message-ID: <1334849078.54.0.599693190746.issue13684@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- assignee: -> orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 17:50:52 2012 From: report at bugs.python.org (Daniel Urban) Date: Thu, 19 Apr 2012 15:50:52 +0000 Subject: [issue14588] PEP 3115 compliant dynamic class creation In-Reply-To: <1334535798.87.0.826104374353.issue14588@psf.upfronthosting.co.za> Message-ID: <1334850652.15.0.835786232847.issue14588@psf.upfronthosting.co.za> Daniel Urban added the comment: Fair enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 18:57:59 2012 From: report at bugs.python.org (Michael) Date: Thu, 19 Apr 2012 16:57:59 +0000 Subject: [issue10769] ast: provide more useful range information In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za> Message-ID: <1334854679.62.0.939132587137.issue10769@psf.upfronthosting.co.za> Michael added the comment: Hi, Attached is the updated patch by Sven Brauch from the original mailing list thread bringing column offset reporting for attributes in line with everything else. The offsets for bar before the patch: foo[bar] = 4 foo(bar) = 4 foo.bar = 0 After: foo[bar] = 4 foo(bar) = 4 foo.bar = 4 With the update, are there still concerns? ---------- keywords: +patch nosy: +kensington Added file: http://bugs.python.org/file25275/fix-attr-ranges.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 19:58:09 2012 From: report at bugs.python.org (Vlado Boza) Date: Thu, 19 Apr 2012 17:58:09 +0000 Subject: [issue14621] Hash function is not randomized properly Message-ID: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> New submission from Vlado Boza : Fix of this http://bugs.python.org/issue13703 is broken. tl;dr: There only 256 different hash functions (compare it to size of _Py_HashSecret prefix and suffix). And whether keys collide or not depends only on the last 8 bits of prefix. Problem with current randomization of hash function is following: Suffix does not influence whether two keys have some hash or not (it is xor-ed after everything). Everything except last 8 bits in prefix does not influence it also. Try adding 0x474200 to prefix and see what happens (it will add 0x474200 to resulting hash). To make a DoS attack, attacker must do the following: Generate sets of colliding keys for every 256 possible combinations of last 8 bits. Try each one of these sets - one will have significantly bigger response time, and then repeat this one. ---------- messages: 158736 nosy: Vlado.Boza priority: normal severity: normal status: open title: Hash function is not randomized properly type: security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 19:59:09 2012 From: report at bugs.python.org (Yuval Greenfield) Date: Thu, 19 Apr 2012 17:59:09 +0000 Subject: [issue14622] Python http.server is dead slow using gethostbyaddr/getfqdn for each request Message-ID: <1334858349.45.0.662214350668.issue14622@psf.upfronthosting.co.za> New submission from Yuval Greenfield : This is the line in question: http://hg.python.org/cpython/file/293180d199f2/Lib/http/server.py#l527 I was trying to test out a few html files using "python -m http.server" and it took 4 seconds for each request, it was completely unusable. I had to do hula hoops to find out that it was Python's fault. The function self.address_string is used in every log, meaning every request makes a reverse DNS query before responding. This function failed for every request. Now I know this may be my network's fault but that doesn't mean the server has to die with it. I think the better solution would be to just print out the ip address like other popular servers do. There's no need to be fancy with server names in the log of our toy server, especially when it may come at such a high price. ---------- components: Library (Lib) messages: 158737 nosy: ubershmekel priority: normal severity: normal status: open title: Python http.server is dead slow using gethostbyaddr/getfqdn for each request versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 19:59:16 2012 From: report at bugs.python.org (Yuval Greenfield) Date: Thu, 19 Apr 2012 17:59:16 +0000 Subject: [issue14622] Python http.server is dead slow using gethostbyaddr/getfqdn for each request In-Reply-To: <1334858349.45.0.662214350668.issue14622@psf.upfronthosting.co.za> Message-ID: <1334858356.68.0.362077025112.issue14622@psf.upfronthosting.co.za> Changes by Yuval Greenfield : ---------- type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 20:54:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 19 Apr 2012 18:54:22 +0000 Subject: [issue14622] Python http.server is dead slow using gethostbyaddr/getfqdn for each request In-Reply-To: <1334858349.45.0.662214350668.issue14622@psf.upfronthosting.co.za> Message-ID: <1334861662.18.0.964900366833.issue14622@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Probably a duplicate of issue 6085. ---------- nosy: +pitrou resolution: -> duplicate status: open -> closed superseder: -> Logging in BaseHTTPServer.BaseHTTPRequestHandler causes lag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 21:06:33 2012 From: report at bugs.python.org (Yuval Greenfield) Date: Thu, 19 Apr 2012 19:06:33 +0000 Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes lag In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za> Message-ID: <1334862393.43.0.854942579937.issue6085@psf.upfronthosting.co.za> Yuval Greenfield added the comment: I agree with Antoine on this. Though the suggested patch is wrong. I believe we should leave address_string alone. Simply stop the log_message method from using it. Either way we'd be changing the log format but if we don't have to then we shouldn't completely change the meaning of a method while leaving its name intact. ---------- nosy: +ubershmekel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 22:25:21 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Apr 2012 20:25:21 +0000 Subject: [issue14371] Add support for bzip2 compression to the zipfile module In-Reply-To: <1334686755.61.0.934292222098.issue14371@psf.upfronthosting.co.za> Message-ID: <1334848673.4162.2.camel@raxxla> Serhiy Storchaka added the comment: > What's the status of your contrib form? Oops. I put this off for a detailed study and forgotten. I will send the form, as only get to the printer and the scanner. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 22:25:47 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Apr 2012 20:25:47 +0000 Subject: [issue14371] Add support for bzip2 compression to the zipfile module In-Reply-To: <1334755428.26.0.697893413736.issue14371@psf.upfronthosting.co.za> Message-ID: <1334849531.4162.16.camel@raxxla> Serhiy Storchaka added the comment: > Perhaps because your system's memory allocator is extremely good (or buf is always very small), but b''.join() is far more robust. > Another alternative is accumulating in a bytearray, since it uses overallocation for linear time appending. I thought, that it was in special optimization, mentioned in the python-dev, but could not find this in the code. Perhaps it had not been implemented. In this particular case, the bytes appending is performed only once (and probably a lot of appending with b''). Exceptions are possible only in pathological cases, for example when compressed data is much larger uncompressed data. The current implementation uses `buf += data`, if someone wants to change it, then it's not me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 22:26:09 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Apr 2012 20:26:09 +0000 Subject: [issue14579] Possible vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429246.7.0.746747652407.issue14579@psf.upfronthosting.co.za> Message-ID: <1334861262.7711.12.camel@raxxla> Serhiy Storchaka added the comment: There is the crasher and leaker. When Python is not crashing, there is garbage (i.e. leakage of data) at the end of the decoded string. Indeed, I see an English text in some versions of Python. There are many other errors in utf-16 decoder (see, for example, b'\xD8\x00\xDC'.decode('utf-16be')). I'm now finishing work on a new decoder, and after that take the bug fixing in 3.2. ---------- Added file: http://bugs.python.org/file25276/utf16crasher.py _______________________________________ Python tracker _______________________________________ -------------- next part -------------- k = len(b'\x00\x01\x00\x00'.decode('utf-32be')) for i in range(1000): print(i, ascii((b'\xD8\x00\xDC\x00' * i + b'\xDC\x00' + b'\x00>' * 2).decode('utf-16be', 'ignore')[i * k:])) From report at bugs.python.org Thu Apr 19 22:40:36 2012 From: report at bugs.python.org (Vlado Boza) Date: Thu, 19 Apr 2012 20:40:36 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1334868036.1.0.110705972728.issue14621@psf.upfronthosting.co.za> Vlado Boza added the comment: E.g this strings collide for every prefix ending on 0xcd: 0x27fd5a18, 0x26fe78fa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 22:44:58 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 19 Apr 2012 20:44:58 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1334868298.61.0.32599583132.issue14621@psf.upfronthosting.co.za> Changes by Dave Malcolm : ---------- nosy: +dmalcolm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 22:49:15 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 19 Apr 2012 20:49:15 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1334780538.29.0.212998514403.issue14532@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > v3 patch, based on feedback from the review here: http://bugs.python.org/review/14532/show Looks good to me. One last thing (sorry for not bringing this up earlier): I don't like bikeshedding, but at least to me, `time_independent_equals` is a bit too long to type, and sounds reductive (we don't want to specifically avoid only timing attacks, but provide a way to compare digests securely). What do you (all) think of something shorter, like `secure_compare`, `secure_equals`, or something along those lines? Note that I'm not good at finding names, so if others are fine with the current one, I won't object ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 22:49:29 2012 From: report at bugs.python.org (Mike Hobbs) Date: Thu, 19 Apr 2012 20:49:29 +0000 Subject: [issue14623] Shutdown exception in daemon thread Message-ID: <1334868569.61.0.545748058978.issue14623@psf.upfronthosting.co.za> New submission from Mike Hobbs : This issue is very similar to the issue original reported in issue1722344, except that it occurs in daemon threads. Here's a sample exception: Exception in thread Thread-1 (most likely raised during interpreter shutdown): Traceback (most recent call last): File "/usr/local/lib/python2.7/threading.py", line 552, in __bootstrap_inner File "/usr/local/lib/python2.7/threading.py", line 505, in run File "/opt/8b/libr8/eb/util/graphite.py", line 86, in run File "/usr/local/lib/python2.7/Queue.py", line 168, in get File "/usr/local/lib/python2.7/threading.py", line 237, in wait : 'NoneType' object is not callable Investigating line 237 in threading.py shows that RuntimeError must have been set to None. The issue appears to be that Py_Finalize wipes all globals while there are still daemon threads running. Would it be correct to terminate daemon threads prior to wiping the globals, since the threads won't be able to accomplish much anyway? ---------- components: Interpreter Core messages: 158746 nosy: mhobbs priority: normal severity: normal status: open title: Shutdown exception in daemon thread type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 22:55:03 2012 From: report at bugs.python.org (Jon Oberheide) Date: Thu, 19 Apr 2012 20:55:03 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1334868903.63.0.8592656761.issue14532@psf.upfronthosting.co.za> Jon Oberheide added the comment: I have used the name "secure_compare" in the past for such a function. That said, I don't have strong feelings either way about the naming, so I'll yield to the others. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 22:59:01 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Apr 2012 20:59:01 +0000 Subject: [issue14624] Faster utf-16 decoder Message-ID: <1334869141.17.0.802149162715.issue14624@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : I propose a patch, which accelerates the utf-16 decoder. With PEP 393 utf-16 decoder slowed down a few times (3-4x), this patch returns the performance at the level of Python 3.2 and even higher (+10-30% over 3.2). In addition, it fixes a few bugs in the utf-16 decoder. Also as a side effect is possible acceleration of other decoders. ---------- components: Interpreter Core files: decode_utf16.patch keywords: patch messages: 158748 nosy: storchaka priority: normal severity: normal status: open title: Faster utf-16 decoder type: performance versions: Python 3.3 Added file: http://bugs.python.org/file25277/decode_utf16.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 22:59:57 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Apr 2012 20:59:57 +0000 Subject: [issue14625] Faster utf-32 decoder Message-ID: <1334869197.32.0.159275934867.issue14625@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : I suggest two variants of patch, accelerating the utf-32 decoder. With PEP 393 utf-32 decoder slowed down up to 2x, these patches returns a performance at the level of Python 3.2 and even much higher (2-3x over 3.2). The variant A is simpler, but the variant B is a little faster (+8-15%). ---------- components: Interpreter Core files: decode_utf32_a.patch keywords: patch messages: 158749 nosy: storchaka priority: normal severity: normal status: open title: Faster utf-32 decoder type: performance versions: Python 3.3 Added file: http://bugs.python.org/file25278/decode_utf32_a.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:00:28 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Apr 2012 21:00:28 +0000 Subject: [issue14625] Faster utf-32 decoder In-Reply-To: <1334869197.32.0.159275934867.issue14625@psf.upfronthosting.co.za> Message-ID: <1334869228.45.0.979686070473.issue14625@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file25279/decode_utf32_b.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:01:54 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 19 Apr 2012 21:01:54 +0000 Subject: [issue14624] Faster utf-16 decoder In-Reply-To: <1334869141.17.0.802149162715.issue14624@psf.upfronthosting.co.za> Message-ID: <1334869314.42.0.77772594579.issue14624@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:02:57 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 19 Apr 2012 21:02:57 +0000 Subject: [issue14624] Faster utf-16 decoder In-Reply-To: <1334869141.17.0.802149162715.issue14624@psf.upfronthosting.co.za> Message-ID: <1334869377.33.0.684666519496.issue14624@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:03:21 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 19 Apr 2012 21:03:21 +0000 Subject: [issue14625] Faster utf-32 decoder In-Reply-To: <1334869197.32.0.159275934867.issue14625@psf.upfronthosting.co.za> Message-ID: <1334869401.22.0.0377413848141.issue14625@psf.upfronthosting.co.za> STINNER Victor added the comment: See also #14624 for UTF-16 decoder. ---------- nosy: +haypo, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:03:30 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 19 Apr 2012 21:03:30 +0000 Subject: [issue14624] Faster utf-16 decoder In-Reply-To: <1334869141.17.0.802149162715.issue14624@psf.upfronthosting.co.za> Message-ID: <1334869410.36.0.982201970207.issue14624@psf.upfronthosting.co.za> STINNER Victor added the comment: See also #14625 for UTF-32 decoder. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:06:28 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 19 Apr 2012 21:06:28 +0000 Subject: [issue14381] Intern certain integral floats for memory savings and performance In-Reply-To: <1332352043.3.0.236525644282.issue14381@psf.upfronthosting.co.za> Message-ID: <1334869588.83.0.175336699938.issue14381@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: return *(PY_LONG_LONG*)&fval == 0; There is no aliasing, because there are no pointer variables in existence. If we did this: double *pfval = &fval; PY_LONG_LONG *pl = (PY_LONG_LONG*)pfval return *pfval == 0 Then we would have aliasing. Because "pfval" in this example doesn't exist but is merely a temporary, there is no aliasing. As for IEEE compatibility, I don't think we could have our own floating point formatting library if we didn't make that assumption, but I might be wrong about that. On the other hand, I don't think there is a supported python architecture that defines positive zero as anything else than bitwise zero. And should such a platform be found, it is easy enough to disable this code for it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:07:35 2012 From: report at bugs.python.org (Michal Petrucha) Date: Thu, 19 Apr 2012 21:07:35 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1334869655.79.0.647015970183.issue14621@psf.upfronthosting.co.za> Changes by Michal Petrucha : ---------- nosy: +koniiiik _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:09:27 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Apr 2012 21:09:27 +0000 Subject: [issue14624] Faster utf-16 decoder In-Reply-To: <1334869141.17.0.802149162715.issue14624@psf.upfronthosting.co.za> Message-ID: <1334869767.15.0.967283864245.issue14624@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue #14579 for utf-16 decoder bugs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:11:13 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 19 Apr 2012 21:11:13 +0000 Subject: [issue14308] '_DummyThread' object has no attribute '_Thread__block' In-Reply-To: <1331768900.76.0.717773710833.issue14308@psf.upfronthosting.co.za> Message-ID: <1334869873.87.0.911791812043.issue14308@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: > Here is a complete patch + tests for 2.7. I like the test. However there's something I find strange with the patch: """ diff --git a/Lib/threading.py b/Lib/threading.py --- a/Lib/threading.py +++ b/Lib/threading.py @@ -887,7 +887,7 @@ def _after_fork(): ident = _get_ident() thread._Thread__ident = ident new_active[ident] = thread - else: + elif not isinstance(thread, _DummyThread): # All the others are already stopped. thread._Thread__stop() """ Is it really the caller's job to check that the thread is not a dummy thread? IMO it should be _DummyThread's stop() method that does the right thing, either by overriding Thread's stop() method in _DummyThread or by puting the check inside Thread.stop(), like what's done inside thread._reset_internal_locks(): """ if hasattr(self, '_Thread__block'): # DummyThread deletes self.__block self.__block.__init__() self.__started._reset_internal_locks() """ ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:15:24 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 19 Apr 2012 21:15:24 +0000 Subject: [issue14623] Shutdown exception in daemon thread In-Reply-To: <1334868569.61.0.545748058978.issue14623@psf.upfronthosting.co.za> Message-ID: <1334870124.47.0.111839978789.issue14623@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Would it be correct to terminate daemon threads prior to wiping the > globals, since the threads won't be able to accomplish much anyway? Daemon threads are not actually "terminated" by the Python interpreter, they just keep running in the background until the process exits. The situation should be much better in Python 3.2, where daemon threads are frozen (their execution is halted) when the interpreter starts to shutdown. I don't think this will be ever fixed in 2.7, though. It's a slightly delicate change. ---------- nosy: +pitrou resolution: -> wont fix stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:17:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 19 Apr 2012 21:17:03 +0000 Subject: [issue14308] '_DummyThread' object has no attribute '_Thread__block' In-Reply-To: <1334869873.87.0.911791812043.issue14308@psf.upfronthosting.co.za> Message-ID: <1334870154.3345.8.camel@localhost.localdomain> Antoine Pitrou added the comment: Le jeudi 19 avril 2012 ? 21:11 +0000, Charles-Fran?ois Natali a ?crit : > IMO it should be _DummyThread's stop() method that does the right > thing, either by overriding Thread's stop() method in _DummyThread or > by puting the check inside Thread.stop(), like what's done inside > thread._reset_internal_locks(): I don't think _DummyThread can override __stop(), because of the name mangling of __private methods. However, the hasattr() approach would probably work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:21:58 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 19 Apr 2012 21:21:58 +0000 Subject: [issue14308] '_DummyThread' object has no attribute '_Thread__block' In-Reply-To: <1331768900.76.0.717773710833.issue14308@psf.upfronthosting.co.za> Message-ID: <1334870518.78.0.614533610313.issue14308@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New patch with the hasattr() approach. ---------- Added file: http://bugs.python.org/file25280/dummythreadafterfork2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:23:32 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 19 Apr 2012 21:23:32 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1334870612.7.0.39503531004.issue14621@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:27:41 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 19 Apr 2012 21:27:41 +0000 Subject: [issue14613] time.time can return NaN In-Reply-To: <1334751988.35.0.313625977941.issue14613@psf.upfronthosting.co.za> Message-ID: <1334870861.44.0.190201968243.issue14613@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: time.time can return None or NaN -> time.time can return NaN _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:29:39 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Apr 2012 21:29:39 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1334870979.22.0.322558024344.issue14579@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is the bugs in the utf-16 decoder: 1. `aligned_end` is not updated after calling error handler. 2. Possible silent reading of one byte over the bytes array limit when decoding of a surrogate pair. b'\xD8\x00\xDC'.decode('utf-16be') 3. Error handlers receive data without last byte. 4. After handling truncate data error it is impossible to continue decoding (unlike all the other decoders). ---------- title: Possible vulnerability in the utf-16 decoder after error handling -> Vulnerability in the utf-16 decoder after error handling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:31:07 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 19 Apr 2012 21:31:07 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1334871067.72.0.448739112644.issue14621@psf.upfronthosting.co.za> Dave Malcolm added the comment: Thanks for filing this bug report. I'm not seeing the equal hashes you describe. I'm using this recipe to hardcode a specific prefix and print the hashes using it: $ gdb --eval-command="break _PyRandom_Init" --eval-command="run" --eval-command="print _Py_HashSecret" --eval-command="set _Py_HashSecret.prefix=0xcdcdcdcd" --eval-command="print _Py_HashSecret" --eval-command="continue" -eval-command="continue" --args python -c "a='\x27\xfd\x5a\x18'; b='\x26\xfe\x78\xfa'; print(hash(a)); print(hash(b))" On a 32-bit build of Python 2.7.3 (i686), if I set _Py_HashSecret.prefix=0xcdcdcdcd, I get non-equal hashes for the data you specify (output trimmed somewhat for conciseness): $1 = {prefix = 0, suffix = 0} $2 = {prefix = -842150451, suffix = 0} Continuing. -121255142 -1199906326 Similarly, on a 64-bit build of Python 2.7.3 (x86_64), I get non-equal hashes: $1 = {prefix = 0, suffix = 0} $2 = {prefix = 3452816845, suffix = 0} -3992804574342296806 -8147489705433570838 Did I misunderstand the report? Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:35:57 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Apr 2012 21:35:57 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1334871357.89.0.659085442767.issue14579@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The proposed patch will fix only the first of these bugs. The patch in issue #14624 fixes all bugs for Python 3.3. For Python 3.2 soon I will make a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 19 23:45:15 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 19 Apr 2012 21:45:15 +0000 Subject: [issue14308] '_DummyThread' object has no attribute '_Thread__block' In-Reply-To: <1334870518.78.0.614533610313.issue14308@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > New patch with the hasattr() approach. LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 00:06:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 19 Apr 2012 22:06:43 +0000 Subject: [issue14308] '_DummyThread' object has no attribute '_Thread__block' In-Reply-To: <1331768900.76.0.717773710833.issue14308@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset ab9d6c4907e7 by Antoine Pitrou in branch '2.7': Issue #14308: Fix an exception when a "dummy" thread is in the threading module's active list after a fork(). http://hg.python.org/cpython/rev/ab9d6c4907e7 New changeset 41c64c700e1e by Antoine Pitrou in branch '3.2': Issue #14308: Fix an exception when a "dummy" thread is in the threading module's active list after a fork(). http://hg.python.org/cpython/rev/41c64c700e1e New changeset e3ea462cb181 by Antoine Pitrou in branch 'default': Issue #14308: Fix an exception when a dummy thread is in the threading module's active list after a fork(). http://hg.python.org/cpython/rev/e3ea462cb181 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 00:08:04 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 19 Apr 2012 22:08:04 +0000 Subject: [issue14308] '_DummyThread' object has no attribute '_Thread__block' In-Reply-To: <1331768900.76.0.717773710833.issue14308@psf.upfronthosting.co.za> Message-ID: <1334873284.67.0.912362582649.issue14308@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > I don't think _DummyThread can override __stop(), because of the name > mangling of __private methods. However, the hasattr() approach would > probably work. Wouldn't a _DummyThread._Thread__stop() method override Thread.__stop()? Like >>> class A(object): ... def foo(self): ... self.__bar() ... def __bar(self): ... print "original" ... >>> class B(A): ... def _A__bar(self): ... print "overridden" ... >>> B().foo() overridden ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 00:08:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 19 Apr 2012 22:08:48 +0000 Subject: [issue14127] add st_*time_ns fileds to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f554043badec by Larry Hastings in branch 'default': Issue #14127: Add st_{cma}time_ns fields to os.stat() result object. http://hg.python.org/cpython/rev/f554043badec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 00:11:00 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 19 Apr 2012 22:11:00 +0000 Subject: [issue14308] '_DummyThread' object has no attribute '_Thread__block' In-Reply-To: <1331768900.76.0.717773710833.issue14308@psf.upfronthosting.co.za> Message-ID: <1334873460.41.0.625274612736.issue14308@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Wouldn't a _DummyThread._Thread__stop() method override Thread.__stop()? Probably, but that would be quite ugly IMHO. I've now committed the patch as-is in 2.7. In 3.2 it turned out easier: __stop is now spelt _stop, so can be overriden without any hacks. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 00:18:49 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 19 Apr 2012 22:18:49 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za> Message-ID: <1334873929.16.0.498667978318.issue13994@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: The patch broke egenix-mx-base, since it relies on the customize_compiler() being available in distutils.ccompiler: https://www.egenix.com/mailman-archives/egenix-users/2012-April/114838.html If you make such changes to dot releases, please make absolutely sure that when you move functions from one module to another, you keep backwards compatibility aliases around. ---------- nosy: +lemburg resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 00:24:02 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 19 Apr 2012 22:24:02 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za> Message-ID: <1334874242.02.0.628390839066.issue13994@psf.upfronthosting.co.za> ?ric Araujo added the comment: Sorry for not thinking about this. I?ll be more careful. ---------- stage: committed/rejected -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 00:24:24 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 19 Apr 2012 22:24:24 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za> Message-ID: <1334874264.76.0.989793229604.issue13994@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Here's the quote from mxSetup.py: # distutils changed a lot in Python 2.7 due to many # distutils.sysconfig APIs having been moved to the new # (top-level) sysconfig module. from sysconfig import \ get_config_h_filename, parse_config_h, get_path, \ get_config_vars, get_python_version, get_platform # This API was moved from distutils.sysconfig to distutils.ccompiler # in Python 2.7 from distutils.ccompiler import customize_compiler So in 2.7 the function was moved from sysconfig to ccompiler (where it belongs), and now you're reverting the change in the third dot release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 00:32:33 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 19 Apr 2012 22:32:33 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <1334874242.02.0.628390839066.issue13994@psf.upfronthosting.co.za> Message-ID: <4F90927A.4000203@egenix.com> Marc-Andre Lemburg added the comment: ?ric Araujo wrote: > > Sorry for not thinking about this. I?ll be more careful. No need to be sorry; these things can happen. What I don't understand is this line in the news section: "Complete the revert back to only having one in distutils.sysconfig as 7.12 + is the case in 3.x." Back when I discussed these changes with Tarek, we both agreed that customize_compiler() is better placed into the ccompiler module than the sysconfig module, so I think the one in the sysconfig module should be replaced with a reference to the version in the ccompile module - in both 2.7 and 3.x. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 00:34:36 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 19 Apr 2012 22:34:36 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za> Message-ID: <1334874876.32.0.804955543463.issue13994@psf.upfronthosting.co.za> Ned Deily added the comment: That's unfortunate. But the documented location for customize_compiler is and, AFAIK, had always been in distutils.sysconfig. It was an inadvertent consequence of the bad revert during the 2.7 development cycle that a second copy was made available in distutils.ccompiler. That change was not supposed to be released in 2.7 and was never documented. So I don't think there is anything that can or needs to be done as this point in Python itself. Other opinions? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 00:40:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 19 Apr 2012 22:40:48 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1334875248.58.0.819288220458.issue14621@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +PaulMcMillan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 00:58:15 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 19 Apr 2012 22:58:15 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1334876295.73.0.675964421909.issue14127@psf.upfronthosting.co.za> Larry Hastings added the comment: Sorry about the delay; laptop died, finally dealt with reviving the data off it. Also: fixed spelling error in title. ---------- title: add st_*time_ns fileds to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds -> add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 01:08:21 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 19 Apr 2012 23:08:21 +0000 Subject: [issue14624] Faster utf-16 decoder In-Reply-To: <1334869141.17.0.802149162715.issue14624@psf.upfronthosting.co.za> Message-ID: <1334876901.72.0.0229536900701.issue14624@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Serhiy: can you please submit a contributor form? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 01:26:32 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 19 Apr 2012 23:26:32 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1334877992.71.0.363744127306.issue14621@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't understand this issue: can you write a short script to test a collision? "E.g this strings collide for every prefix ending on 0xcd" Do you mean that prefix & 0xff == 0xcd? "0x27fd5a18, 0x26fe78fa" Is it a byte string or an Unicode string? b'\x27\xfd\x5a\x18' and b'\x26\xfe\x78\xfa'? -- Using PYTHONHASHSEED environment variable, it's easy to find two values generating the same _Py_HashSecret. Just one example: PYTHONHASHSEED=3035016679: * _Py_HashSecret = {0xcd5192eff3fd4d58, 0x3926b1431b200720} PYTHONHASHSEED=4108758503: * _Py_HashSecret = {0xcd5192eff3fd4d58, 0x3926b1431b200720} -- I wrote find_hash_collision.py to try to compute a collision, but the programs fail with: --- Fail to generate a new seed! # seeds = 65298 --- So it fails to generate a new random seed after testing 65298 different seeds. I ran the script with a function generating a seed, a seed generate a prefix "ending with 0xDC". See attached program: it generates a random seed. Uncomment "seed = generate_seed_0xCD()" if the prefix must ends with 0xCD byte. ---------- Added file: http://bugs.python.org/file25281/find_hash_collision.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 01:27:46 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 19 Apr 2012 23:27:46 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za> Message-ID: <1334878066.35.0.49727899827.issue13994@psf.upfronthosting.co.za> Ned Deily added the comment: And to recap the history here, there was a change in direction for Distutils during the 2.7 development cycle, as decided at the 2010 language summit, in particular to revert feature changes in Distutils for 2.7 to its 2.6.x state and, going forward, "Distutils in Python will be feature-frozen". http://mail.python.org/pipermail/python-dev/2010-March/098135.html ---------- resolution: -> fixed stage: -> committed/rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 01:34:10 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 19 Apr 2012 23:34:10 +0000 Subject: [issue14613] time.time can return NaN In-Reply-To: <1334751988.35.0.313625977941.issue14613@psf.upfronthosting.co.za> Message-ID: <1334878450.3.0.366151236835.issue14613@psf.upfronthosting.co.za> STINNER Victor added the comment: > So NaN is a possible result from time.time()? Oops. I don't know if it is possible. I just know that it cannot return None :-) _PyTime_gettimeofday() fills a structure having two integer fields (tv_sec, tv_usec), and floattime() uses these fields to compute a double: static PyObject* floattime(void) { _PyTime_timeval t; _PyTime_gettimeofday(&t); return PyFloat_FromDouble((double)t.tv_sec + t.tv_usec * 1e-6); } I don't see how "(double)t.tv_sec + t.tv_usec * 1e-6" can generate NaN. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 01:42:55 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 19 Apr 2012 23:42:55 +0000 Subject: [issue14386] Expose dict_proxy internal type as types.MappingProxyType In-Reply-To: <1332381004.13.0.167648412562.issue14386@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 34af3e74292d by Victor Stinner in branch 'default': Close #14386: Register types.MappingProxyType as a Mapping http://hg.python.org/cpython/rev/34af3e74292d ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 01:52:39 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 19 Apr 2012 23:52:39 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count Message-ID: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> New submission from Larry Hastings : There are some functions in the os module that do much the same thing but differ only in minor ways, like * whether or not they follow symbolic links (stat vs lstat) * taking an extra "dir_fd" parameter (chmod vs fchmodat(3.3)) It would be better if we consolidated these variations into one function which took keyword-only parameters that allow access to the alternate functionality. Here is a sample of the new possible function signatures, as originally proposed by Serhiy Storchaka: access(path, mode, *, followlinks=True, dirfd=None, eaccess=False) chmod(path, mode, *, followlinks=True, dirfd=None) chown(path, uid, gid, *, followlinks=True, dirfd=None) link(srcpath, dstpath, *, followlinks=True, srcdirfd=None, dstdirfd=None) mkdir(path, mode=0o777, *, dirfd=None) mknod(path, mode=0o600, device=0, *, dirfd=None) open(path, flag, mode=0o777, *, dirfd=None) readlink(path, *, dirfd=None) rename(oldpath, newpath, *, olddirfd=None, newdirfd=None) stat(path, *, followlinks=True, dirfd=None) symlink(src, dst, *, dirfd=None) unlink(path, *, removedir=False, dirfd=None) utimes(path[, (atime, mtime)], *, ns=False, dirfd=None) mkfifoat(path, mode=0o666, *, followlinks=True, dirfd=None) My opinion about naming: PEP 8 suggests underscores to separate words in non-class identifiers. So I'd spell those "dir_fd", "src_dir_fd" (etc), "remove_dir", and "follow_symlinks". (While thinking about this, I remembered the infrequently-cited maxim "no boolean parameters". But that's more a guideline than a rule, and it tends to be a complaint about how the meaning of the parameter is unclear at a call site. As these will be keyword-only parameters I think their meanings will be perfectly clear, so I shan't worry about it.) ---------- messages: 158777 nosy: larry priority: normal severity: normal status: open title: os module: use keyword-only arguments for dir_fd and nofollow to reduce function count _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 01:53:20 2012 From: report at bugs.python.org (Vlado Boza) Date: Thu, 19 Apr 2012 23:53:20 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1334879600.07.0.103859600036.issue14621@psf.upfronthosting.co.za> Vlado Boza added the comment: My bad (I checked only function in C++, not result in python). This should work on 32bit: Prefix: anything ending on 0x00 Suffix: anything Strings: "\x00\xcf\x0b\x96\x19", "\x00\x6d\x29\x45\x18" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 01:54:18 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 19 Apr 2012 23:54:18 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1334879658.72.0.0358245038947.issue14626@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 01:56:59 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 19 Apr 2012 23:56:59 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1334879819.15.0.72756088704.issue14626@psf.upfronthosting.co.za> Larry Hastings added the comment: storchaka: sorry for the long delay, somehow I missed your reply in python-ideas.) You said you envision this as a big patch. Could I convince you to try and make a series of smaller patches? It should be easy to break up into small pieces--do one patch adding dir_fd, the next with follow_symlinks, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 01:58:15 2012 From: report at bugs.python.org (Vlado Boza) Date: Thu, 19 Apr 2012 23:58:15 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1334879895.91.0.680790638653.issue14621@psf.upfronthosting.co.za> Vlado Boza added the comment: For example take this script (on 32bit): ha = hash("\x00\xcf\x0b\x96\x19") hb = hash("\x00\x6d\x29\x45\x18") if ha == hb: print "collision" And run following: for i in `seq 0 25`; do echo $i; for j in `seq 0 100`; do ./python -R x.py; done; done; It gives collison too many times (around 9 out of 2500). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 01:59:48 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 19 Apr 2012 23:59:48 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1334879988.21.0.498204056462.issue14621@psf.upfronthosting.co.za> Dave Malcolm added the comment: $ gdb --eval-command="break _PyRandom_Init" --eval-command="run" --eval-command="print _Py_HashSecret" --eval-command="set _Py_HashSecret.prefix=0xcdcdcd00" --eval-command="print _Py_HashSecret" --eval-command="continue" -eval-command="continue" --args python -c 'a="\x00\xcf\x0b\x96\x19"; b="\x00\x6d\x29\x45\x18"; print(hash(a)); print(hash(b))' On 32-bit: $1 = {prefix = 0, suffix = 0} $2 = {prefix = -842150656, suffix = 0} 1220138288 1220138288 On 64-bit: $1 = {prefix = 0, suffix = 0} $2 = {prefix = 3452816640, suffix = 0} Continuing. 4087671194599937328 -1679444439011306192 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 02:01:22 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 20 Apr 2012 00:01:22 +0000 Subject: [issue14627] Fatal Python Error when Python startup is interrupted by CTRL+c Message-ID: <1334880082.24.0.373368528623.issue14627@psf.upfronthosting.co.za> New submission from STINNER Victor : If you press CTRL+c while Python is starting, you may get such error: ^CFatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "", line 990, in _find_and_load File "", line 571, in load_module File "", line 228, in module_for_loader_wrapper File "", line 456, in _load_module File "/home/haypo/prog/python/default/Lib/io.py", line 90, in RawIOBase.register(FileIO) File "/home/haypo/prog/python/default/Lib/abc.py", line 155, in register if issubclass(subclass, cls): File "/home/haypo/prog/python/default/Lib/abc.py", line 201, in __subclasscheck__ elif subclass in cls._abc_negative_cache: KeyboardInterrupt Abandon ---------- messages: 158782 nosy: brett.cannon, haypo priority: normal severity: normal status: open title: Fatal Python Error when Python startup is interrupted by CTRL+c versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 02:05:56 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 20 Apr 2012 00:05:56 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1334880356.76.0.996398208499.issue14621@psf.upfronthosting.co.za> STINNER Victor added the comment: > For example take this script (on 32bit): (...) > It gives collison too many times (around 9 out of 2500). I tried this script on Linux 32 bits and Linux 64 bits: I didn't see any collision. What is your operating system and the version of your operating system please? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 02:08:31 2012 From: report at bugs.python.org (Michal Petrucha) Date: Fri, 20 Apr 2012 00:08:31 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1334880511.21.0.818894780597.issue14621@psf.upfronthosting.co.za> Michal Petrucha added the comment: @dmalcolm: As for the gdb example, you need to add --eval-command="set _Py_HashSecret_Initialized=1", otherwise _Py_HashSecret will get overwritten immediately after it is set by gdb, either to 0 if run without the -R switch, or to a random value. With the fresh pair of values Vlado provided, I managed to reproduce the collisions on Python 2.7.3, i686 (output trimmed like you did): for __PREFIX in 0x0 0x4700 0xdead00 0xcafe00; do gdb --eval-command="break _PyRandom_Init" --eval-command="run" --eval-command="print _Py_HashSecret" --eval-command="set _Py_HashSecret.prefix=${__PREFIX}" --eval-command="set _Py_HashSecret_Initialized=1" --eval-command="print _Py_HashSecret" --eval-command="continue" -eval-command="continue" --args ./python -c "a='\x00\xcf\x0b\x96\x19'; b='\x00\x6d\x29\x45\x18'; print(hash(a)); print(hash(b))"; done $1 = {prefix = 0, suffix = 0} $2 = {prefix = 0, suffix = 0} Continuing. 1220138288 1220138288 $1 = {prefix = 0, suffix = 0} $2 = {prefix = 18176, suffix = 0} Continuing. -1483212240 -1483212240 $1 = {prefix = 0, suffix = 0} $2 = {prefix = 14593280, suffix = 0} Continuing. -972665808 -972665808 $1 = {prefix = 0, suffix = 0} $2 = {prefix = 13303296, suffix = 0} Continuing. 1003122480 1003122480 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 02:21:15 2012 From: report at bugs.python.org (Vlado Boza) Date: Fri, 20 Apr 2012 00:21:15 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1334881275.8.0.850299516327.issue14621@psf.upfronthosting.co.za> Vlado Boza added the comment: >I tried this script on Linux 32 bits and Linux 64 bits: I didn't see any >collision. What is your operating system and the version of your >operating system please? uname -a Linux 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 20:45:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Anyway you should be able to do following (in 32bits): - generate two colliding keys (with some random seed) - try these keys with different random seeds and they will collide ~1 out of 256 times ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 02:30:16 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 20 Apr 2012 00:30:16 +0000 Subject: [issue8885] markupbase declaration errors aren't recoverable In-Reply-To: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za> Message-ID: <1334881816.08.0.124611361737.issue8885@psf.upfronthosting.co.za> Ezio Melotti added the comment: HTMLParser shouldn't raise errors anymore, so the "error" method (and probably the HTMLParseError exception too) should be deprecated along with the non-strict mode on 3.3. ---------- assignee: -> ezio.melotti nosy: +ezio.melotti type: behavior -> enhancement versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 02:33:02 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 20 Apr 2012 00:33:02 +0000 Subject: [issue755660] allow HTMLParser to continue after a parse error Message-ID: <1334881982.33.0.927760581542.issue755660@psf.upfronthosting.co.za> Ezio Melotti added the comment: HTMLParser should now be able to parse invalid HTML too, so this patch is not necessary anymore. ---------- assignee: -> ezio.melotti nosy: +ezio.melotti resolution: -> out of date stage: patch review -> committed/rejected status: open -> closed versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 02:40:33 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 20 Apr 2012 00:40:33 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1334882433.58.0.0348641361518.issue14626@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think it most (all?) of these cases, it's better to mirror the os level APIs, since many people already know them. Such fanciness is better left to high level wrappers (like path objects). ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 02:43:19 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 20 Apr 2012 00:43:19 +0000 Subject: [issue8885] markupbase declaration errors aren't recoverable In-Reply-To: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za> Message-ID: <1334882599.89.0.573828157529.issue8885@psf.upfronthosting.co.za> Ezio Melotti added the comment: s/non-strict/strict/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 02:43:37 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 20 Apr 2012 00:43:37 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1334882617.48.0.65587108941.issue14621@psf.upfronthosting.co.za> STINNER Victor added the comment: hash.py: Python implementation of the 32-bit version of hash(bytes). Ok, I now see that only the lower 8 bits are really mixed with the input string. ---------- Added file: http://bugs.python.org/file25282/hash.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 02:52:15 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 20 Apr 2012 00:52:15 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1334883135.63.0.596909026287.issue14621@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 04:30:09 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 20 Apr 2012 02:30:09 +0000 Subject: [issue14627] Fatal Python Error when Python startup is interrupted by CTRL+c In-Reply-To: <1334880082.24.0.373368528623.issue14627@psf.upfronthosting.co.za> Message-ID: <1334889009.29.0.78376459935.issue14627@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 04:31:59 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 20 Apr 2012 02:31:59 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1334889119.23.0.69947870469.issue14626@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 05:01:43 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 20 Apr 2012 03:01:43 +0000 Subject: [issue14627] Fatal Python Error when Python startup is interrupted by CTRL+c In-Reply-To: <1334880082.24.0.373368528623.issue14627@psf.upfronthosting.co.za> Message-ID: <1334890903.39.0.117217369553.issue14627@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, so what's your point? =) I mean you stopped the interpreter while in the middle of starting up. Do you want to trigger a fatal error if the exception raised was KeyboardInterrupt? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 05:18:45 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 20 Apr 2012 03:18:45 +0000 Subject: [issue14588] PEP 3115 compliant dynamic class creation In-Reply-To: <1334535798.87.0.826104374353.issue14588@psf.upfronthosting.co.za> Message-ID: <1334891925.34.0.999214472349.issue14588@psf.upfronthosting.co.za> Nick Coghlan added the comment: It occurs to me that, for naming consistency, the callback arg should be documented as "exec_body" rather than "eval_body". I'll try to get to a proper patch review this weekend. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 06:29:57 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 20 Apr 2012 04:29:57 +0000 Subject: [issue14588] PEP 3115 compliant dynamic class creation In-Reply-To: <1334535798.87.0.826104374353.issue14588@psf.upfronthosting.co.za> Message-ID: <1334896197.97.0.973888388426.issue14588@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 06:31:07 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 20 Apr 2012 04:31:07 +0000 Subject: [issue14628] Clarify import statement documentation regarding what gets bound Message-ID: <1334896267.8.0.0783452284973.issue14628@psf.upfronthosting.co.za> New submission from Eric Snow : (see #14609 and #14582) http://docs.python.org/dev/reference/simple_stmts.html#the-import-statement The specification for the import statement says the following: "The first form of import statement binds the module name in the local namespace to the module object". This is not the case and has not been the case perhaps ever. Instead of getting bound to the module (returned by loader.load_module() during import), the name is bound to the value at sys.modules[module_name]. Normally two approaches yield the same result. However, if during import the sys.modules value for the module is assigned to something else, the behavior deviates from the specfication. See #14609 for an example. Considering the backwards-compatibility issues, the language reference should be updated to reflect the actual behavior. ---------- assignee: docs at python components: Documentation messages: 158793 nosy: benjamin.peterson, brett.cannon, docs at python, eric.snow priority: normal severity: normal status: open title: Clarify import statement documentation regarding what gets bound versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 06:37:43 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 20 Apr 2012 04:37:43 +0000 Subject: [issue14627] Fatal Python Error when Python startup is interrupted by CTRL+c In-Reply-To: <1334880082.24.0.373368528623.issue14627@psf.upfronthosting.co.za> Message-ID: <1334896663.57.0.114084849767.issue14627@psf.upfronthosting.co.za> R. David Murray added the comment: I think Victor's point was that you get the "can't initialize standard streams" in addition to the KeyboardInterrupt (but I'm just guessing). (See issue 14228 for examples of what normally happens on a startup KeyboardInterrupt.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 06:45:47 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 20 Apr 2012 04:45:47 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1334897147.7.0.354490019122.issue14626@psf.upfronthosting.co.za> R. David Murray added the comment: No, Guido's boolean keyword dislike is not about things being unclear at the call site. It's about boolean parameters instead of separate functions. That is (I believe) he prefers lstat/stat to having stat take a boolean keyword, keyword-only or not. Did he weigh in on the python-ideas thread? ---------- nosy: +r.david.murray type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 06:55:03 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 20 Apr 2012 04:55:03 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1334897703.97.0.223067866374.issue14626@psf.upfronthosting.co.za> Larry Hastings added the comment: r.david.murray said: > No, Guido's boolean keyword dislike is not about things > being unclear at the call site. I wasn't referring to Guido specifically, just general code smell complaints about boolean parameters. > That is (I believe) he prefers lstat/stat to having stat take > a boolean keyword, keyword-only or not. > > Did he weigh in on the python-ideas thread? Not per se. But I ran into him when he was leaving PyCon 2012 for good (second night of the sprints iirc), and he steered me to the original python-ideas thread and asked me to follow up on it / work with the poster. (Probably because of my doing the nanosecond-precision os.stat / utime work.) If there's genuine opposition to the patch being generated here I'll ping him. Oh, btw storchaka, in the email thread you asked > how the user code will check the availability of > dirfd functionality. Special global flags in os or sys? No--it'll just be part of a release, and you'll check which version of Python 3 you have before using it. if sys.version_info.major >= 3 or sys.version_info.minor >= 3: # use extra flags p.s. http://mail.python.org/pipermail/python-ideas/2012-March/014482.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 07:17:18 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 20 Apr 2012 05:17:18 +0000 Subject: [issue14629] discrepency between tokenize.detect_encoding() and PyTokenizer_FindEncodingFilename() Message-ID: <1334899038.03.0.61083358932.issue14629@psf.upfronthosting.co.za> New submission from Eric Snow : (see http://mail.python.org/pipermail/python-dev/2012-April/118889.html) The behavior of tokenize.detect_encoding() and PyTokenizer_FindEncodingFilename() is unexpectedly different and this has bearing on the current work on imports. When a file has no encoding indicator (see PEP 263) it falls back to UTF8 (see PEP 3120). The tokenize module (Lib/tokenize.py) facilitates this through "detect_encoding()". The CPython internal tokenizer (Python/tokenizer.c) does so through "PyTokenizer_FindEncodingFilename()". Both check the first two lines of the file, per PEP 263. When faced with an unparsable file (per the encoding), tokenize.detect_encoding() will gladly give you the encoding without any fuss. However, PyTokenizer_FindEncodingFilename() will raise a SyntaxError in that situation. The 'badsyntax_pep3120' test (Lib/test/badsyntax_pep3120.py) is one module that demonstrates this discrepency. I'll use it in the following example. --- For tokenize.detect_encoding(): import tokenize enc = tokenize.detect_encoding(open("cpython/Lib/test/badsyntax_pep3120.py").readline) print(enc) # "utf-8" (no SyntaxError) For PyTokenizer_FindEncodingFilename(): I've attached the source for a C extension module ('_tokenizer') that wraps PyTokenizer_FindEncodingFilename(). import _tokenizer enc = _tokenizer.detect_encoding("cpython/Lib/test/badsyntax_pep3120.py") print(enc) # raises SyntaxError --- Some relevant, related notes: The discrepencies extend further too. The following code returns a UnicodeDecodeError, rather than a SyntaxError: tokenize.tokenize(open("/home/esnow/projects/import_cleanup/Lib/test/badsyntax_pep3120.py").readline) In 3.1 (C-based import machinery, Python/import.c), the following results in a SyntaxError, during encoding detection. In the current repo tip (importlib-based import machinery, Lib/importlib/_bootstrap.py), the following results in a SyntaxError much later, during compilation. import test.badsyntax_pep3120 importlib uses tokenize.detect_encoding() and import.c uses PyTokenizer_FindEncodingFilename()... ---------- components: Library (Lib) files: _tokenizer.c messages: 158797 nosy: brett.cannon, eric.snow, loewis priority: normal severity: normal status: open title: discrepency between tokenize.detect_encoding() and PyTokenizer_FindEncodingFilename() type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file25283/_tokenizer.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 07:17:48 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 20 Apr 2012 05:17:48 +0000 Subject: [issue14629] discrepency between tokenize.detect_encoding() and PyTokenizer_FindEncodingFilename() In-Reply-To: <1334899038.03.0.61083358932.issue14629@psf.upfronthosting.co.za> Message-ID: <1334899068.12.0.0325955141785.issue14629@psf.upfronthosting.co.za> Changes by Eric Snow : Added file: http://bugs.python.org/file25284/setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 08:08:58 2012 From: report at bugs.python.org (Joe Peterson) Date: Fri, 20 Apr 2012 06:08:58 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1334902138.35.0.900361575899.issue10941@psf.upfronthosting.co.za> Joe Peterson added the comment: OK, fixed patch to apply cleanly to current code. BTW, this is only for python3. Is it still appropriate to patch python2? And if so, what is the correct code repo to check out for that? ---------- versions: +Python 3.4 Added file: http://bugs.python.org/file25285/issue10941_python3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 08:14:51 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 20 Apr 2012 06:14:51 +0000 Subject: [issue14628] Clarify import statement documentation regarding what gets bound In-Reply-To: <1334896267.8.0.0783452284973.issue14628@psf.upfronthosting.co.za> Message-ID: <1334902491.75.0.140385161554.issue14628@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 08:18:25 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 20 Apr 2012 06:18:25 +0000 Subject: [issue14629] discrepency between tokenize.detect_encoding() and PyTokenizer_FindEncodingFilename() In-Reply-To: <1334899038.03.0.61083358932.issue14629@psf.upfronthosting.co.za> Message-ID: <1334902705.34.0.94362723989.issue14629@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 08:31:39 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 20 Apr 2012 06:31:39 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za> Message-ID: <1334903499.88.0.309097935459.issue13994@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 08:34:17 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 20 Apr 2012 06:34:17 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za> Message-ID: <1334903657.27.0.35462983867.issue13994@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 08:35:36 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 20 Apr 2012 06:35:36 +0000 Subject: [issue14624] Faster utf-16 decoder In-Reply-To: <1334869141.17.0.802149162715.issue14624@psf.upfronthosting.co.za> Message-ID: <1334903736.05.0.315910356544.issue14624@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 08:35:47 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Apr 2012 06:35:47 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1334903747.78.0.163964535333.issue14626@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you, Larry. I was going to do it, but got stuck with other things. The main objective of this proposal is to get rid of litter os module by dozen rarely popular and non-portable functions (introduced by issue4761). Moreover, the descriptions are given in alphabetical order and related functions are located far from each other. > So I'd spell those "dir_fd", "src_dir_fd" (etc), "remove_dir", and "follow_symlinks". I follow the common style. `followlinks` is already used in other functions. > No--it'll just be part of a release, and you'll check which version of Python 3 you have before using it. Presence of function depends not only on the version, but also from the platform. Benjamin, therefore I believe it is critically important to do this work before the release of Python 3.3. To people and have not started to use the new features. Otherwise, get rid of them will be more difficult. But I have nothing against to put "at"-functions in a separate submodule (os.posix?). David, let lstat remains. fstatat include functionality both stat and lstat (but has a different interface). I suggest to unite fstatat and stat, while maintaining backward compatibility and using a more user-friendly interface. In the C extension of the functions is impossible, that is why were introduced new functions with other names. ---------- components: +Library (Lib) versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 08:36:35 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 20 Apr 2012 06:36:35 +0000 Subject: [issue14625] Faster utf-32 decoder In-Reply-To: <1334869197.32.0.159275934867.issue14625@psf.upfronthosting.co.za> Message-ID: <1334903795.7.0.010518163363.issue14625@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 08:38:39 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 20 Apr 2012 06:38:39 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1334903919.37.0.941103000472.issue14579@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 08:40:35 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 20 Apr 2012 06:40:35 +0000 Subject: [issue14614] PyTuple_SET_ITEM could check bounds in debug mode In-Reply-To: <1334761414.21.0.756614621806.issue14614@psf.upfronthosting.co.za> Message-ID: <1334904035.2.0.636677646394.issue14614@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 08:44:37 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 20 Apr 2012 06:44:37 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1334904277.2.0.891934614743.issue14428@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 08:45:49 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 20 Apr 2012 06:45:49 +0000 Subject: [issue14617] confusing docs with regard to __hash__ In-Reply-To: <1334771728.14.0.513778784524.issue14617@psf.upfronthosting.co.za> Message-ID: <1334904349.92.0.487223163139.issue14617@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 08:46:42 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 06:46:42 +0000 Subject: [issue14381] Intern certain integral floats for memory savings and performance In-Reply-To: <1332352043.3.0.236525644282.issue14381@psf.upfronthosting.co.za> Message-ID: <1334904402.69.0.956915334925.issue14381@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Because "pfval" in this example doesn't exist but is merely a temporary, > there is no aliasing. Maybe aliasing wasn't the right word to use, then. The exact rule being violated is C99 6.5, para. 7 (or C11 6.5 para. 7 if you prefer): """ An object shall have its stored value accessed only by an lvalue expression that has one of the following types: ... """ In any case, I don't think it's relevant whether the values involved are named variables or temporaries. > I don't think we could have our own floating point formatting library > if we didn't make that assumption There are configure-time checks that determine whether that floating-point formatting library is used or not, including (amongst some other things) whether the underlying floating-point type is IEEE 754. Officially, Python shouldn't assume IEEE 754 floating-point anywhere---the core should build fine without it, and there's lots of code in the core to deal with non-IEEE 754 platforms. > And should such a platform be found, it is easy enough to disable this > code for it. I think that's the wrong way around: the code should only be enabled in the first place when we're sure that the platform is IEEE 754. That shouldn't be hard to build into the patch, since the checks for IEEE 754 are already all over the place for other purposes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 08:46:59 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 20 Apr 2012 06:46:59 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1334904419.9.0.972216470604.issue2377@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 08:51:32 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 20 Apr 2012 06:51:32 +0000 Subject: [issue14618] remove modules_reloading from the interpreter state In-Reply-To: <1334799147.41.0.250628519615.issue14618@psf.upfronthosting.co.za> Message-ID: <1334904692.37.0.296185509703.issue14618@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 08:52:54 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Apr 2012 06:52:54 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1334904774.81.0.0673772186109.issue14626@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Before starting to code, it is necessary to solve the problem of interface. With the majority of the functions all is good, but the `link` and `rename` have two `dirfd` parameters (even with different names). So I suggest two more alternatives. One is the filename and dirfd are combined in a tuple. Instead of a tuple, you can specify only the name. link ((srcpath, srcdirfd), (dstpath, dstdirfd), *, followlinks=True) The other -- `dirfd`s are combined in a tuple. You can specify a number, then `dirfd` is the same for both filenames. link (srcpath, dstpath, *, followlinks=True, dirfd=(srcdirfd, dstdirfd)) Which of these options (or the original, with different keywords) is preferable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 09:40:18 2012 From: report at bugs.python.org (Larry Hastings) Date: Fri, 20 Apr 2012 07:40:18 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1334907618.8.0.785500981261.issue14626@psf.upfronthosting.co.za> Larry Hastings added the comment: It's true that, for example, dir_fd parameters won't work on Windows. The solution is to always accept the parameters and throw NotImplementedError on platforms where the functionality isn't available. Here are my thoughts on the interface for link(). Since the two dir_fd parameters are independent--you might specify none, one, or both--I think the dir_fd=(src,dst) form would be obnoxious. And polymorphic parameters (accept a string or a tuple of string and fd) are nearly always a bad idea; the % operator on strings is a good example of what can go wrong. So I think you should stick with the original interface, with independent explicit keyword arguments. I'd prefer that we did this everywhere it made sense, including adding a follow_symlinks parameter to stat(). But obviously you should prioritize places where we want to get rid of functions that are only in trunk (3.3) so far. I suppose there's precedent for "followlinks"; it's very old, predating PEP 8. Personally I'd overlook it if I were doing the implementation and spell the new parameters "follow_symlinks"--or at least I'd try it and see what the community thought. Anyway, there's no established precedent for "dir_fd" and "remove_dir". So I'd certainly prefer PEP 8 spellings for those. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 09:51:23 2012 From: report at bugs.python.org (Brecht Machiels) Date: Fri, 20 Apr 2012 07:51:23 +0000 Subject: [issue14630] non-deterministic behavior of int subclass Message-ID: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> New submission from Brecht Machiels : I have subclassed int to add an extra attribute: class Integer(int): def __new__(cls, value, base=10, indirect=False): try: obj = int.__new__(cls, value, base) except TypeError: obj = int.__new__(cls, value) return obj def __init__(self, value, base=10, indirect=False): self.indirect = indirect Using this class in my application, int(Integer(b'0')) sometimes returns a value of 48 (= ord('0')!) or 192, instead of the correct value 0. str(Integer(b'0')) always returns '0'. This seems to only occur for the value 0. First decoding b'0' to a string, or passing int(b'0') to Integer makes no difference. The problem lies with converting an Integer(0) to an int with int(). Furthermore, this occurs in a random way. Subsequent runs will produce 48 or 192 at different points in the application (a parser). Both Python 3.2.2 and 3.2.3 behave the same (32-bit, Windows XP). Apparently, the 64-bit Windows Python 3.2.3 does not show this behavior [2]. I haven't tested on other operating systems. I cannot seem to reproduce this in a simple test program. The following produces no output: for i in range(100000): integer = int(Integer(b'0')) if integer > 0: print(integer) Checking for the condition int(Integer()) > 0 in my application (when I know the argument to Integer is b'0') and conditionally printing int(Integer(b'0')) a number of times, the results 48 and 192 do show up now and then. As I can't reproduce the problem in a short test program, I have attached the relevant code. It is basically a PDF parser. The output for this [2] PDF file is, for example: b'0' 0 Integer(0) 192 0 b'0' 16853712 b'0' 0 Integer(0) 48 0 b'0' 16938088 b'0' 0 Integer(0) 192 0 b'0' 17421696 b'0' 0 Integer(0) 48 0 b'0' 23144888 b'0' 0 Integer(0) 48 0 b'0' 23185408 b'0' 0 Integer(0) 48 0 b'0' 23323272 Search for print function calls in the code to see what this represents. [1] http://stackoverflow.com/questions/10230604/non-deterministic-behavior-of-int-subclass#comment13156508_10230604 [2] http://www.gust.org.pl/projects/e-foundry/math-support/vieth2008.pdf ---------- components: None files: pdf.py messages: 158803 nosy: brechtm priority: normal severity: normal status: open title: non-deterministic behavior of int subclass type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file25286/pdf.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 10:07:05 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 08:07:05 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334909225.49.0.172460232314.issue14630@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 10:13:49 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 20 Apr 2012 08:13:49 +0000 Subject: [issue14627] Fatal Python Error when Python startup is interrupted by CTRL+c In-Reply-To: <1334896663.57.0.114084849767.issue14627@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > OK, so what's your point? =) In Python < 3.3, CTRL+c at startup fails with "Traceback: ...", not with a fatal error. A fatal error may dump a core dump and open a popup on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 10:38:13 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 20 Apr 2012 08:38:13 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <1334874876.32.0.804955543463.issue13994@psf.upfronthosting.co.za> Message-ID: <4F91206E.1010207@egenix.com> Marc-Andre Lemburg added the comment: Ned Deily wrote: > > Ned Deily added the comment: > > That's unfortunate. But the documented location for customize_compiler is and, AFAIK, had always been in distutils.sysconfig. It was an inadvertent consequence of the bad revert during the 2.7 development cycle that a second copy was made available in distutils.ccompiler. That change was not supposed to be released in 2.7 and was never documented. So I don't think there is anything that can or needs to be done as this point in Python itself. Other opinions? Excuse me, Ned, but that's not how we do approach dot releases in Python. Regardless of whether the documentation was fixed or not, you cannot simply remove a non-private function without making sure that at least the import continues to work. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 10:42:06 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 20 Apr 2012 08:42:06 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za> Message-ID: <1334911326.74.0.890990814101.issue13994@psf.upfronthosting.co.za> Changes by Marc-Andre Lemburg : ---------- resolution: fixed -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 10:45:15 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 20 Apr 2012 08:45:15 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <1334878066.35.0.49727899827.issue13994@psf.upfronthosting.co.za> Message-ID: <4F912213.4040902@egenix.com> Marc-Andre Lemburg added the comment: Ned Deily wrote: > > And to recap the history here, there was a change in direction for Distutils during the 2.7 development cycle, as decided at the 2010 language summit, in particular to revert feature changes in Distutils for 2.7 to its 2.6.x state and, going forward, "Distutils in Python will be feature-frozen". > > http://mail.python.org/pipermail/python-dev/2010-March/098135.html I know that distutils development was stopped (even though I don't consider that a good thing), but since the code changes were let into the wild, we have to deal with it properly now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 11:12:28 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 20 Apr 2012 09:12:28 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <4F91206E.1010207@egenix.com> Message-ID: <4F912875.4090606@egenix.com> Marc-Andre Lemburg added the comment: Marc-Andre Lemburg wrote: > >> Ned Deily added the comment: >> >> That's unfortunate. But the documented location for customize_compiler is and, AFAIK, had always been in distutils.sysconfig. It was an inadvertent consequence of the bad revert during the 2.7 development cycle that a second copy was made available in distutils.ccompiler. That change was not supposed to be released in 2.7 and was never documented. So I don't think there is anything that can or needs to be done as this point in Python itself. Other opinions? > > Excuse me, Ned, but that's not how we do approach dot releases in Python. > > Regardless of whether the documentation was fixed or not, you cannot > simply remove a non-private function without making sure that at least > the import continues to work. Turns out, the "fix" broke all our packages for Python 2.7.3 and I can hardly believe we're the only ones affected by this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 11:12:42 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 20 Apr 2012 09:12:42 +0000 Subject: [issue14381] Intern certain integral floats for memory savings and performance In-Reply-To: <1332352043.3.0.236525644282.issue14381@psf.upfronthosting.co.za> Message-ID: <1334913162.57.0.413707890586.issue14381@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Interesting. I declare that this rule does not apply here since the code is a deliberate hack: We are pretending that a certain address points to integers and checking those integers. If you insist on following the standard, you could do double cmp = 0; return mcmcmp(&cmp, fval, sizeof(fval)) == 0; but on all real machines this is the same as: PY_LONG_LONG cmp = 0; return mcmcmp(&cmp, fval, sizeof(fval)) == 0; Which again is the same as return *(PY_LONG_LONG*)&fval == 0; technically speaking, even if the standard doesn't agree. You could implement this with in-line assembly and so cheerfully sidestep the standard. When you're hacking, your're hacking and the standard isn't your friend :) Anyway, this proposal has been rejected due to lack of interest or some misguided idea of performance, so the point is moot. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 11:13:32 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 20 Apr 2012 09:13:32 +0000 Subject: [issue14381] Intern certain integral floats for memory savings and performance In-Reply-To: <1332352043.3.0.236525644282.issue14381@psf.upfronthosting.co.za> Message-ID: <1334913212.28.0.121331826357.issue14381@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- Removed message: http://bugs.python.org/msg158808 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 11:14:55 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 20 Apr 2012 09:14:55 +0000 Subject: [issue14381] Intern certain integral floats for memory savings and performance In-Reply-To: <1332352043.3.0.236525644282.issue14381@psf.upfronthosting.co.za> Message-ID: <1334913295.07.0.583844817948.issue14381@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Interesting. I declare that this rule does not apply here since the code is a deliberate hack: We are pretending that a certain address points to integers and checking those integers. If you insist on following the standard, you could do double cmp = 0; return mcmcmp(&cmp, &fval, sizeof(fval)) == 0; but on all real machines this is the same as: PY_LONG_LONG cmp = 0; return mcmcmp(&cmp, &fval, sizeof(fval)) == 0; Which again is the same as return *(PY_LONG_LONG*)&fval == 0; technically speaking, even if the standard doesn't agree. You could implement this with in-line assembly and so cheerfully sidestep the standard. When you're hacking, your're hacking and the standard isn't your friend :) As for IEEE, sure, anyway that thing is oriented is fine, although in this day and age, I find it rather amusing that the logic thinks of IEEE support as the exception, rather than the rule. Anyway, this proposal has been rejected due to lack of interest or some misguided idea of performance, so the point is moot. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 11:53:23 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 20 Apr 2012 09:53:23 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1334915603.51.0.635458785241.issue14579@psf.upfronthosting.co.za> Martin v. L?wis added the comment: [moving from Rietveld back to Roundup] On 2012/04/20 11:15:48, storchaka wrote: > The `aligned_end` may point outside unicode object, > if the unicode object was reallocated. How so? The aligned_end *never* points into the unicode object: q = (unsigned char *)s; e = q + size - 1; aligned_end = (const unsigned char *) ((size_t) e & ~LONG_PTR_MASK); So aligned_end points into s, not into the unicode object. So this adjustment is necessary because the *input* may change in the callback, not because the output may change. So the comment in decode_utf8_errors seems just as wrong. Why this is relevant to this issue, is unclear to me, though: the ignore handler doesn't modify the input object. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 11:54:11 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 09:54:11 +0000 Subject: [issue14381] Intern certain integral floats for memory savings and performance In-Reply-To: <1332352043.3.0.236525644282.issue14381@psf.upfronthosting.co.za> Message-ID: <1334915651.72.0.0285150596761.issue14381@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I declare that this rule does not apply here ... Clearly the gcc developers disagree. :-) iwasawa:~ mdickinson$ cat test2.c int is_positive_zero(double f) { return *(long long*)&f == 0; } iwasawa:~ mdickinson$ gcc -fstrict-aliasing -O3 -Wall -Wextra -Wstrict-aliasing -c test2.c test2.c: In function ?is_positive_zero?: test2.c:2: warning: dereferencing type-punned pointer will break strict-aliasing rules ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 12:01:57 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 10:01:57 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334916117.52.0.896829904143.issue14630@psf.upfronthosting.co.za> Mark Dickinson added the comment: I can reproduce this on a 32-bit OS X build of the default branch, so it doesn't seem to be Windows specific (though it may be 32-bit specific). Brecht, if you can find a way to reduce the size of your example at all that would be really helpful. ---------- priority: normal -> high versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 12:41:08 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 20 Apr 2012 10:41:08 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1334918468.03.0.0472567820038.issue10142@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I am going to integrate next week Please, review. ---------- assignee: -> jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 12:53:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 20 Apr 2012 10:53:33 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334919213.24.0.942026374344.issue14630@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Reproduced under 32-bit Linux. The problem seems to be that Py_SIZE(x) == 0 when x is Integer(0), but ob_digit[0] is still supposed to be significant. There's probably some overwriting with the trailing attributes. By forcing Py_SIZE(x) == 1, the bug disappears, but it probably breaks lots of other stuff in longobject.c. ---------- nosy: +pitrou, skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 12:56:45 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 10:56:45 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334919405.99.0.218553265573.issue14630@psf.upfronthosting.co.za> Mark Dickinson added the comment: If we're accessing ob_digit[0] when Py_SIZE(x) == 0, that sounds like a bug to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 13:07:07 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 20 Apr 2012 11:07:07 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334920027.81.0.87008687463.issue14630@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > If we're accessing ob_digit[0] when Py_SIZE(x) == 0, that sounds like a > bug to me. _PyLong_Copy does. It's ok as long as the object is int(0), because it's part of the small ints and its allocated size is one digit. The following hack seems to fix the issue here. Perhaps we can simply fix _PyLong_Copy, but I wonder how many other parts of longobject.c rely on accessing ob_digit[0]. diff --git a/Objects/longobject.c b/Objects/longobject.c --- a/Objects/longobject.c +++ b/Objects/longobject.c @@ -4194,6 +4194,8 @@ long_subtype_new(PyTypeObject *type, PyO n = Py_SIZE(tmp); if (n < 0) n = -n; + if (n == 0) + n = 1; newobj = (PyLongObject *)type->tp_alloc(type, n); if (newobj == NULL) { Py_DECREF(tmp); diff --git a/Objects/object.c b/Objects/object.c --- a/Objects/object.c +++ b/Objects/object.c @@ -1010,6 +1010,8 @@ PyObject ** tsize = ((PyVarObject *)obj)->ob_size; if (tsize < 0) tsize = -tsize; + if (tsize == 0 && PyLong_Check(obj)) + tsize = 1; size = _PyObject_VAR_SIZE(tp, tsize); dictoffset += (long)size; @@ -1090,6 +1092,8 @@ PyObject * tsize = ((PyVarObject *)obj)->ob_size; if (tsize < 0) tsize = -tsize; + if (tsize == 0 && PyLong_Check(obj)) + tsize = 1; size = _PyObject_VAR_SIZE(tp, tsize); dictoffset += (long)size; ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 13:35:59 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 11:35:59 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334921759.7.0.603451536911.issue14630@psf.upfronthosting.co.za> Mark Dickinson added the comment: > _PyLong_Copy does. Grr. So it does. That at least should be fixed, but I agree that it would be good to have the added protection of ensuring that we always allocate space for at least one limb. We should also check whether 2.7 is susceptible. ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 13:43:35 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Apr 2012 11:43:35 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334915603.51.0.635458785241.issue14579@psf.upfronthosting.co.za> Message-ID: <1334922361.22625.180.camel@raxxla> Serhiy Storchaka added the comment: > So this adjustment is necessary because the *input* may change in the callback, > not because the output may change. So the comment in decode_utf8_errors seems > just as wrong. You're right, and my eyes in a lather. Now I saw it. What you have to offer any comment? If someone would correct a comment for decode_utf8_errors, I just copied it. > Why this is relevant to this issue, is unclear to me, though: the ignore handler > doesn't modify the input object. I first got the crash using a custom handler, and then I saw that "ignore" handler is enough. Even if the "ignore" handler does not have to change the input object, other handlers can do it and this is the reason for the crash remains. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 13:45:03 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 11:45:03 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334922303.63.0.602169853598.issue14630@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 13:53:11 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 11:53:11 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334922791.66.0.451260420395.issue14630@psf.upfronthosting.co.za> Mark Dickinson added the comment: Self-contained example that fails for me on 32-bit OS X. class Integer(int): def __new__(cls, value, base=10, indirect=False): try: obj = int.__new__(cls, value, base) except TypeError: obj = int.__new__(cls, value) return obj def __init__(self, value, base=10, indirect=False): self.indirect = indirect integers = [] for i in range(1000): integer = Integer(b'0') integers.append(integer) for integer in integers: assert int(integer) == 0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 13:55:19 2012 From: report at bugs.python.org (Ned Deily) Date: Fri, 20 Apr 2012 11:55:19 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za> Message-ID: <1334922919.03.0.924012636121.issue13994@psf.upfronthosting.co.za> Ned Deily added the comment: I agree that we should always try very hard not to break anything in point releases. But I think it is fair to say that this is an unusual case. Looking at the commit logs (and Tarek can correct me if I misread them), it appears the change that, among other things, moved customize_compiler was committed on 2010-01-23, in time for 2.7alpha3. The language summit decision followed soon thereafter and the faulty partial revert happened on 2010-03-05, in time for 2.7alpha4. So, if the revert had been completed as intended, the moved module should have only been in the wild for a little over a month. Clearly you had a vested interest in making the change to your code base but it seems unlikely that anyone else would have gone to the trouble of changing their code since existing (2.6) code would have only been broken for that one small alpha window, 2.7 alpha3. And considering that customize_compiler is probably not used by all that many packages to begin with it, I would think it is not unlikely that you *are* the only ones affected by it. Nevertheless, what are the alternatives? We could add a wrapper function into distutils.ccompiler that just calls the distutils.sysconfig version. Here's a patch that attempts to do so. That should fix that breakage for the eGenix packages. It would be great if you could test it. It's up to the 2.7 release manager to decide what action to take, i.e. whether the patch is needed and, if so, how quickly to schedule a new release. As a practical matter, regardless of whether the patch is applied in Python or not, I would assume that a faster solution for your end users would be to ship a version of the eGenix packages that reverts the changes(s) there. By the way, it looks like you'll need to eventually do that anyway since the code in mxSetup.py incorrectly assumes that the corresponding changes were also made to Python 3.2. ---------- priority: normal -> release blocker stage: committed/rejected -> patch review Added file: http://bugs.python.org/file25287/issue13994_compat.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 13:55:57 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 20 Apr 2012 11:55:57 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334922361.22625.180.camel@raxxla> Message-ID: <4F914ECB.2020904@v.loewis.de> Martin v. L?wis added the comment: > You're right, and my eyes in a lather. Now I saw it. > > What you have to offer any comment? If someone would correct a comment > for decode_utf8_errors, I just copied it. "might have changed the input object" >> Why this is relevant to this issue, is unclear to me, though: the ignore handler >> doesn't modify the input object. > > I first got the crash using a custom handler, and then I saw that > "ignore" handler is enough. Even if the "ignore" handler does not have > to change the input object, other handlers can do it and this is the > reason for the crash remains. I agree that the change is necessary. It just does not explain why it fixes this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 14:06:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 20 Apr 2012 12:06:29 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334923589.41.0.732390815293.issue14630@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The fix for _PyLong_Copy is the following: diff --git a/Objects/longobject.c b/Objects/longobject.c --- a/Objects/longobject.c +++ b/Objects/longobject.c @@ -156,7 +156,7 @@ PyObject * if (i < 0) i = -(i); if (i < 2) { - sdigit ival = src->ob_digit[0]; + sdigit ival = (i == 0) ? 0 : src->ob_digit[0]; if (Py_SIZE(src) < 0) ival = -ival; CHECK_SMALL_INT(ival); ---------- assignee: mark.dickinson -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 14:06:37 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 20 Apr 2012 12:06:37 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334923597.18.0.380385736183.issue14630@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- components: +Interpreter Core -None stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 14:18:37 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 12:18:37 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334924317.59.0.767222891976.issue14630@psf.upfronthosting.co.za> Mark Dickinson added the comment: Using MEDIUM_VALUE also works. I'll cook up a patch tonight, after work. diff -r 6762b943ee59 Objects/longobject.c --- a/Objects/longobject.c Tue Apr 17 21:42:07 2012 -0400 +++ b/Objects/longobject.c Fri Apr 20 13:18:01 2012 +0100 @@ -156,9 +156,7 @@ if (i < 0) i = -(i); if (i < 2) { - sdigit ival = src->ob_digit[0]; - if (Py_SIZE(src) < 0) - ival = -ival; + sdigit ival = MEDIUM_VALUE(src); CHECK_SMALL_INT(ival); } result = _PyLong_New(i); ---------- assignee: -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 14:37:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Apr 2012 12:37:26 +0000 Subject: [issue14629] discrepency between tokenize.detect_encoding() and PyTokenizer_FindEncodingFilename() In-Reply-To: <1334899038.03.0.61083358932.issue14629@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b07488490001 by Martin v. L?wis in branch '3.2': Issue #14629: Raise SyntaxError in tokenizer.detect_encoding http://hg.python.org/cpython/rev/b07488490001 New changeset 98a6a57c5876 by Martin v. L?wis in branch 'default': merge 3.2: issue 14629 http://hg.python.org/cpython/rev/98a6a57c5876 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 14:39:38 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 20 Apr 2012 12:39:38 +0000 Subject: [issue14629] discrepency between tokenize.detect_encoding() and PyTokenizer_FindEncodingFilename() In-Reply-To: <1334899038.03.0.61083358932.issue14629@psf.upfronthosting.co.za> Message-ID: <1334925578.25.0.24902924781.issue14629@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the report. This is now fixed in 3.2 and default. Notice that your usage tokenize is incorrect: you need to open the file in binary mode. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 14:47:34 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 20 Apr 2012 12:47:34 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <1334922919.03.0.924012636121.issue13994@psf.upfronthosting.co.za> Message-ID: <4F915ADE.7050103@egenix.com> Marc-Andre Lemburg added the comment: ink it is not unlikely that you *are* the only ones affected by it. With "in the wild" I'm referring to the function being released in the ccompiler not only in alpha releases but also in the beta releases, the 2.7, 2.7.1 and 2.7.2 release - in every release since early in 2010. We were unaware of the reversal of the changes by Tarek and the way we coded things in mxSetup.py did not show that things were removed again, simply because we support more than just Python 2.7 and have proper fallback solutions for most things. Only in this particular case, we were using different strategies based on the Python version number and so there is no fallback. > Nevertheless, what are the alternatives? We could add a wrapper function into distutils.ccompiler that just calls the distutils.sysconfig version. Here's a patch that attempts to do so. That should fix that breakage for the eGenix packages. It would be great if you could test it. The fix is easy: simply import the customize_compiler() API in the ccompiler module to maintain compatibility with what had already been release. No need to add a wrapper function, a single from distutils.sysconfig import customize_compiler() in ccompile.py will do just fine. > It's up to the 2.7 release manager to decide what action to take, i.e. whether the patch is needed and, if so, how quickly to schedule a new release. As a practical matter, regardless of whether the patch is applied in Python or not, I would assume that a faster solution for your end users would be to ship a version of the eGenix packages that reverts the changes(s) there. By the way, it looks like you'll need to eventually do that anyway since the code in mxSetup.py incorrectly assumes that the corresponding changes were also made to Python 3.2. We don't support Python 3.x yet, so that's a non-issue at the moment. But yes, we will have to release new patch level releases for all our packages to get this fixed for our users. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 15:41:17 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 20 Apr 2012 13:41:17 +0000 Subject: [issue14381] Intern certain integral floats for memory savings and performance In-Reply-To: <1332352043.3.0.236525644282.issue14381@psf.upfronthosting.co.za> Message-ID: <1334929277.26.0.950055449476.issue14381@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Dang. I yield! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 15:49:42 2012 From: report at bugs.python.org (Sundance) Date: Fri, 20 Apr 2012 13:49:42 +0000 Subject: [issue14631] Instance methods and WeakRefs don't mix. Message-ID: <1334929782.59.0.560223623807.issue14631@psf.upfronthosting.co.za> New submission from Sundance : SUMMARY ======= The behavior of instance methods makes it impossible to keep a weakref on them. The reference dies instantly even if the instance and the method still exist. EXAMPLE ======= >>> import weakref >>> callbacks = weakref.WeakSet() >>> def callback1(): ... print "In callback1." >>> class SomeClass: ... def callback2(self): ... print "In callback2." >>> some_instance = SomeClass() >>> callbacks.add( callback1 ) >>> callbacks.add( some_instance.callback2 ) >>> for callback in callbacks: ... callback() In callback1. >>> ## callback2 is never called! ANALYSIS ======== The WeakSet in the example above, and the weakref.ref() it employs, actually behave as specified. It's the particular nature of bound methods that causes the unexpected behavior. >From what I understand, instance methods are bound dynamically when looked up on the instance. A new object of type instancemethod is created each time: >>> t1 = some_instance.callback >>> t2 = some_instance.callback >>> t1 is t2 False So when a program calls weakref.ref(some_instance.callback), a new instancemethod object is created on the fly, a weakref to that object is created... and the instancemethod object dies, because its refcount is 0. This fundamental difference between instance methods and other callables makes it painful to implement weakly referencing callback registries. PROPOSED SOLUTION ================= Changing the fundamental nature of instance methods to accommodate one single corner case doesn't seem worthwhile. Similarly, changing the behavior of weakref.ref(), which does work as specified, is probably not a good idea. My approach is thus to provide a new helper, WeakCallableRef, that behaves like weakref.ref(), but is safe to use on callables and does what you would naturally expect with instance methods. It works by binding the lifetime of the ref to that of 1/ the instance bearing the method, and 2/ the unbound method itself. It is also safe to use on other function types beside instance methods, so implementations of callback registries don't have to special case depending on the callable type. The unexpected behavior should also be mentioned somewhere in the weakref documentation, by the way. See attached file for a proposed implementation. ---------- components: Library (Lib) files: WeakCallableRef.py messages: 158828 nosy: Sundance priority: normal severity: normal status: open title: Instance methods and WeakRefs don't mix. type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file25288/WeakCallableRef.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 15:57:08 2012 From: report at bugs.python.org (JohnM) Date: Fri, 20 Apr 2012 13:57:08 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception Message-ID: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> New submission from JohnM : The (very handy) logging.handlers.WatchedFileHandler appears to be susceptible to a race condition that causes occasional OSErrors during the normal course of operations: Traceback (most recent call last): File "test.py", line 58, in test_race log.warning('Foo bar %d', ii) File "/usr/lib64/python2.7/logging/__init__.py", line 1144, in warning self._log(WARNING, msg, args, **kwargs) File "/usr/lib64/python2.7/logging/__init__.py", line 1250, in _log self.handle(record) File "/usr/lib64/python2.7/logging/__init__.py", line 1260, in handle self.callHandlers(record) File "/usr/lib64/python2.7/logging/__init__.py", line 1300, in callHandlers hdlr.handle(record) File "/usr/lib64/python2.7/logging/__init__.py", line 744, in handle self.emit(record) File "/usr/lib64/python2.7/logging/handlers.py", line 412, in emit stat = os.stat(self.baseFilename) OSError: [Errno 2] No such file or directory: '/tmp/tmpG6_luRTestRaceWatchedFileHandler' Looking at the implementation of the handler's emit function, I've commented on where I think the race can occur. Logrotate (or some similar application) is deleting/unlinking the logfile between the first os.path.exists and os.stat calls: def emit(self, record): """ Emit a record. First check if the underlying file has changed, and if it has, close the old stream and reopen the file to get the current stream. """ if not os.path.exists(self.baseFilename): # ^^^ race occurs between here stat = None changed = 1 else: stat = os.stat(self.baseFilename) # ^^^ and this stat call changed = (stat[ST_DEV] != self.dev) or (stat[ST_INO] != self.ino) if changed and self.stream is not None: self.stream.flush() self.stream.close() self.stream = self._open() if stat is None: stat = os.stat(self.baseFilename) self.dev, self.ino = stat[ST_DEV], stat[ST_INO] logging.FileHandler.emit(self, record) I've attached a test script that attempts to recreate the issue. On my Linux system running the script is able to trigger the issue about every 7 of 10 runs. ---------- components: Library (Lib) files: test.py messages: 158829 nosy: phlogistonjohn priority: normal severity: normal status: open title: Race condition in WatchedFileHandler leads to unhandled exception type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file25289/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 16:43:03 2012 From: report at bugs.python.org (Patrick Hahn) Date: Fri, 20 Apr 2012 14:43:03 +0000 Subject: [issue1079] decode_header does not follow RFC 2047 In-Reply-To: <1188637019.25.0.0476259625696.issue1079@psf.upfronthosting.co.za> Message-ID: <1334932983.93.0.260013301671.issue1079@psf.upfronthosting.co.za> Changes by Patrick Hahn : ---------- nosy: +phahn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 16:58:59 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 20 Apr 2012 14:58:59 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1334933939.01.0.564427901646.issue11618@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Two runs with standard locks: D:\pydev\hg\cpython2>pcbuild\amd64\python.exe -m timeit -s "import _thread; l = _thread.allocate_lock()" l.acquire();l.release() 1000000 loops, best of 3: 0.746 usec per loop D:\pydev\hg\cpython2>pcbuild\amd64\python.exe -m timeit -s "import _thread; l = _thread.allocate_lock()" l.acquire();l.release() 1000000 loops, best of 3: 0.749 usec per loop Two runs with CV locks (emulated) D:\pydev\hg\cpython2>pcbuild\amd64\python.exe -m timeit -s "import _thread; l = _thread.allocate_lock()" l.acquire();l.release() 1000000 loops, best of 3: 0.278 usec per loop D:\pydev\hg\cpython2>pcbuild\amd64\python.exe -m timeit -s "import _thread; l = _thread.allocate_lock()" l.acquire();l.release() 1000000 loops, best of 3: 0.279 usec per loop Two runs with CV locks targeted for Vista: D:\pydev\hg\cpython2>pcbuild\amd64\python.exe -m timeit -s "import _thread; l = _thread.allocate_lock()" l.acquire();l.release() 1000000 loops, best of 3: 0.272 usec per loop D:\pydev\hg\cpython2>pcbuild\amd64\python.exe -m timeit -s "import _thread; l = _thread.allocate_lock()" l.acquire();l.release() 1000000 loops, best of 3: 0.272 usec per loop You can see the big win from not doing kernel switches all the time. shedding 60% of the time. Once in user space, moving from CriticalSection objects to SRWLock objects is less beneficial, being overshadowed by Python overhead. Still, 2% overall is not to be frowned upon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 17:09:11 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 20 Apr 2012 15:09:11 +0000 Subject: [issue14629] discrepency between tokenize.detect_encoding() and PyTokenizer_FindEncodingFilename() In-Reply-To: <1334899038.03.0.61083358932.issue14629@psf.upfronthosting.co.za> Message-ID: <1334934551.97.0.503807379043.issue14629@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks, Martin! That did the trick. ---------- versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 17:10:10 2012 From: report at bugs.python.org (JohnM) Date: Fri, 20 Apr 2012 15:10:10 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> Message-ID: <1334934610.98.0.79849823228.issue14632@psf.upfronthosting.co.za> JohnM added the comment: I'm attaching a patch of an emit function implementation that reduces the number of stats and uses fstat were we can. Using fstat should also prevent any races between opening the new file and stating the path in the file system. Using this patch or something along these lines should avoid the time of check to time of use issues with the current version with repeated stat calls. ---------- keywords: +patch Added file: http://bugs.python.org/file25290/watchedfilehandler.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 17:13:52 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 20 Apr 2012 15:13:52 +0000 Subject: [issue14628] Clarify import statement documentation regarding what gets bound In-Reply-To: <1334896267.8.0.0783452284973.issue14628@psf.upfronthosting.co.za> Message-ID: <1334934832.28.0.0540702325702.issue14628@psf.upfronthosting.co.za> Brett Cannon added the comment: So I think the sentence is saying exactly what is going on, but you want clarification that the module object is originating from sys.modules specifically. So you could change the sentence to "The first form of import statement binds the module name in the local namespace to the module object as found in sys.modules." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 17:16:21 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 15:16:21 +0000 Subject: [issue14631] Instance methods and WeakRefs don't mix. In-Reply-To: <1334929782.59.0.560223623807.issue14631@psf.upfronthosting.co.za> Message-ID: <1334934981.67.0.968059233699.issue14631@psf.upfronthosting.co.za> Mark Dickinson added the comment: I quite like the WeakCallableRef idea, having had to work around this problem myself in the past (using a similar mechanism). This looks like a feature request rather than a bug report, though; changing Type and Versions accordingly. ---------- nosy: +mark.dickinson stage: -> patch review type: behavior -> enhancement versions: +Python 3.3 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 17:16:25 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 20 Apr 2012 15:16:25 +0000 Subject: [issue14627] Fatal Python Error when Python startup is interrupted by CTRL+c In-Reply-To: <1334880082.24.0.373368528623.issue14627@psf.upfronthosting.co.za> Message-ID: <1334934985.05.0.394280678183.issue14627@psf.upfronthosting.co.za> Brett Cannon added the comment: Welcome to Python code running during startup. =) As I said, the only thing I can think of is raising the exception instead of catching it and immediately triggering the fatal exception, but that specific fatal error was not introduced by me so this is just a side-effect of having Python code running during startup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 17:17:51 2012 From: report at bugs.python.org (Mark Nottingham) Date: Fri, 20 Apr 2012 15:17:51 +0000 Subject: [issue8885] markupbase declaration errors aren't recoverable In-Reply-To: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za> Message-ID: <1334935071.69.0.853812841847.issue8885@psf.upfronthosting.co.za> Mark Nottingham added the comment: Why remove 2.7? It'd be an easy bug fix if j is incremented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 17:18:59 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 20 Apr 2012 15:18:59 +0000 Subject: [issue14633] test_find_module_encoding should test for a less specific message (or Message-ID: <1334935139.39.0.293792224706.issue14633@psf.upfronthosting.co.za> New submission from Eric Snow : test_find_module_encoding (in Lib/test/test_imp.py), has the following check: self.assertRaisesRegex(SyntaxError, r"Non-UTF-8 code starting with '\\xf6'" r" in file .*badsyntax_pep3120.py", imp.find_module, 'badsyntax_pep3120', path) It may be worth changing to something like this (aligning with the changes in issue14629): self.assertRaisesRegex(SyntaxError, r"invalid or missing encoding declaration", imp.find_module, 'badsyntax_pep3120', path) ---------- messages: 158837 nosy: brett.cannon, eric.snow priority: normal severity: normal status: open title: test_find_module_encoding should test for a less specific message (or _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 17:19:30 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 20 Apr 2012 15:19:30 +0000 Subject: [issue14633] test_find_module_encoding should test for a less specific message In-Reply-To: <1334935139.39.0.293792224706.issue14633@psf.upfronthosting.co.za> Message-ID: <1334935170.46.0.844486280799.issue14633@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- components: +Tests title: test_find_module_encoding should test for a less specific message (or -> test_find_module_encoding should test for a less specific message versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 17:22:03 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 20 Apr 2012 15:22:03 +0000 Subject: [issue14633] test_find_module_encoding should test for a less specific message In-Reply-To: <1334935139.39.0.293792224706.issue14633@psf.upfronthosting.co.za> Message-ID: <1334935323.38.0.213667282268.issue14633@psf.upfronthosting.co.za> Eric Snow added the comment: or even _not_ check the message string? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 17:24:34 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 20 Apr 2012 15:24:34 +0000 Subject: [issue14629] discrepency between tokenize.detect_encoding() and PyTokenizer_FindEncodingFilename() In-Reply-To: <1334899038.03.0.61083358932.issue14629@psf.upfronthosting.co.za> Message-ID: <1334935474.46.0.107379560549.issue14629@psf.upfronthosting.co.za> Eric Snow added the comment: Apparently the message string contained by the SyntaxError is different between the two. I noticed due to the hard-coded check in test_find_module_encoding (in Lib/test/test_imp.py). I've brought up the specific issue of that hard-coded message check in issue14633. However, in case it otherwise matters that the message string be the same between the two, I've brought it up here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 17:25:41 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 20 Apr 2012 15:25:41 +0000 Subject: [issue14627] Fatal Python Error when Python startup is interrupted by CTRL+c In-Reply-To: <1334880082.24.0.373368528623.issue14627@psf.upfronthosting.co.za> Message-ID: <1334935541.89.0.43381857446.issue14627@psf.upfronthosting.co.za> Stefan Krah added the comment: Hmm, I've managed to produce the error with 3.1: $ python3.1 Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "/usr/lib/python3.1/io.py", line 60, in import _io File "/usr/lib/python3.1/os.py", line 380, in from _abcoll import MutableMapping # Can't use collections (bootstrap) File "/usr/lib/python3.1/encodings/iso8859_15.py", line 14, in decode def decode(self,input,errors='strict'): KeyboardInterrupt Aborted ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 17:27:57 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 20 Apr 2012 15:27:57 +0000 Subject: [issue14628] Clarify import statement documentation regarding what gets bound In-Reply-To: <1334896267.8.0.0783452284973.issue14628@psf.upfronthosting.co.za> Message-ID: <1334935677.89.0.338946663768.issue14628@psf.upfronthosting.co.za> Eric Snow added the comment: Sounds mostly right. sys.modules[name] won't necessarily contain a module object, as Benjamin brought up in issue14609. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 17:32:19 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 20 Apr 2012 15:32:19 +0000 Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of customize_compiler In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za> Message-ID: <1334935939.9.0.291721135241.issue13994@psf.upfronthosting.co.za> ?ric Araujo added the comment: [MAL] > I know that distutils development was stopped (even though I don't consider that a good thing) This is OT, but could you tell a bit more? The freeze appears to me to have been a necessary decision due to the impossibility of making non-trivial changes without breaking setup scripts or projects such as mxSetup. > but since the code changes were let into the wild, we have to deal with it properly now. This I agree with. Saturday or Sunday I will have the time to commit a fix and test. ---------- assignee: ned.deily -> eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 17:34:08 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 20 Apr 2012 15:34:08 +0000 Subject: [issue14628] Clarify import statement documentation regarding what gets bound In-Reply-To: <1334896267.8.0.0783452284973.issue14628@psf.upfronthosting.co.za> Message-ID: <1334936048.02.0.911450737674.issue14628@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, so you say "to the object found in sys.modules." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 17:34:59 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 20 Apr 2012 15:34:59 +0000 Subject: [issue14627] Fatal Python Error when Python startup is interrupted by CTRL+c In-Reply-To: <1334880082.24.0.373368528623.issue14627@psf.upfronthosting.co.za> Message-ID: <1334936099.22.0.441986173389.issue14627@psf.upfronthosting.co.za> Brett Cannon added the comment: So importlib just increased the window of vulnerability for this kind of thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 17:47:07 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 20 Apr 2012 15:47:07 +0000 Subject: [issue14627] Fatal Python Error when Python startup is interrupted by CTRL+c In-Reply-To: <1334880082.24.0.373368528623.issue14627@psf.upfronthosting.co.za> Message-ID: <1334936827.74.0.139701059477.issue14627@psf.upfronthosting.co.za> Stefan Krah added the comment: The funny thing is, in 3.3 I can't reproduce it (i.e. I only get the KeyboardInterrupt). So I'm not sure if this happens more often now. ^CTraceback (most recent call last): File "", line 989, in _find_and_load File "", line 571, in load_module File "", line 228, in module_for_loader_wrapper File "", line 456, in _load_module File "/home/stefan/pydev/cpython/Lib/site.py", line 537, in main() [...] File "/home/stefan/pydev/cpython/Lib/collections/__init__.py", line 322, in namedtuple field_names = list(map(str, field_names)) KeyboardInterrupt ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 18:11:24 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 20 Apr 2012 16:11:24 +0000 Subject: [issue14517] Recompilation of sources with Distutils In-Reply-To: <1333711497.18.0.995661570344.issue14517@psf.upfronthosting.co.za> Message-ID: <1334938284.24.0.485363846487.issue14517@psf.upfronthosting.co.za> ?ric Araujo added the comment: I think this is done on purpose; I?ll dig up the changeset and bug report later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 18:19:30 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 20 Apr 2012 16:19:30 +0000 Subject: [issue14629] discrepency between tokenize.detect_encoding() and PyTokenizer_FindEncodingFilename() In-Reply-To: <1334899038.03.0.61083358932.issue14629@psf.upfronthosting.co.za> Message-ID: <1334938770.56.0.847743438572.issue14629@psf.upfronthosting.co.za> Martin v. L?wis added the comment: IMO, the test is flawed testing for the specific error message. OTOH, the original message is better than the tokenize message in that it mentions the file name. However, tokenize does not have the file name available, so it can't possibly report it. I have no idea how to resolve this. Contributions are welcome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 18:53:21 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Apr 2012 16:53:21 +0000 Subject: [issue14581] Support case-insensitive file extensions on Windows in importlib In-Reply-To: <1334434221.26.0.706558952592.issue14581@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset a32be109bd86 by Brett Cannon in branch 'default': Issue #14581: Windows users are allowed to import modules w/o taking http://hg.python.org/cpython/rev/a32be109bd86 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:00:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Apr 2012 17:00:20 +0000 Subject: [issue14629] discrepency between tokenize.detect_encoding() and PyTokenizer_FindEncodingFilename() In-Reply-To: <1334899038.03.0.61083358932.issue14629@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset a281a6622714 by Brett Cannon in branch 'default': Issue #14633: Simplify imp.find_modue() test after fixes from issue http://hg.python.org/cpython/rev/a281a6622714 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:04:09 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 20 Apr 2012 17:04:09 +0000 Subject: [issue14633] test_find_module_encoding should test for a less specific message In-Reply-To: <1334935139.39.0.293792224706.issue14633@psf.upfronthosting.co.za> Message-ID: <1334941449.35.0.977490458163.issue14633@psf.upfronthosting.co.za> Brett Cannon added the comment: Committed in http://hg.python.org/cpython/rev/a281a6622714 (I think our issue detection algorithm grabs the last issue in a commit message instead of the first one). ---------- assignee: -> brett.cannon resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:17:10 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 20 Apr 2012 17:17:10 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1334942230.83.0.512126190498.issue10142@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Is there a reason to say (several times) 'can support' instead of just 'support'? Do the OSes in question just optionally support rather than always support? The first version added: change 'depend of' to 'depend on'. In several functions you delete error checks: - if not (0 <= whence <= 2): - raise ValueError("invalid whence value") (or C equivalent). What happens with patch if invalid whence value is passed? Error from deeper in the call stack? Silently pass error, with no message? Could import of io create set of valid_whences for system? Then check would be "if whence not in valid_whences:" (or C equivalent). In 3.3, unittest has new mock submodule. Perhaps that would help testing. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:22:20 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 20 Apr 2012 17:22:20 +0000 Subject: [issue8885] markupbase declaration errors aren't recoverable In-Reply-To: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za> Message-ID: <1334942540.0.0.353258111899.issue8885@psf.upfronthosting.co.za> Ezio Melotti added the comment: Because even on 2.7 the parser is now able to handle broken markup, so "error" won't be called anymore. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:23:55 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 17:23:55 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334942635.64.0.152665859045.issue14630@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's the patch. I searched through the rest of Objects/longobject.c for other occurrences of [0], and found nothing else that looked suspicious, so I'm reasonably confident that this was an isolated case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:24:06 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 17:24:06 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334942646.6.0.454157306203.issue14630@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- keywords: +patch Added file: http://bugs.python.org/file25291/issue14630.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:24:35 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Apr 2012 17:24:35 +0000 Subject: [issue14629] discrepency between tokenize.detect_encoding() and PyTokenizer_FindEncodingFilename() In-Reply-To: <1334899038.03.0.61083358932.issue14629@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 1b57de8a8383 by Brett Cannon in branch 'default': Issue #14629: Mention the filename in SyntaxError exceptions from http://hg.python.org/cpython/rev/1b57de8a8383 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:30:43 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 20 Apr 2012 17:30:43 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1334943043.18.0.207650127403.issue10142@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Terry, yes, skiping the test in the code will raise an error anyway when doing the real "seek()" OS syscall. > Is there a reason to say (several times) 'can support' instead of > just 'support'? Do the OSes in question just optionally support > rather than always support? Sometimes depends of the concrete filesystem used, or the concrete OS version. > The first version added: change 'depend of' to 'depend on'. Done in my repository. Thanks. > Could import of io create set of valid_whences for system? > Then check would be "if whence not in valid_whences:" (or C > equivalent). This is far from trivial and I don't see the point if OS "seek()" is going to give an error anyway. The only point would to provide a maybe more useful error message. > In 3.3, unittest has new mock submodule. Perhaps that would help > testing. This is a very thin layer over the OS. Thanks for the feedback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:32:31 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 20 Apr 2012 17:32:31 +0000 Subject: [issue14633] test_find_module_encoding should test for a less specific message In-Reply-To: <1334935139.39.0.293792224706.issue14633@psf.upfronthosting.co.za> Message-ID: <1334943151.04.0.563990551785.issue14633@psf.upfronthosting.co.za> Eric Snow added the comment: thanks, Brett! That did the trick. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:35:21 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 20 Apr 2012 17:35:21 +0000 Subject: [issue14629] discrepency between tokenize.detect_encoding() and PyTokenizer_FindEncodingFilename() In-Reply-To: <1334899038.03.0.61083358932.issue14629@psf.upfronthosting.co.za> Message-ID: <1334943321.12.0.866974234248.issue14629@psf.upfronthosting.co.za> Eric Snow added the comment: Looks good. Thanks for the help, Martin and Brett. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:40:58 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 20 Apr 2012 17:40:58 +0000 Subject: [issue14581] Support case-insensitive file extensions on Windows in importlib In-Reply-To: <1334434221.26.0.706558952592.issue14581@psf.upfronthosting.co.za> Message-ID: <1334943658.96.0.0884945323781.issue14581@psf.upfronthosting.co.za> Brett Cannon added the comment: http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/98/steps/test/logs/stdio suggests this fix worked. ---------- assignee: -> brett.cannon resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:44:07 2012 From: report at bugs.python.org (Vlado Boza) Date: Fri, 20 Apr 2012 17:44:07 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1334943847.01.0.765567078717.issue14621@psf.upfronthosting.co.za> Vlado Boza added the comment: One possible fix: Look for StringHasher in google v8 code (http://code.google.com/p/v8/source/search?q=stringhasher&origq=stringhasher&btnG=Search+Trunk). Main loop looks like this: raw_running_hash_ += c; raw_running_hash_ += (raw_running_hash_ << 10); raw_running_hash_ ^= (raw_running_hash_ >> 6); It seems not to have same collisions with many different hash seeds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:45:13 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 20 Apr 2012 17:45:13 +0000 Subject: [issue14599] Windows test_import failure thanks to ImportError.path In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: <1334943913.41.0.546672724216.issue14599@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- title: Windows test_import failure -> Windows test_import failure thanks to ImportError.path _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:51:22 2012 From: report at bugs.python.org (Colin Marc) Date: Fri, 20 Apr 2012 17:51:22 +0000 Subject: [issue13344] closed sockets don't raise EBADF anymore In-Reply-To: <1320441286.92.0.465148592312.issue13344@psf.upfronthosting.co.za> Message-ID: <1334944282.67.0.6354681917.issue13344@psf.upfronthosting.co.za> Changes by Colin Marc : ---------- nosy: +colinmarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:52:09 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 17:52:09 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334944329.1.0.297492200093.issue14630@psf.upfronthosting.co.za> Mark Dickinson added the comment: Also, Python 2.7 looks safe here. ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:52:15 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 17:52:15 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334944335.32.0.899478445623.issue14630@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:53:51 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 17:53:51 +0000 Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za> Message-ID: <1334944431.53.0.739302868562.issue7511@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: -mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:56:27 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 17:56:27 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1334944587.74.0.953878168402.issue14596@psf.upfronthosting.co.za> Mark Dickinson added the comment: IMO, the struct module does what it's intended to do just fine here. I don't a big need for any change. I'd propose closing this as "won't fix". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:57:52 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 20 Apr 2012 17:57:52 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334944672.1.0.119830960125.issue14630@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patch works fine here, and the test exercises the issue correctly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 19:58:50 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 17:58:50 +0000 Subject: [issue10156] Initialization of globals in unicodeobject.c In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za> Message-ID: <1334944730.21.0.512215032961.issue10156@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: -mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 20:08:04 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 20 Apr 2012 18:08:04 +0000 Subject: [issue14634] Mock cannot autospec functions with keyword-only arguments. Message-ID: <1334945284.24.0.289841146723.issue14634@psf.upfronthosting.co.za> New submission from R. David Murray : The following code: def foo(a, *, b=None): pass unittest.mock.create_autospec(foo) fails with this traceback: Traceback (most recent call last): File "temp.py", line 6, in unittest.mock.create_autospec(foo) File "/home/rdmurray/python/p33/Lib/unittest/mock.py", line 2026, in create_autospec mock = _set_signature(mock, spec) File "/home/rdmurray/python/p33/Lib/unittest/mock.py", line 162, in _set_signature result = _getsignature(original, skipfirst, instance) File "/home/rdmurray/python/p33/Lib/unittest/mock.py", line 81, in _getsignature regargs, varargs, varkwargs, defaults = inspect.getargspec(func) File "/home/rdmurray/python/p33/Lib/inspect.py", line 808, in getargspec raise ValueError("Function has keyword-only arguments or annotations" ValueError: Function has keyword-only arguments or annotations, use getfullargspec() API which can support them ---------- keywords: easy messages: 158864 nosy: michael.foord, r.david.murray priority: normal severity: normal status: open title: Mock cannot autospec functions with keyword-only arguments. type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 20:09:32 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 20 Apr 2012 18:09:32 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1334945372.71.0.198026631395.issue13405@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Stan, anybody working in SystemTap support, could you possibly create a new issue in the tracker to track specifically stap support?. You can depend on this bug, and coordinate effort. Clone my repository and use it as base. Thanks!. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 20:10:38 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 20 Apr 2012 18:10:38 +0000 Subject: [issue14634] Mock cannot autospec functions with keyword-only arguments. In-Reply-To: <1334945284.24.0.289841146723.issue14634@psf.upfronthosting.co.za> Message-ID: <1334945438.59.0.622899639054.issue14634@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Library (Lib) nosy: +ezio.melotti stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 20:10:46 2012 From: report at bugs.python.org (Daniel Urban) Date: Fri, 20 Apr 2012 18:10:46 +0000 Subject: [issue14588] PEP 3115 compliant dynamic class creation In-Reply-To: <1334535798.87.0.826104374353.issue14588@psf.upfronthosting.co.za> Message-ID: <1334945446.24.0.248111181961.issue14588@psf.upfronthosting.co.za> Daniel Urban added the comment: I've attached the third patch with the eval_body -> exec_body change; explicitly passing the default (None) now also allowed. I also fixed a refleak (I think). ---------- Added file: http://bugs.python.org/file25292/operator_build_class_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 20:21:41 2012 From: report at bugs.python.org (Frank Ch. Eigler) Date: Fri, 20 Apr 2012 18:21:41 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1334945372.71.0.198026631395.issue13405@psf.upfronthosting.co.za> Message-ID: <20120420182137.GM18217@elastic.org> Frank Ch. Eigler added the comment: > Stan, anybody working in SystemTap support, could you possibly > create a new issue in the tracker to track specifically stap > support?. You can depend on this bug, and coordinate effort. Clone > my repository and use it as base. I believe the only remotely-systemtap-specific stuff we suggested would be useful would be the addition of that PyEval_GetFrame() value as an extra argument for function entry/exit sdt.h calls. I believe your patch already apprx. works against systemtap (and in fact many dtrace idiosyncracies like asm("nop") are unnecessary here), except for the inclusion of the /usr/bin/dtrace -G-generated header file, as mentioned in . Do you think it is necessary to track that in a separate bug? - FChE ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 20:28:12 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 20 Apr 2012 18:28:12 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1334946492.82.0.010475558209.issue13405@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Frank, if somebody provides a "diff" I can test under Ubuntu 10.04, I can try it myself. This patch MUST be differential from my current patch (to be applied OVER it) and must cover EVERYTHING, from "./configure" to the test execution. Anyway, "issues" in the tracker are free, and I rather prefer to have a separate issue, actually. You can copy the nosy list. The "nop" issue seems to be related to SPARC branch slot. I don't have SPARC hardware to try, anymore :-(. Trying with "friends", but it is moving slowly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 20:36:49 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Apr 2012 18:36:49 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1334947009.44.0.759269483902.issue14579@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file25293/utf16_error_handling-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 20:39:06 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Apr 2012 18:39:06 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1334947146.71.0.0153634824166.issue14579@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a minimal patch that corrects all bugs for 3.2. As a side effect, decoding is accelerated by 4-8%. ---------- Added file: http://bugs.python.org/file25294/utf16_error_handling-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 20:39:50 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 20 Apr 2012 18:39:50 +0000 Subject: [issue14606] Memory leak subprocess on Windows In-Reply-To: <1334689181.81.0.435135933783.issue14606@psf.upfronthosting.co.za> Message-ID: <1334947190.68.0.90970527619.issue14606@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Does your last message mean that this issue should be closed here? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 20:40:30 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Apr 2012 18:40:30 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1334947230.66.0.957230631712.issue14579@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file25293/utf16_error_handling-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 20:41:07 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 20 Apr 2012 18:41:07 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1334947267.15.0.587513072244.issue14579@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file25295/utf16_update_after_error-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 20:46:19 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 18:46:19 +0000 Subject: [issue14620] Fatal Python error: Cannot recover from stack overflow. In-Reply-To: <1334825499.76.0.44489005416.issue14620@psf.upfronthosting.co.za> Message-ID: <1334947579.32.0.386173162336.issue14620@psf.upfronthosting.co.za> Mark Dickinson added the comment: If you have a self-contained script that exhibits the problem, please could you attach it directly to the issue? ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 20:47:11 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 18:47:11 +0000 Subject: [issue14620] Fatal Python error: Cannot recover from stack overflow. In-Reply-To: <1334825499.76.0.44489005416.issue14620@psf.upfronthosting.co.za> Message-ID: <1334947631.77.0.12703846869.issue14620@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 20:50:36 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 20 Apr 2012 18:50:36 +0000 Subject: [issue14620] Fatal Python error: Cannot recover from stack overflow. In-Reply-To: <1334825499.76.0.44489005416.issue14620@psf.upfronthosting.co.za> Message-ID: <1334947836.58.0.528466941252.issue14620@psf.upfronthosting.co.za> Terry J. Reedy added the comment: There are several other 'stack overflow' issues (just do a search on that phrase). Please take a look and see if yours is a duplicate of any of the others. If this does seem different, please reduce your code to the minimum needed and attach the file here. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 21:14:39 2012 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 20 Apr 2012 19:14:39 +0000 Subject: [issue14627] Fatal Python Error when Python startup is interrupted by CTRL+c In-Reply-To: <1334880082.24.0.373368528623.issue14627@psf.upfronthosting.co.za> Message-ID: <1334949279.0.0.127754577961.issue14627@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In a running interpreter and Idle, ^C results in KeyboardInterrupt >>> and nothing else. >From a command line, I think KeyboardInterrupt: Python startup stopped" would be ideal. On Windows, I do not know if a program started from an icon, shortcut, or explorer *can* be interrupted, except possibly with Task Manager if the entry shows up fast enough, as it should not get keyboard focus until started. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 21:20:23 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 20 Apr 2012 19:20:23 +0000 Subject: [issue14635] telnetlib uses select instead of poll - limited to FD_SETSIZE fds Message-ID: <1334949623.77.0.295518189269.issue14635@psf.upfronthosting.co.za> New submission from Gregory P. Smith : telnetlib uses select.select. This limits it to being able to work when file descriptors are still below FD_SETSIZE (often 1024) meaning it can't be used in some large programs today. It should use poll. (it is probably easy to fix this and the telnetlib EINTR issue1049450 at the same time) ---------- assignee: jackdied components: Library (Lib) messages: 158874 nosy: gregory.p.smith, jackdied priority: normal severity: normal status: open title: telnetlib uses select instead of poll - limited to FD_SETSIZE fds type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 21:23:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Apr 2012 19:23:18 +0000 Subject: [issue14599] Windows test_import failure thanks to ImportError.path In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 573010778eed by Brett Cannon in branch 'default': Issue #14599: Generalize a test for ImportError.path and add support http://hg.python.org/cpython/rev/573010778eed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 21:31:19 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Apr 2012 19:31:19 +0000 Subject: [issue14599] Windows test_import failure thanks to ImportError.path In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 56aa4cda11a8 by Brett Cannon in branch 'default': Issue #14599: Support ImportError.path on AIX and HPUX when loading http://hg.python.org/cpython/rev/56aa4cda11a8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 21:49:52 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 20 Apr 2012 19:49:52 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334944335.34.0.303661096515.issue14630@psf.upfronthosting.co.za> Message-ID: <20120420194951.GA19717@sleipnir.bytereef.org> Stefan Krah added the comment: The patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 21:52:23 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Apr 2012 19:52:23 +0000 Subject: [issue14585] Have test_import run more importlib tests In-Reply-To: <1334453245.9.0.0799360762368.issue14585@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset a74ba7407457 by Brett Cannon in branch 'default': Issue #14585: test_import now runs all tests under http://hg.python.org/cpython/rev/a74ba7407457 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 21:52:43 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 20 Apr 2012 19:52:43 +0000 Subject: [issue14585] Have test_import run more importlib tests In-Reply-To: <1334453245.9.0.0799360762368.issue14585@psf.upfronthosting.co.za> Message-ID: <1334951563.89.0.463895859999.issue14585@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 21:54:12 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 20 Apr 2012 19:54:12 +0000 Subject: [issue14599] Windows test_import failure thanks to ImportError.path In-Reply-To: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za> Message-ID: <1334951652.9.0.639201663583.issue14599@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 21:58:06 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Apr 2012 19:58:06 +0000 Subject: [issue14628] Clarify import statement documentation regarding what gets bound In-Reply-To: <1334896267.8.0.0783452284973.issue14628@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 150bd84e737e by Brett Cannon in branch 'default': Issue #14628: Document the fact that import always returns the module http://hg.python.org/cpython/rev/150bd84e737e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 21:58:32 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 20 Apr 2012 19:58:32 +0000 Subject: [issue14628] Clarify import statement documentation regarding what gets bound In-Reply-To: <1334896267.8.0.0783452284973.issue14628@psf.upfronthosting.co.za> Message-ID: <1334951912.2.0.886781149257.issue14628@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: docs at python -> brett.cannon resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 22:04:51 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 20 Apr 2012 20:04:51 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1334952291.21.0.317727887895.issue10142@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > I don't see the point if OS "seek()" is going to give an error anyway. Please check that Windows won't crash the interpreter with bad 'whence' values, like it already does for closed file descriptors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 22:21:47 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Apr 2012 20:21:47 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1331932171.45.0.56771909125.issue14339@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset dcd3344b6d5b by Mark Dickinson in branch 'default': Issue #14339: Improve speed of bin, oct and hex builtins. Patch by Serhiy Storchaka (with minor modifications). http://hg.python.org/cpython/rev/dcd3344b6d5b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 22:23:28 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 20:23:28 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1331932171.45.0.56771909125.issue14339@psf.upfronthosting.co.za> Message-ID: <1334953408.11.0.581209054952.issue14339@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks for the patch. I made some minor changes, notably moving the overflow check closer to where it's needed, moving some comments around, and removing a (possibly inappropriate) PyErr_NoMemory call. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 22:38:09 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 20 Apr 2012 20:38:09 +0000 Subject: [issue14636] Mock could check for exceptions in side effect list Message-ID: <1334954289.59.0.991318648825.issue14636@psf.upfronthosting.co.za> New submission from R. David Murray : I just spent an hour figuring out why my test was failing because I tried to do this: mymock.side_effect = (AuthenticationError, None) expecting the first call to raise an auth error and the second time it was called to get a normal return. Since there are almost zero circumstances in which one would really want to return an exception, is there any reason not to have mock check for exceptions and raise them in this circumstance? (If one did need to return an exception one could write a function...which is what one has to do now for the above case, but the above case seems more commonly needed than returning an exception would be.) ---------- components: Library (Lib) keywords: easy messages: 158883 nosy: michael.foord, r.david.murray priority: normal severity: normal stage: needs patch status: open title: Mock could check for exceptions in side effect list type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 22:41:09 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 20 Apr 2012 20:41:09 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1331932171.45.0.56771909125.issue14339@psf.upfronthosting.co.za> Message-ID: <1334954469.29.0.182446723784.issue14339@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This should have waited until Serhiy submits a contributor form. Serhiy, can you please do this soon? Else I'll have to revert the change. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 22:41:31 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 20 Apr 2012 20:41:31 +0000 Subject: [issue14637] test.test_import.PathsTests.test_UNC_path is failing Message-ID: <1334954491.9.0.0351086786979.issue14637@psf.upfronthosting.co.za> New submission from Brett Cannon : See http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/104/steps/test/logs/stdio for the failure, but basically: ====================================================================== ERROR: test_UNC_path (test.test_import.PathsTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_import.py", line 469, in _test_UNC_path mod = __import__("test_trailing_slash") File "", line 1003, in _find_and_load ImportError: No module named 'test_trailing_slash' ---------------------------------------------------------------------- It seems spontaneous as the test succeeded previously and the commit it failed on didn't even touch code compiled by Windows. ---------- components: Windows keywords: buildbot messages: 158885 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: test.test_import.PathsTests.test_UNC_path is failing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 22:44:32 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Apr 2012 20:44:32 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset cdcc6b489862 by Mark Dickinson in branch '3.2': Issue #14630: Fix an incorrect access of ob_digit[0] for a zero instance of an int subclass. http://hg.python.org/cpython/rev/cdcc6b489862 New changeset c7b0f711dc15 by Mark Dickinson in branch 'default': Issue #14630: Merge fix from 3.2. http://hg.python.org/cpython/rev/c7b0f711dc15 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 22:45:23 2012 From: report at bugs.python.org (Florent Xicluna) Date: Fri, 20 Apr 2012 20:45:23 +0000 Subject: [issue14638] pydoc error on instance of a custom class Message-ID: <1334954723.85.0.214601064543.issue14638@psf.upfronthosting.co.za> New submission from Florent Xicluna : pydoc fails on custom instances in specific cases. (When instance __name__ does not resolve to a str). This is a small example: >>> import pydoc >>> class A: ... def __getattr__(self, name): ... return True ... >>> print(pydoc.render_doc(A)) Python Library Documentation: class A in module __main__ (...) >>> print(pydoc.render_doc(A())) Traceback (most recent call last): File "", line 1, in File "./Lib/pydoc.py", line 1534, in render_doc if name and '.' in name: TypeError: argument of type 'bool' is not iterable ---------- components: Library (Lib) messages: 158887 nosy: flox priority: normal severity: normal status: open title: pydoc error on instance of a custom class type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 22:45:29 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 20:45:29 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334954729.48.0.145498737808.issue14630@psf.upfronthosting.co.za> Mark Dickinson added the comment: Fixed. Thanks Brecht for the report (and Antoine for diagnosing the problem). ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 22:47:53 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 20 Apr 2012 20:47:53 +0000 Subject: [issue14635] telnetlib uses select instead of poll - limited to FD_SETSIZE fds In-Reply-To: <1334949623.77.0.295518189269.issue14635@psf.upfronthosting.co.za> Message-ID: <1334954873.79.0.52148812766.issue14635@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: See also issue #10527, dealing with multiprocessing. Note that this probably affects other modules besides telnetlib, so it might be interesting to find a way to factorize code (i.e. use poll() if available or fallback to select()). ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 22:49:55 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 20:49:55 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1331932171.45.0.56771909125.issue14339@psf.upfronthosting.co.za> Message-ID: <1334954995.59.0.609416990247.issue14339@psf.upfronthosting.co.za> Mark Dickinson added the comment: Aargh. Sorry, yes. Serhiy, can you do this? The form can be found at: http://www.python.org/psf/contrib/contrib-form-python/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 22:52:55 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 20:52:55 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1331932171.45.0.56771909125.issue14339@psf.upfronthosting.co.za> Message-ID: <1334955175.59.0.972224168245.issue14339@psf.upfronthosting.co.za> Mark Dickinson added the comment: Whoops; that looks like a slightly older version of the form. I think the correct one is: http://www.python.org/psf/contrib/contrib-form/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 23:02:16 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 21:02:16 +0000 Subject: [issue14630] non-deterministic behavior of int subclass In-Reply-To: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za> Message-ID: <1334955736.48.0.52862155275.issue14630@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 23:14:16 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 20 Apr 2012 21:14:16 +0000 Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format In-Reply-To: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za> Message-ID: <1334956456.86.0.749646522405.issue13072@psf.upfronthosting.co.za> Stefan Krah added the comment: I'm not sure what to do. Martin's opinion was that the change should be reverted: http://mail.python.org/pipermail/python-dev/2012-March/117390.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 23:24:47 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 20 Apr 2012 21:24:47 +0000 Subject: [issue14323] Normalize math precision in RGB/YIQ conversion In-Reply-To: <1331831977.5.0.174772346075.issue14323@psf.upfronthosting.co.za> Message-ID: <1334957087.02.0.695087080429.issue14323@psf.upfronthosting.co.za> Mark Dickinson added the comment: Terry: sorry, I missed this before. Re 1. Sure, this seems reasonable, if there's a real sense in which the new numbers are better than the old. Besides MATLAB, there's also a set of numbers given on Wikipedia that might be considered. I don't have the domain knowledge to know what's sensible here. I *would* rather see the inverse transformation keep the full 6 digits of precision, though. Or perhaps even give the inverse to full float precision. Without that, the result of roundtripping RGB -> YIQ -> RGB could be significantly (perhaps even visibly) different from the original. I don't think it's acceptable for the roundtrip error to increase significantly w.r.t. Python 3.2. Re 2. For this issue, I don't see a real benefit to adding the tests to the maintenance releases. No strong opinions, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 23:38:12 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 20 Apr 2012 21:38:12 +0000 Subject: [issue14625] Faster utf-32 decoder In-Reply-To: <1334869197.32.0.159275934867.issue14625@psf.upfronthosting.co.za> Message-ID: <1334957892.68.0.902907151713.issue14625@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 23:38:25 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 20 Apr 2012 21:38:25 +0000 Subject: [issue14624] Faster utf-16 decoder In-Reply-To: <1334869141.17.0.802149162715.issue14624@psf.upfronthosting.co.za> Message-ID: <1334957905.1.0.816143088734.issue14624@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 23:38:37 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 20 Apr 2012 21:38:37 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1334957917.98.0.974170387218.issue14579@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 23:55:57 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 20 Apr 2012 21:55:57 +0000 Subject: [issue14636] Mock could check for exceptions in side effect list In-Reply-To: <1334954289.59.0.991318648825.issue14636@psf.upfronthosting.co.za> Message-ID: <1334958957.11.0.466759721348.issue14636@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 23:56:31 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 20 Apr 2012 21:56:31 +0000 Subject: [issue14638] pydoc error on instance of a custom class In-Reply-To: <1334954723.85.0.214601064543.issue14638@psf.upfronthosting.co.za> Message-ID: <1334958991.85.0.659819084672.issue14638@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 20 23:57:55 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 20 Apr 2012 21:57:55 +0000 Subject: [issue14635] telnetlib uses select instead of poll - limited to FD_SETSIZE fds In-Reply-To: <1334949623.77.0.295518189269.issue14635@psf.upfronthosting.co.za> Message-ID: <1334959075.11.0.147304042365.issue14635@psf.upfronthosting.co.za> ?ric Araujo added the comment: Out of curiosity, are you reporting this because you ran into it in your code? I was not aware that telnet was still in real use. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 00:04:19 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 20 Apr 2012 22:04:19 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset c820aa9c0c00 by Brett Cannon in branch 'default': Issue #13959: Keep imp.get_magic() in C code, but cache in importlib http://hg.python.org/cpython/rev/c820aa9c0c00 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 00:38:09 2012 From: report at bugs.python.org (Michael Foord) Date: Fri, 20 Apr 2012 22:38:09 +0000 Subject: [issue14636] Mock could check for exceptions in side effect list In-Reply-To: <1334954289.59.0.991318648825.issue14636@psf.upfronthosting.co.za> Message-ID: <1334961489.05.0.520750168017.issue14636@psf.upfronthosting.co.za> Michael Foord added the comment: Seems like a good change. ---------- assignee: -> michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 01:13:47 2012 From: report at bugs.python.org (Diego Manenti Martins) Date: Fri, 20 Apr 2012 23:13:47 +0000 Subject: [issue14639] Different behavior for urllib2 in Python 2.7 Message-ID: <1334963627.5.0.25860672306.issue14639@psf.upfronthosting.co.za> New submission from Diego Manenti Martins : this code sends data in a different way if using python 2.6 or python 2.7 >>> import urllib2 >>> url = 'http://server.com/post_image?tid=zoV6LJ' >>> f = open('test.jpg') >>> data = f.read() >>> res = urllib2.urlopen(url, data) I checked it with wireshark and the data is sent in a different way when using python 2.7 The code works for python2.5 and python2.6 ---------- components: Library (Lib) messages: 158897 nosy: Diego.Manenti.Martins priority: normal severity: normal status: open title: Different behavior for urllib2 in Python 2.7 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 01:41:31 2012 From: report at bugs.python.org (Rick Rune) Date: Fri, 20 Apr 2012 23:41:31 +0000 Subject: [issue14470] Remove using of w9xopen in subprocess module In-Reply-To: <1333303587.03.0.401233973218.issue14470@psf.upfronthosting.co.za> Message-ID: <1334965291.24.0.561632359184.issue14470@psf.upfronthosting.co.za> Rick Rune added the comment: Removed w9xpopen usage in subprocess module via attached patch. ---------- keywords: +patch nosy: +Rune Added file: http://bugs.python.org/file25296/subprocess_minus_w9xpopen.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 01:43:30 2012 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 20 Apr 2012 23:43:30 +0000 Subject: [issue14639] Different behavior for urllib2 in Python 2.7 In-Reply-To: <1334963627.5.0.25860672306.issue14639@psf.upfronthosting.co.za> Message-ID: <1334965410.25.0.248790806347.issue14639@psf.upfronthosting.co.za> Eric V. Smith added the comment: In what way is it different? Does it cause a problem, or is it compatible but different? ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 02:42:10 2012 From: report at bugs.python.org (Hugh Gibbons) Date: Sat, 21 Apr 2012 00:42:10 +0000 Subject: [issue14575] IDLE crashes after file open in OS X In-Reply-To: <1334708792.12.0.49360889545.issue14575@psf.upfronthosting.co.za> Message-ID: Hugh Gibbons added the comment: thanks. That eliminated the crashiness. On Apr 17, 2012, at 6:26 PM, Ned Deily wrote: > > Ned Deily added the comment: > > The crash dump confirms that the buggy Apple Tcl/Tk 8.5 frameworks are being used (/System/Library/Frameworks/Tk.framework/Versions/8.5/Tk). As I mentioned, the easiest solution is to install the most recent ActiveState Tcl/Tk 8.5. The python.org Python 2.7.3 will automatically use it if it is available at run time. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 02:55:39 2012 From: report at bugs.python.org (Joe Peterson) Date: Sat, 21 Apr 2012 00:55:39 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1334969739.97.0.776811416238.issue10941@psf.upfronthosting.co.za> Joe Peterson added the comment: I have now included a patch for 2.7. Here are the two latest patches: Python 2: issue10941_python2.diff Python 3: issue10941_python3.diff ---------- Added file: http://bugs.python.org/file25297/issue10941_python2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 02:56:58 2012 From: report at bugs.python.org (Diego Manenti Martins) Date: Sat, 21 Apr 2012 00:56:58 +0000 Subject: [issue14639] Different behavior for urllib2 in Python 2.7 In-Reply-To: <1334963627.5.0.25860672306.issue14639@psf.upfronthosting.co.za> Message-ID: <1334969818.92.0.80996704087.issue14639@psf.upfronthosting.co.za> Diego Manenti Martins added the comment: It stoped to work. It was working when using with python 2.6 and crashed on switching to python 2.7 I expect the same behavior of curl -X POST http://server.com/post_image?tid=zoV6LJ -T test.jpg ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 03:07:17 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 21 Apr 2012 01:07:17 +0000 Subject: [issue14584] Add gzip support to xmlrpc.server In-Reply-To: <1334436496.76.0.995633405639.issue14584@psf.upfronthosting.co.za> Message-ID: <1334970437.08.0.297828817899.issue14584@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- components: +Library (Lib) nosy: +eric.araujo stage: -> needs patch title: Add gzip support the XMLRPC Server -> Add gzip support to xmlrpc.server _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 03:42:30 2012 From: report at bugs.python.org (Dave Abrahams) Date: Sat, 21 Apr 2012 01:42:30 +0000 Subject: [issue9458] xml.etree.ElementTree.ElementTree.write(): encoding handling problems In-Reply-To: <1280782925.67.0.136452249646.issue9458@psf.upfronthosting.co.za> Message-ID: <1334972550.46.0.767284409674.issue9458@psf.upfronthosting.co.za> Dave Abrahams added the comment: These bugs are annoying. How does one convert a set of examples into a patch? Do you mean you want these to become test cases? ---------- nosy: +dabrahams _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 03:42:30 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 21 Apr 2012 01:42:30 +0000 Subject: [issue14613] time.time can return NaN In-Reply-To: <1334751988.35.0.313625977941.issue14613@psf.upfronthosting.co.za> Message-ID: <1334972550.83.0.84347981423.issue14613@psf.upfronthosting.co.za> ?ric Araujo added the comment: See http://patch-tracker.debian.org/package/python2.7 for the list of patches applied to Python 2.7 in Debian. I don?t know if there are more patches in Ubuntu. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 03:46:05 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 21 Apr 2012 01:46:05 +0000 Subject: [issue9458] xml.etree.ElementTree.ElementTree.write(): encoding handling problems In-Reply-To: <1280782925.67.0.136452249646.issue9458@psf.upfronthosting.co.za> Message-ID: <1334972765.5.0.59673652634.issue9458@psf.upfronthosting.co.za> ?ric Araujo added the comment: Yes. See the devguide if you need more info. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 03:49:13 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 21 Apr 2012 01:49:13 +0000 Subject: [issue14573] json iterencode can not handle general iterators In-Reply-To: <1334355033.57.0.314676653112.issue14573@psf.upfronthosting.co.za> Message-ID: <1334972953.99.0.868512280764.issue14573@psf.upfronthosting.co.za> ?ric Araujo added the comment: Agreed with Antoine; I think that if this is added, it should be opt-in, not default. Also, it is not clear if the request is about iterators or iterables. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 04:05:24 2012 From: report at bugs.python.org (Dave Abrahams) Date: Sat, 21 Apr 2012 02:05:24 +0000 Subject: [issue1572710] cElementTree.SubElement doesn't recognize keyword "attrib" Message-ID: <1334973924.15.0.33877044084.issue1572710@psf.upfronthosting.co.za> Dave Abrahams added the comment: @effbot, I think you may have misread the OP's example. The first two arguments /are/ being passed positionally. In any case, there's a real bug here. cElementTree seems to choke on uses of attrib. Change cElementTree to ElementTree below and this one works, too. >>> from xml.etree.cElementTree import Element, tostring >>> print tostring(Element('foo', attrib={})) Traceback (most recent call last): File "bug.py", line 2, in print tostring(Element('foo', attrib={})) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 1127, in tostring ElementTree(element).write(file, encoding, method=method) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 821, in write serialize(write, self._root, encoding, qnames, namespaces) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 933, in _serialize_xml v = _escape_attrib(v, encoding) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 1093, in _escape_attrib _raise_serialization_error(text) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 1053, in _raise_serialization_error "cannot serialize %r (type %s)" % (text, type(text).__name__) TypeError: cannot serialize {} (type dict) ---------- nosy: +dabrahams _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 04:07:06 2012 From: report at bugs.python.org (Eric Snow) Date: Sat, 21 Apr 2012 02:07:06 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1334974026.01.0.249902126402.issue13959@psf.upfronthosting.co.za> Eric Snow added the comment: I'd still like to consider this a bit more. When you're trying to understand imports, having one place to look (Lib/importlib/_bootstrap.py) is better than two, especially when the one is pure Python code. So it still may be worth it to pull in the odds and ends that play into that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 04:10:18 2012 From: report at bugs.python.org (Dave Abrahams) Date: Sat, 21 Apr 2012 02:10:18 +0000 Subject: [issue1572710] cElementTree.SubElement doesn't recognize keyword "attrib" Message-ID: <1334974218.23.0.0938857667245.issue1572710@psf.upfronthosting.co.za> Dave Abrahams added the comment: On second thought, I see what effbot is trying to say... but it's still a bug. Given the way the interface is declared and the behavior of regular python functions: Element(tag, attrib={}, **extra) indicates that I can pass attrib (or tag, for that matter) as a keyword argument. Nothing in the documentation gives the C implementation permission to behave differently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 06:50:27 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 21 Apr 2012 04:50:27 +0000 Subject: [issue14604] spurious stat() calls in importlib In-Reply-To: <1334663931.89.0.459058246046.issue14604@psf.upfronthosting.co.za> Message-ID: <1334983827.93.0.815921383666.issue14604@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, so a cursory look at importlib suggests that the possible costs of those stat calls (by looking at what has to examine the filesystem) are: * os.listdir() for caching * os.path.isdir() for directories if they are a package * os.path.isfile() for __init__.py * os.path.isfile() for a module (and all the possible extensions) * os.stat() for details of bytecode * reading any bytecode * reading the source * writing the bytecode So looking at that initial block of stat calls, I am willing to bet that Lib is getting the stat call by the os.path.isdir() check in the finder, the 2 Lib/_sysconfigdata.py checks are from the finder checking the file exists and then stat'ing in the loader for bytecode verification, and then finally the opening of the bytecode to read it and discover it's usable. As for the multiple stat calls on directories, that's validating the cache isn't out-of-date which I don't see how that can be avoided short of hitting the system clock to see if some amount of time has passed. As for the multiple stat calls between the finder and the loader, I don't see any way to cut that down without coming up with a find + load API which makes the call immediately or some way to pass in stat details, else you have race conditions on the status of the file before you check if the bytecode is stale. If the stat calls on the directories for cache validation is too frequent, then issue #14067 is probably your best bet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 07:20:17 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 21 Apr 2012 05:20:17 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1334985617.22.0.650372760328.issue7559@psf.upfronthosting.co.za> Chris Jerdonek added the comment: I'm still getting hit with this. In what versions is it okay for us to fix the bad API, as Michael suggested? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 10:04:31 2012 From: report at bugs.python.org (Peter Otten) Date: Sat, 21 Apr 2012 08:04:31 +0000 Subject: [issue14638] pydoc error on instance of a custom class In-Reply-To: <1334954723.85.0.214601064543.issue14638@psf.upfronthosting.co.za> Message-ID: <1334995471.49.0.28455304202.issue14638@psf.upfronthosting.co.za> Peter Otten <__peter__ at web.de> added the comment: Patch upload, second attempt. ---------- keywords: +patch nosy: +peter.otten Added file: http://bugs.python.org/file25298/render_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 11:52:55 2012 From: report at bugs.python.org (Dionysios Kalofonos) Date: Sat, 21 Apr 2012 09:52:55 +0000 Subject: [issue14640] Typos in pyporting.rst Message-ID: <1335001975.37.0.452902157881.issue14640@psf.upfronthosting.co.za> New submission from Dionysios Kalofonos : See attached file. ---------- assignee: docs at python components: Documentation files: pyporting.diff keywords: patch messages: 158913 nosy: dk, docs at python priority: normal severity: normal status: open title: Typos in pyporting.rst versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file25299/pyporting.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 12:41:32 2012 From: report at bugs.python.org (Roland) Date: Sat, 21 Apr 2012 10:41:32 +0000 Subject: [issue14606] Memory leak subprocess on Windows In-Reply-To: <1334689181.81.0.435135933783.issue14606@psf.upfronthosting.co.za> Message-ID: <1335004892.85.0.412983808875.issue14606@psf.upfronthosting.co.za> Roland added the comment: yes, thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 12:48:08 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 21 Apr 2012 10:48:08 +0000 Subject: [issue14606] Memory leak subprocess on Windows In-Reply-To: <1334689181.81.0.435135933783.issue14606@psf.upfronthosting.co.za> Message-ID: <1335005288.25.0.821081892271.issue14606@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 13:15:20 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 21 Apr 2012 11:15:20 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> Message-ID: <1335006920.45.0.840355189671.issue14632@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Thanks for the report and patch. I'm making Vinay nosy, as he's the logging expert. A couple remarks: - it would be nice to add your testcase to the logging tests (Lib/test/test_logging.py) - I think you could probably save the whole fstat() result (instead of st_dev and st_inode): this would allow you to use os.pathsamestat() to check whether we're still refering to the same file, and it could maybe be useful someday (maybe use st_mtime) - typo: "existance" -> "existence" - I see you're catching OSError when calling fstat(): however, I don't see what error could be raised apart from EBADF (if the FD is closed, then it's likely a bug that shouldn't be masked, and it will blow up on the next write()), or I/O errors, that shouldn't be silenced ---------- nosy: +neologix, vinay.sajip versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 14:21:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 21 Apr 2012 12:21:09 +0000 Subject: [issue14635] telnetlib uses select instead of poll - limited to FD_SETSIZE fds In-Reply-To: <1334949623.77.0.295518189269.issue14635@psf.upfronthosting.co.za> Message-ID: <1335010869.69.0.305200249844.issue14635@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Note that this probably affects other modules besides telnetlib, so it > might be interesting to find a way to factorize code (i.e. use poll() > if available or fallback to select()). asyncore might have been the answer. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 14:46:41 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 21 Apr 2012 12:46:41 +0000 Subject: [issue11477] Bug in code dispatching based on internal slots In-Reply-To: <1299965091.63.0.267715976543.issue11477@psf.upfronthosting.co.za> Message-ID: <1335012401.06.0.614827034022.issue11477@psf.upfronthosting.co.za> Nick Coghlan added the comment: And, back on topic... I've been pondering this problem and the approach I adopted in my branch and decided it's the *wrong* way to go about it. It takes an already complex piece of code and makes it even more complicated. A completely different approach that I'm considering is to instead make types defined in C behave more like their counterparts defined in Python. The reason sequences implemented in Python don't have this problem is because their nb_add and nb_mul slots get filled in with functions that call up into the Python __[ri]add__ and __[ri]mul__ implementations. So my thought is that, when the type construction machinery is filling in the type slots, we could actually do something similar at the C level: define a standard _PySequenceAsNumber variable and add a pointer to that in to the tp_as_number slot. The nb_add and nb_mul slots in this structure would reference functions that delegated the relevant operations to sq_concat and sq_repeat. I haven't actually tried this approach, so there may be practical issues with it that haven't occurred to me as yet, but it's definitely appealing as it has the potential to *simplify* the dispatch code in abstract.c instead of making it even more complicated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 14:50:16 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 21 Apr 2012 12:50:16 +0000 Subject: [issue11477] Bug in code dispatching based on internal slots In-Reply-To: <1299965091.63.0.267715976543.issue11477@psf.upfronthosting.co.za> Message-ID: <1335012616.99.0.61357433774.issue11477@psf.upfronthosting.co.za> Nick Coghlan added the comment: Heh, rereading the issue comments, I noticed that my latest idea is quite similar to what Terry suggested last year, just using delegation to adjust the signatures appropriately rather than copying the function pointers directly over. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 15:49:17 2012 From: report at bugs.python.org (Dionysios Kalofonos) Date: Sat, 21 Apr 2012 13:49:17 +0000 Subject: [issue14641] Minor fixes in sockets.rst Message-ID: <1335016157.05.0.701229655848.issue14641@psf.upfronthosting.co.za> New submission from Dionysios Kalofonos : See attached file. ---------- assignee: docs at python components: Documentation files: sockets.diff keywords: patch messages: 158919 nosy: dk, docs at python priority: normal severity: normal status: open title: Minor fixes in sockets.rst versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file25300/sockets.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 16:03:54 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 21 Apr 2012 14:03:54 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1335017034.0.0.486476995932.issue7559@psf.upfronthosting.co.za> R. David Murray added the comment: Does fix for issue 1559549 (and the fact that importlib is in) allow for a cleaner fix for this? I've been putting off dealing with this issue in the expectation that it would. To answer the question: the fixed API can go in 3.3. If we fix this in earlier versions the API should probably stay the same there, and since the above is 3.3 only, the existing patch is probably appropriate there. If Michael doesn't pass judgement soon I'll take a look, since this causes me problems at least once a week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 16:19:10 2012 From: report at bugs.python.org (Michael Foord) Date: Sat, 21 Apr 2012 14:19:10 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1335017950.4.0.421997981582.issue7559@psf.upfronthosting.co.za> Michael Foord added the comment: My favoured fix is to catch the exception and generate a failing test that re-raises the *original exception* (with traceback) when run. That way a single failing module doesn't kill a whole test run (although it does mean later feedback about misspelt imports). It also means (the main problem being reported here) that unittest no longer masks exceptions whilst importing test modules. This would be a new feature / api change - so it would be Python 3.3 only (but it would go into unittest2). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 16:52:20 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 21 Apr 2012 14:52:20 +0000 Subject: [issue14636] Mock could check for exceptions in side effect list In-Reply-To: <1334954289.59.0.991318648825.issue14636@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset c310233b1d64 by Michael Foord in branch 'default': Closes issue 14636. mock objects raise exceptions from an iterable side_effect http://hg.python.org/cpython/rev/c310233b1d64 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 18:48:29 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 21 Apr 2012 16:48:29 +0000 Subject: [issue14443] Distutils test failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <1335026909.56.0.114824742681.issue14443@psf.upfronthosting.co.za> Nick Coghlan added the comment: This failure is also affecting the new RHEL-6 buildbot I'm attempting to bring online. Failure on trunk: http://www.python.org/dev/buildbot/all/builders/x86%20RHEL%206%203.x/builds/12/steps/test/logs/stdio Failure on 3.2: http://www.python.org/dev/buildbot/all/builders/x86%20RHEL%206%203.2/builds/1/steps/test/logs/stdio Seems like it may be an old problem come back to life: https://www.redhat.com/archives/rhl-devel-list/2009-January/msg00389.html (The rh-devel-list link is interesting more for the problem description than it is for the suggested workaround) ---------- keywords: +buildbot nosy: +ncoghlan versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 18:49:52 2012 From: report at bugs.python.org (Michael Foord) Date: Sat, 21 Apr 2012 16:49:52 +0000 Subject: [issue14634] Mock cannot autospec functions with keyword-only arguments. In-Reply-To: <1334945284.24.0.289841146723.issue14634@psf.upfronthosting.co.za> Message-ID: <1335026992.85.0.592858091004.issue14634@psf.upfronthosting.co.za> Michael Foord added the comment: This is non-trivial to fix. Although inspect.getfullargspec can be used, which does support keyword only arguments, inspect.formatargspec *doesn't* support them. (mock.create_autospec uses these to rebuild a compatible signature for generated mocks.) The easiest route to fixing would be to extend formatargspec to optionally take extra arguments for kwonlyargs and kwonlydefaults. ---------- assignee: -> michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 18:58:05 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 21 Apr 2012 16:58:05 +0000 Subject: [issue14443] Distutils test failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <1335027485.27.0.680278769911.issue14443@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm wondering if there may be a deeper problem here: how certain are we that bdist_rpm isn't using the system Python to handle the byte compilation step? It would explain why the files are still being generated in the old locations. And, in practical terms, who uses RPM to package Python software for any version of Python other than the system Python? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 19:03:30 2012 From: report at bugs.python.org (Michael Foord) Date: Sat, 21 Apr 2012 17:03:30 +0000 Subject: [issue14634] Mock cannot autospec functions with keyword-only arguments. In-Reply-To: <1334945284.24.0.289841146723.issue14634@psf.upfronthosting.co.za> Message-ID: <1335027810.64.0.997236451652.issue14634@psf.upfronthosting.co.za> Changes by Michael Foord : ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 19:09:49 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 21 Apr 2012 17:09:49 +0000 Subject: [issue14157] time.strptime without a year fails on Feb 29 In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za> Message-ID: <1335028189.91.0.6900545559.issue14157@psf.upfronthosting.co.za> Hynek Schlawack added the comment: I gave it a shot, doesn?t look like a hack to me, what do you think? ---------- keywords: +patch Added file: http://bugs.python.org/file25301/strptime-on-leap-years.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 19:10:56 2012 From: report at bugs.python.org (Michael Foord) Date: Sat, 21 Apr 2012 17:10:56 +0000 Subject: [issue14634] Mock cannot autospec functions with keyword-only arguments. In-Reply-To: <1334945284.24.0.289841146723.issue14634@psf.upfronthosting.co.za> Message-ID: <1335028256.71.0.297939701989.issue14634@psf.upfronthosting.co.za> Michael Foord added the comment: Hmmm... looks like formatargspec does support these features but they aren't documented. If it works out I'll update the docs for inspect.formatargspec too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 21 19:22:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 21 Apr 2012 17:22:48 +0000 Subject: [issue14634] Mock cannot autospec functions with keyword-only arguments. In-Reply-To: <1334945284.24.0.289841146723.issue14634@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 6f478a4aa137 by Michael Foord in branch 'default': Closes issue 14634. unittest.mock.create_autospec now supports keyword only arguments. http://hg.python.org/cpython/rev/6f478a4aa137 ---------- nosy: +python-dev resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 00:48:01 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 21 Apr 2012 22:48:01 +0000 Subject: [issue14637] test.test_import.PathsTests.test_UNC_path is failing In-Reply-To: <1334954491.9.0.0351086786979.issue14637@psf.upfronthosting.co.za> Message-ID: <1335048481.99.0.362210088841.issue14637@psf.upfronthosting.co.za> Vinay Sajip added the comment: I think that the line just before the __import__ call: sys.path.append(path) should say sys.path.append(unc) With this change, test_import passes for me (on the pythonv branch). ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 00:51:28 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 21 Apr 2012 22:51:28 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> Message-ID: <1335048688.95.0.209733439761.issue14632@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- assignee: -> vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 00:53:27 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 21 Apr 2012 22:53:27 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b773a751c2e7 by Brett Cannon in branch 'default': Issue #13959: Re-implement imp.cache_from_source() in Lib/imp.py. http://hg.python.org/cpython/rev/b773a751c2e7 New changeset ea46ebba8a0f by Brett Cannon in branch 'default': Issue #13959: Re-implement imp.source_from_cache() in Lib/imp.py. http://hg.python.org/cpython/rev/ea46ebba8a0f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 01:02:39 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 21 Apr 2012 23:02:39 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335049359.12.0.371044527957.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: Time for a recap! I am personally not bothering with moving imp.get_tag() and imp.get_magic() to importlib._bootstrap as the amount of C code required to support the public C API is not worth it. If someone else once to do the work then by all means attach a patch. I still need to port imp.find_module() (and the various constants) and will base it off of Eric's code. NullImporter will get ported once issue #14605 (exposing the import machinery) lands. get_suffixes() will also get ported, but that is a little bit more involved as I need to change how _DynLoadFiletab works by only storing the file extensions and not the other fluff (which is the same for all OSs). After all of that is done then I will expose some API in importlib to replace find_module() and load_*() functions and then deprecate them (see issue #14551 for an ongoing discussion the possible API). ---------- assignee: -> brett.cannon dependencies: +Make import machinery explicit stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 01:04:32 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 21 Apr 2012 23:04:32 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1335049472.36.0.174342392812.issue1521950@psf.upfronthosting.co.za> Vinay Sajip added the comment: I've received no comments on the latest revision of my patch (incorporating comments on the previous version); is it OK to commit this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 01:12:08 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 21 Apr 2012 23:12:08 +0000 Subject: [issue14637] test.test_import.PathsTests.test_UNC_path is failing In-Reply-To: <1334954491.9.0.0351086786979.issue14637@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 0356103cde28 by Brett Cannon in branch 'default': Issue #14637: Fix the UNC import test under Windows to actually use http://hg.python.org/cpython/rev/0356103cde28 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 01:15:08 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 21 Apr 2012 23:15:08 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1335050108.99.0.267356070009.issue1521950@psf.upfronthosting.co.za> R. David Murray added the comment: I'd like to take a look at this (I wasn't aware of it before). I'll try to do that some time in the next 24 hours, and if I don't you shouldn't wait for me :) Did you address Dan's concern about 'old' possibly not matching the old behavior completely? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 01:15:38 2012 From: report at bugs.python.org (Brett Cannon) Date: Sat, 21 Apr 2012 23:15:38 +0000 Subject: [issue14637] test.test_import.PathsTests.test_UNC_path is failing In-Reply-To: <1334954491.9.0.0351086786979.issue14637@psf.upfronthosting.co.za> Message-ID: <1335050138.87.0.195846271584.issue14637@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for catching that, Vinay! Just waiting for the buildbots to verify my fix (which also included invalidating the cache which is why it was sporadic plus cleaning up sys.path properly). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 01:36:30 2012 From: report at bugs.python.org (Ned Deily) Date: Sat, 21 Apr 2012 23:36:30 +0000 Subject: [issue10731] UnicodeDecodeError in OS X tkinter when binding to In-Reply-To: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za> Message-ID: <1335051390.36.0.979567903861.issue10731@psf.upfronthosting.co.za> Ned Deily added the comment: The exception also occurs with Python 3.3 linked with Cocoa Tk 8.5. However, the it does not appear when Python 3.x is linked with Carbon Tk 8.4. ---------- components: +Tkinter stage: -> needs patch versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 01:49:36 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 21 Apr 2012 23:49:36 +0000 Subject: [issue14517] Recompilation of sources with Distutils In-Reply-To: <1333711497.18.0.995661570344.issue14517@psf.upfronthosting.co.za> Message-ID: <1335052176.77.0.973379319144.issue14517@psf.upfronthosting.co.za> ?ric Araujo added the comment: Is it #5372? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 02:06:07 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 22 Apr 2012 00:06:07 +0000 Subject: [issue14639] Different behavior for urllib2 in Python 2.7 In-Reply-To: <1334963627.5.0.25860672306.issue14639@psf.upfronthosting.co.za> Message-ID: <1335053167.13.0.894162701507.issue14639@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Could you give the proper POST FORM url which you were trying? I could try it in 2.6 and 2.7 and see if there is any difference. Nothing has changed that such low levels like the POST operations by sending of data. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 02:58:16 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 22 Apr 2012 00:58:16 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335056296.55.0.638701992566.issue13959@psf.upfronthosting.co.za> Eric Snow added the comment: Yeah, I'm hoping to keep pressing those odds and ends forward. I have one lingering, oddball bug in find_module, but that patch is pretty much standing on its own. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 03:05:47 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 22 Apr 2012 01:05:47 +0000 Subject: [issue14637] test.test_import.PathsTests.test_UNC_path is failing In-Reply-To: <1334954491.9.0.0351086786979.issue14637@psf.upfronthosting.co.za> Message-ID: <1335056747.86.0.758845082324.issue14637@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for catching that, Vinay! Buildbots say it worked. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 03:15:34 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 22 Apr 2012 01:15:34 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 085cf1480cfe by Brett Cannon in branch 'default': Issue #13959: Re-implement imp.find_module() in Lib/imp.py. http://hg.python.org/cpython/rev/085cf1480cfe ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 03:20:05 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 22 Apr 2012 01:20:05 +0000 Subject: [issue2193] Cookie Colon Name Bug In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 57ec2e6cd70a by Senthil Kumaran in branch 'default': Fix Issue2193 - Allow ":" character in Cookie NAME values http://hg.python.org/cpython/rev/57ec2e6cd70a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 03:28:56 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 22 Apr 2012 01:28:56 +0000 Subject: [issue2193] Cookie Colon Name Bug In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za> Message-ID: <1335058136.98.0.726349655338.issue2193@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I tested with apache to set ":" in names and then verified the behavior in browsers and it looks like it fine to allow ":" as legal character in cookie name ( though RFC originally does say that). My guess is previously it could have been thought that ":" might hinder parsing, but does not seem so as how Cookie name=value;name2=values2 have evolved. So in 3.3, I have made the change to just allow ":" in Cookie Name. But as previous versions raised CookieError error, I see this is a change in behavior and it should not be back-ported. In Docs 2.7,3.2 etc, I see the mention that users should look for and catch CookieError if they are capturing cookies from unknown sources, in case if it contains any illegal characters. That still applies to other illegal characters. I think, the docs could just be updated with mention of illegal characters in python versions to be little more helpful and with that, this issue can be closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 03:52:48 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 22 Apr 2012 01:52:48 +0000 Subject: [issue14642] Fix imoprtlib.h build rule to not depend on hg Message-ID: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> New submission from Brett Cannon : A shell or Python script should be used to verify that importlib.h actually needs to be rebuilt, and if so make sure that it's even possible (since it depends on a locally built ./python). ---------- components: Build messages: 158944 nosy: brett.cannon, georg.brandl, loewis priority: release blocker severity: normal stage: needs patch status: open title: Fix imoprtlib.h build rule to not depend on hg type: compile error versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 04:32:15 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 22 Apr 2012 02:32:15 +0000 Subject: [issue2193] Cookie Colon Name Bug In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset d3b0845a9253 by Senthil Kumaran in branch '3.2': issue2193 - Update 3.2 docs about legal characters allowed in Cookie name http://hg.python.org/cpython/rev/d3b0845a9253 New changeset 8cae3ee7f691 by Senthil Kumaran in branch 'default': issue2193 - Update docs about the legal characters allowed in Cookie name http://hg.python.org/cpython/rev/8cae3ee7f691 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 04:39:29 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 22 Apr 2012 02:39:29 +0000 Subject: [issue2193] Cookie Colon Name Bug In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za> Message-ID: <1335062369.5.0.829120426443.issue2193@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 06:40:47 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 22 Apr 2012 04:40:47 +0000 Subject: [issue10731] UnicodeDecodeError in OS X tkinter when binding to In-Reply-To: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za> Message-ID: <1335069647.48.0.606291860964.issue10731@psf.upfronthosting.co.za> Ned Deily added the comment: It looks like the problem is that the current Cocoa Tcl/Tk 8.5.x returns an incorrect MouseWheel event. Using the supplied test program and breakpointing in PythonCmd (around Modules/_tkinter.c:2027 in default), I found that it is being called from Tcl for MouseWheel events with an "argc" of 20, which looks suspiciously like the length of argv[1], "4302153816mouse_wheel", rather than the number of arguments which should be more like 3. It may also be an issue that affects Python because _tkinter still uses the older Tcl_CreateCommand interface rather than the newer Tcl_CreateObjCommand. The same Tcl behavior is observed with Python 2.7 _tkinter.c but there the bogus arguments are translated using PyString_FromString which is unaffected by the garbage arguments. It might be possible to workaround this problem in _tkinter but the next step is to open a Tcl/Tk issue against the Cocoa implementation and push for a proper fix there. http://www.tcl.tk/man/tcl8.5/TclLib/CrtCommand.htm ---------- assignee: ronaldoussoren -> ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 06:56:23 2012 From: report at bugs.python.org (Ned Deily) Date: Sun, 22 Apr 2012 04:56:23 +0000 Subject: [issue10731] UnicodeDecodeError in OS X tkinter when binding to In-Reply-To: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za> Message-ID: <1335070583.99.0.0404211798807.issue10731@psf.upfronthosting.co.za> Ned Deily added the comment: I've opened Tk Toolkit bug 3520202: https://sourceforge.net/tracker/?func=detail&aid=3520202&group_id=12997&atid=112997 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 07:53:02 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 22 Apr 2012 05:53:02 +0000 Subject: [issue1703178] link_objects in setup.cfg crashes build Message-ID: <1335073982.95.0.526957608563.issue1703178@psf.upfronthosting.co.za> ?ric Araujo added the comment: The code in build_ext is missing a few ensure_string_list calls; it is a method that converts a string (from the setup.cfg file or command line) into a list, or if the attribute is already a list (if it was given in setup.py) then leave it alone. Recently I fixed the same bug with the build_ext --libraries option (#1326113), so it?s easy to make a patch with the same kind of tests and the code fix. ---------- assignee: tarek -> eric.araujo components: +Distutils2 -Build keywords: +easy nosy: +alexis, eric.araujo status: pending -> open versions: +3rd party, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 07:58:52 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 22 Apr 2012 05:58:52 +0000 Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib Message-ID: <1335074332.11.0.940282416754.issue1326113@psf.upfronthosting.co.za> ?ric Araujo added the comment: Another instance of this is #1703178. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 09:17:38 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 22 Apr 2012 07:17:38 +0000 Subject: [issue14026] test_cmd_line_script should include more sys.argv checks In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 22f0044ea366 by Nick Coghlan in branch '3.2': Close issue #14026 by better testing sys.argv handling in test_cmd_line_script (patch by Jason Yeo) http://hg.python.org/cpython/rev/22f0044ea366 New changeset ff6593aa8376 by Nick Coghlan in branch 'default': Resolve #14026 (Merge from 3.2) http://hg.python.org/cpython/rev/ff6593aa8376 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 09:20:53 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 22 Apr 2012 07:20:53 +0000 Subject: [issue14026] test_cmd_line_script should include more sys.argv checks In-Reply-To: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za> Message-ID: <1335079253.84.0.857231936678.issue14026@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 09:41:33 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 22 Apr 2012 07:41:33 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335080493.54.0.479694619507.issue13959@psf.upfronthosting.co.za> Eric Snow added the comment: Ported _imp.reload() (Python/import.c) to Lib/imp.py. Included is the change to PyImport_ReloadModule() to make it simply a wrapper around the pure Python imp.reload(). There's a good chance I don't have this right or that I have some reference leak. I haven't worked a ton on the C side of Python (sounds tropical). This patch also removes 'modules_reloading' from the interpreter state, since it's no longer used anywhere (see issue14618). ---------- Added file: http://bugs.python.org/file25302/issue13959_reload.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 09:42:35 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 22 Apr 2012 07:42:35 +0000 Subject: [issue14618] remove modules_reloading from the interpreter state In-Reply-To: <1334799147.41.0.250628519615.issue14618@psf.upfronthosting.co.za> Message-ID: <1335080555.36.0.659966427714.issue14618@psf.upfronthosting.co.za> Eric Snow added the comment: patch added to issue13959. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 10:20:59 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 22 Apr 2012 08:20:59 +0000 Subject: [issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu In-Reply-To: <1334734810.54.0.87567518387.issue14610@psf.upfronthosting.co.za> Message-ID: <1335082859.73.0.864988899409.issue14610@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Could you please run: $ sh -x ./configure to see what's going on. It might also be interesting to have the output of $ strace -f ./configure Thanks. ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 11:28:12 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 22 Apr 2012 09:28:12 +0000 Subject: [issue14643] Security page out of date Message-ID: <1335086892.52.0.709735016989.issue14643@psf.upfronthosting.co.za> New submission from Antoine Pitrou : http://www.python.org/news/security/ is completely out of date. Also, the release pages (e.g. http://www.python.org/download/releases/2.7.3/) don't make it clear which versions are affected by the security issues. ---------- components: None messages: 158954 nosy: barry, benjamin.peterson, georg.brandl, loewis, pitrou priority: normal severity: normal status: open title: Security page out of date _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 11:33:07 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 22 Apr 2012 09:33:07 +0000 Subject: [issue14643] Security page out of date In-Reply-To: <1335086892.52.0.709735016989.issue14643@psf.upfronthosting.co.za> Message-ID: <1335087187.66.0.51444424013.issue14643@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 11:44:42 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 22 Apr 2012 09:44:42 +0000 Subject: [issue14591] Value returned by random.random() out of valid range on 64-bit In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1335087882.14.0.104484993447.issue14591@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Value returned by random.random() out of valid range -> Value returned by random.random() out of valid range on 64-bit _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 11:54:39 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 22 Apr 2012 09:54:39 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: <1335088479.83.0.848966324705.issue14642@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- title: Fix imoprtlib.h build rule to not depend on hg -> Fix importlib.h build rule to not depend on hg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 12:40:23 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 22 Apr 2012 10:40:23 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335091223.64.0.830230618158.issue13959@psf.upfronthosting.co.za> Eric Snow added the comment: A patch for magic and tag. It's not quite finished, but I wanted to see if the approach was palatable. FYI, I'm also trying to push forward the sys.implementation stuff, which would help on the pyc tag. ---------- Added file: http://bugs.python.org/file25303/issue13959_magic.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 13:20:59 2012 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 22 Apr 2012 11:20:59 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: <1335093659.76.0.637123959565.issue14642@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 13:50:46 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 22 Apr 2012 11:50:46 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1335095446.4.0.646093883638.issue1521950@psf.upfronthosting.co.za> Vinay Sajip added the comment: I believe Dan meant that the behaviour of shlex.split() now is different from what it was when he first raised the issue (in July 2006). Looking at the default branch of CPython, this is what I see: Python 3.3.0a2+ (default:ff6593aa8376, Apr 22 2012, 12:39:08) [GCC 4.3.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import shlex >>> list(shlex.shlex('e;')) ['e', ';'] >>> list(shlex.shlex(">'abc';")) ['>', "'abc'", ';'] Likewise, on the 2.6 branch: Python 2.6.8+ (unknown, Apr 22 2012, 12:44:43) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import shlex >>> list(shlex.shlex('e;')) ['e', ';'] >>> list(shlex.shlex(">'abc';")) ['>', "'abc'", ';'] So from what Dan is saying, it would seem that he is saying that shlex behaviour (before my patch being applied) is different now to how he remembers it - not that the patch introduces any incompatibility. Still, another set of eyeballs on the patch would be good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 14:29:44 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 22 Apr 2012 12:29:44 +0000 Subject: [issue14644] test_logging failure on OS X Tiger Message-ID: <1335097784.55.0.606093462856.issue14644@psf.upfronthosting.co.za> New submission from Antoine Pitrou : test_logging always fails on the OS X Tiger buildbot: http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x Traceback (most recent call last): File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/smtplib.py", line 365, in getreply line = self.file.readline() File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/socket.py", line 297, in readinto return self._sock.recv_into(b) socket.timeout: timed out During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/logging/handlers.py", line 930, in emit smtp = smtplib.SMTP(self.mailhost, port, timeout=self.timeout) File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/smtplib.py", line 238, in __init__ (code, msg) = self.connect(host, port) File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/smtplib.py", line 319, in connect (code, msg) = self.getreply() File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/smtplib.py", line 369, in getreply + str(e)) smtplib.SMTPServerDisconnected: Connection unexpectedly closed: timed out Logged from file , line 0 test test_logging failed ok ====================================================================== FAIL: test_basic (test.test_logging.SMTPHandlerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_logging.py", line 941, in test_basic self.assertTrue(self.handled.is_set()) AssertionError: False is not true ---------- assignee: vinay.sajip components: Library (Lib), Tests messages: 158957 nosy: pitrou, vinay.sajip priority: normal severity: normal status: open title: test_logging failure on OS X Tiger type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 14:30:01 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 22 Apr 2012 12:30:01 +0000 Subject: [issue14644] test_logging failure on OS X Tiger In-Reply-To: <1335097784.55.0.606093462856.issue14644@psf.upfronthosting.co.za> Message-ID: <1335097801.34.0.678824939974.issue14644@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +db3l _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 14:54:23 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 22 Apr 2012 12:54:23 +0000 Subject: [issue14591] Value returned by random.random() out of valid range on 64-bit In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1335099263.43.0.951061842588.issue14591@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patch should probably come with an unit test. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 14:56:33 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 22 Apr 2012 12:56:33 +0000 Subject: [issue14591] Value returned by random.random() out of valid range on 64-bit In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1335099393.62.0.0730817157598.issue14591@psf.upfronthosting.co.za> Mark Dickinson added the comment: Patch with unit test. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 14:56:50 2012 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 22 Apr 2012 12:56:50 +0000 Subject: [issue14474] mishandling of AttributeError in threads In-Reply-To: <1333368500.29.0.652267156106.issue14474@psf.upfronthosting.co.za> Message-ID: <1335099410.4.0.200561605363.issue14474@psf.upfronthosting.co.za> Stefan Behnel added the comment: Could the while thread._count() > c: pass in test_thread.py be changed to this? (as used in other places) while thread._count() > c: time.sleep(0.01) It currently hangs in Cython because it doesn't free the GIL during the plain C loop. (While that might be considered a bug in Cython, it's not what this test is supposed to test for.) ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 14:56:58 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 22 Apr 2012 12:56:58 +0000 Subject: [issue14591] Value returned by random.random() out of valid range on 64-bit In-Reply-To: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za> Message-ID: <1335099418.04.0.600256079216.issue14591@psf.upfronthosting.co.za> Mark Dickinson added the comment: Dang. Patch now attached. ---------- Added file: http://bugs.python.org/file25304/random_jumpahead_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 15:11:44 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 22 Apr 2012 13:11:44 +0000 Subject: [issue1762561] unable to serialize Infinity or NaN on ARM using marshal Message-ID: <1335100304.13.0.696155391582.issue1762561@psf.upfronthosting.co.za> Mark Dickinson added the comment: [Dirkjan] > Could we reconsider ARM support at this time? Note that it's just the Linux old ABI (OABI) that needs this patch; ARM / Linux using the new family of ABIs (EABI) should be fine. IIUC, this old ABI is being phased out, but I have no idea what the current real-world situation is here. Maybe it's worth reopening a discussion on python-dev? I'm not sure what the current policies are. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 16:02:47 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 22 Apr 2012 14:02:47 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1334868903.63.0.8592656761.issue14532@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I have used the name "secure_compare" in the past for such a function. That > said, I don't have strong feelings either way about the naming, so I'll > yield to the others. I prefer this name too. Wait one day or two (to let others chime in if they want), and upload a new patch with that change :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 16:16:22 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 22 Apr 2012 14:16:22 +0000 Subject: [issue14643] Security page out of date In-Reply-To: <1335086892.52.0.709735016989.issue14643@psf.upfronthosting.co.za> Message-ID: <1335104182.36.0.473410694715.issue14643@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I fixed the 2.7.3 page. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 16:29:18 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 22 Apr 2012 14:29:18 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: <1335104958.31.0.893994277841.issue14642@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 17:01:55 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 22 Apr 2012 15:01:55 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: <1335106915.06.0.294356657211.issue14642@psf.upfronthosting.co.za> Brett Cannon added the comment: The thing should also do a sanity check on the syntax so as to minimize the chances of freezing code that has no chance of working. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 17:09:33 2012 From: report at bugs.python.org (Kevin Walzer) Date: Sun, 22 Apr 2012 15:09:33 +0000 Subject: [issue10731] UnicodeDecodeError in OS X tkinter when binding to In-Reply-To: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za> Message-ID: <1335107373.66.0.554242471594.issue10731@psf.upfronthosting.co.za> Kevin Walzer added the comment: I've added some comments to this on the Tkinter-dev mailing list, but to summarize, the bug is not reproducible on the Tcl side of the bridge, and so I am not clear what changes can be made in Tk's internals. It might e better to proceed with implementing a fix in Tkinter because the bug seems to occur at the level of Tkinter/Tk interaction. ---------- nosy: +wordtech _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 17:12:14 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 22 Apr 2012 15:12:14 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1335107534.06.0.469083357761.issue2377@psf.upfronthosting.co.za> Brett Cannon added the comment: To note: _frozen_importlib is a CPython implementation detail ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 17:38:48 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 22 Apr 2012 15:38:48 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335109128.5.0.29918635557.issue13959@psf.upfronthosting.co.za> Eric Snow added the comment: After thinking about it, is MAGIC an implementation detail? It certainly reflects changes specific to the CPython interpreter. I'm much more comfortable with leaving implementation details in Python/import.c. On the other hand, there's already no small amount of rather CPython-specific stuff in Lib/importlib/_bootstrap.py, which belongs there. The pyc magic bytes are tightly coupled with it. Because of that, I realize, I'm still fine with the patch. But it makes me wonder if it might be worth having a clear separation between the general and CPython-specific stuff in _bootstrap.py, for the sake of people who look at the code for the first (or tenth) time. That's the same rationale I have for advocating moving as much over from import.c as relates to the importlib implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 18:43:19 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 22 Apr 2012 16:43:19 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: <1335112999.46.0.0783043468993.issue14642@psf.upfronthosting.co.za> Martin v. L?wis added the comment: What do you mean by "sanity check on the syntax"? The current Makefile rule to build importlib.h already checks the syntax of _bootstrap.py, and fails if there is a syntax error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 19:02:06 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 22 Apr 2012 17:02:06 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335112999.46.0.0783043468993.issue14642@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: On Sun, Apr 22, 2012 at 12:43, Martin v. L?wis wrote: > > Martin v. L?wis added the comment: > > What do you mean by "sanity check on the syntax"? The current Makefile > rule to build importlib.h already checks the syntax of _bootstrap.py, and > fails if there is a syntax error That's true, so ignore my comment. =) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 19:02:40 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 22 Apr 2012 17:02:40 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 4e853913054c by Brett Cannon in branch 'default': Issue #13959: Continue to try to accomodate altsep in importlib by not http://hg.python.org/cpython/rev/4e853913054c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 19:10:05 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 22 Apr 2012 17:10:05 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: <1335114605.31.0.68593364878.issue14642@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Also, what's the issue with a shell script? The current Makefile will rebuild importlib.h if its time stamp is older than the one of _bootstrap.py. That will fail if ./python was not build. So what is the problem to solve? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 19:14:45 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 22 Apr 2012 17:14:45 +0000 Subject: [issue1346572] Remove inconsistent behavior between import and zipimport Message-ID: <1335114885.03.0.56333586477.issue1346572@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- resolution: -> wont fix stage: needs patch -> committed/rejected status: open -> closed versions: -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 19:16:22 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 22 Apr 2012 17:16:22 +0000 Subject: [issue14622] Python http.server is dead slow using gethostbyaddr/getfqdn for each request In-Reply-To: <1334858349.45.0.662214350668.issue14622@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset fe66fb61f199 by Vinay Sajip in branch 'default': Issue #14622: Increased default timeout for SMTPHandler. http://hg.python.org/cpython/rev/fe66fb61f199 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 19:16:31 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 22 Apr 2012 17:16:31 +0000 Subject: [issue1762561] unable to serialize Infinity or NaN on ARM using marshal Message-ID: <1335114991.15.0.377617626517.issue1762561@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This issue remains as "won't fix". ARM is supported; just OABI is not, and never will be. If anybody needs that, they will have to maintain their own fork of Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 19:20:00 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 22 Apr 2012 17:20:00 +0000 Subject: [issue14644] test_logging failure on OS X Tiger In-Reply-To: <1335097784.55.0.606093462856.issue14644@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset bdbcb8f48ddd by Vinay Sajip in branch 'default': Issue #14644: Increased default timeout for SMTPHandler. Note: last commit message referred to the wrong issue number. http://hg.python.org/cpython/rev/bdbcb8f48ddd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 19:20:36 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 22 Apr 2012 17:20:36 +0000 Subject: [issue14622] Python http.server is dead slow using gethostbyaddr/getfqdn for each request In-Reply-To: <1334858349.45.0.662214350668.issue14622@psf.upfronthosting.co.za> Message-ID: <1335115236.91.0.714611951856.issue14622@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- Removed message: http://bugs.python.org/msg158973 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 19:47:05 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 22 Apr 2012 17:47:05 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> Message-ID: <1335116825.32.0.639130319143.issue14632@psf.upfronthosting.co.za> Vinay Sajip added the comment: There's certainly a problem to be addressed here, but integrating the test into the regular test suite represents a problem in that the test takes around 10 minutes to run, and sometimes completes successfully. I'm not sure a 10-minute extension of the time taken to run regrtest will be acceptable, but if the test is skipped unless explicitly enabled, then I'm not sure it'll add much value. I will look at the patch and Charles-Fran?ois' review comments soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 19:49:40 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 22 Apr 2012 17:49:40 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: <1335116980.02.0.898548104368.issue14642@psf.upfronthosting.co.za> Brett Cannon added the comment: I don't quite follow. I have no issue with a shell script verifying things by doing an `hg status` to verify certain truths (or something). I said a shell *or* Python script to begin with. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 19:57:08 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 22 Apr 2012 17:57:08 +0000 Subject: [issue14645] Generator does not translate linesep characters in certain circumstances Message-ID: <1335117428.2.0.322445942387.issue14645@psf.upfronthosting.co.za> New submission from R. David Murray : I ran into this while translating a test, but it turns out it is a long standing problem. I presume it has not been an issue because in general in Python2 email messages are read as text with universal newline support, and thus the linesep characters get translated on *read*, and the problem in Generator never shows up. In python3, however, we will often read messages as binary, which will preserve the existing linesep characters, and expose the Generator bug. This isn't a critical bug for Python3 only because if a message is read in binary it will likely be written in binary using \r\n linesep, in which case the right thing will be happening. Likewise most messages read from disk will be written to disk. But it should be fixed so that the cases where a message is read in binary and written to disk in text and vice versa are correctly formatted. (In particular, uses of the new smtplib.send_message could theoretically run in to this, though I haven't tested to see if that is really a problem.) To reproduce, read data/msg_26.txt from the email test suite in binary mode (or text mode using "linesep='\n'", which will preserve the crlf in that file), and run str on the resulting message. You'll see that the MIME preamble and the base64 part both have \r\n linesep, instead of the default '\n' linesep used for the rest of the message. ---------- assignee: r.david.murray messages: 158978 nosy: r.david.murray priority: normal severity: normal stage: needs patch status: open title: Generator does not translate linesep characters in certain circumstances type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 20:41:57 2012 From: report at bugs.python.org (JohnM) Date: Sun, 22 Apr 2012 18:41:57 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> Message-ID: <1335120117.92.0.0997506841347.issue14632@psf.upfronthosting.co.za> JohnM added the comment: Thank you both for looking at this. I've added an updated version of the patch that incorporates the last two suggestions that Charles-Fran?ois made. I agree that this test may not be appropriate for the python test suite, due to the length and non-determinism of the test. I don't know what the suite's policy on monkey patching stdlib in the tests is, but monkey patching either os.path.exists or os.stat to remove the file at the appropriate time could be one way to make the test fast and deterministic. Seems a bit dirty to me though. :-) I am up for adding some kind of test to the suite for the WatchedFileHandler, though. I'm pretty ambivalent about keeping the whole stat structure around, since the samestat method is just a wrapper around what the emit function is already doing, and we'd be keeping more memory (although a small amount) around. I doubt we'd want to look at the timestamps because they could legitimately change in ways this check doesn't care about. ---------- Added file: http://bugs.python.org/file25305/watchedfilehandler.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 20:42:19 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 22 Apr 2012 18:42:19 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1335116825.32.0.639130319143.issue14632@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > There's certainly a problem to be addressed here, but integrating the test into the regular test suite represents a problem in that the test takes around 10 minutes to run, and sometimes completes successfully. I'm not sure a 10-minute extension of the time taken to run regrtest will be acceptable, but if the test is skipped unless explicitly enabled, then I'm not sure it'll add much value. There's no reason to wait for 10 minutes: one can reduce the number of iterations greatly, so that it can run in a matter of seconds. Since the test is run by all the builders multiple times per day, should the race condition resurface, it will trigger a buildbot failure some day. No need for it to trigger a failure every time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 20:53:47 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 22 Apr 2012 18:53:47 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: <1332849673.66.0.0828799259938.issue14423@psf.upfronthosting.co.za> Message-ID: <1335120827.75.0.371192209927.issue14423@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Ok so now i only get errors for "_Fast" tests > am I correct in assuming that this is because i lack a C implementation? If your errors look like the one below, then yes. ====================================================================== ERROR: test_from_iso_week_value_week (test.datetimetester.TestDate_Fast) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/mdickinson/Python/cpython/Lib/test/datetimetester.py", line 1000, in test_from_iso_week_value_week self.assertRaises(ValueError, self.theclass.from_iso_week, year, AttributeError: type object 'datetime.date' has no attribute 'from_iso_week' ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 21:16:30 2012 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 22 Apr 2012 19:16:30 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> Message-ID: <1335122190.86.0.99243390963.issue14632@psf.upfronthosting.co.za> Vinay Sajip added the comment: John: Thanks for the updated patch. Charles-Fran?ois: Certainly I can reduce the iterations to make the test faster. As it is, I did reproduce the failure on my dev system, but only once, after running John's test script about a dozen times: every other time, it completed successfully :-( Isn't it simpler if I just replace the os.path.exists() calls with os.stat(), and check for ENOENT if an exception of type OSError or WindowsError occurs? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 21:19:12 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 22 Apr 2012 19:19:12 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335122352.46.0.942659194534.issue14605@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 21:37:53 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 22 Apr 2012 19:37:53 +0000 Subject: [issue14646] Require loaders set __loader__ and __package__ Message-ID: <1335123473.69.0.487132909443.issue14646@psf.upfronthosting.co.za> New submission from Brett Cannon : As discussed and agreed to on python-dev, it makes sense to require loaders to set __loader__ and __package__ so that they can be relied upon by globally executed code in a module. The following needs to happen to close this bug: * Update PEP 302 to say __loader__ is required, not optional * Update PEP 366 to say __package__ is required * Update PEP 302 to point to PEP 366 and mention the requirement * Update importlib.util.module_for_loader to set both __loader__ and __package__ * Update importlib.util.set_loader and importlib.util.set_package to point out that module_for_loader supercedes those decorators * Update importlib._bootstrap to set __loader__ when it is absent ---------- assignee: brett.cannon components: Interpreter Core messages: 158983 nosy: brett.cannon priority: release blocker severity: normal stage: test needed status: open title: Require loaders set __loader__ and __package__ type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 21:38:23 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 22 Apr 2012 19:38:23 +0000 Subject: [issue2377] Replace __import__ w/ importlib.__import__ In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za> Message-ID: <1335123503.29.0.859492389953.issue2377@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- dependencies: +Make import machinery explicit _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 21:51:09 2012 From: report at bugs.python.org (=?utf-8?q?Michael=2EElsd=C3=B6rfer?=) Date: Sun, 22 Apr 2012 19:51:09 +0000 Subject: [issue13857] Add textwrap.indent() as counterpart to textwrap.dedent() In-Reply-To: <1327462635.84.0.618726818638.issue13857@psf.upfronthosting.co.za> Message-ID: <1335124269.09.0.49392396178.issue13857@psf.upfronthosting.co.za> Changes by Michael.Elsd?rfer : ---------- nosy: +elsdoerfer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 21:51:49 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 22 Apr 2012 19:51:49 +0000 Subject: [issue14646] Require loaders set __loader__ and __package__ In-Reply-To: <1335123473.69.0.487132909443.issue14646@psf.upfronthosting.co.za> Message-ID: <1335124309.05.0.734739791051.issue14646@psf.upfronthosting.co.za> Eric Snow added the comment: Yeah, that patch for reload() in issue13959 relies on this. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 21:54:15 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 22 Apr 2012 19:54:15 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335124455.46.0.129229235506.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: First off, you should separate the patches for get_magic() and get_tag(). Second, why is there _get_pyc_magic_int() when it is never called? Third, all of this would be greatly simplified if you just had a _RAW_MAGIC_NUMBER of 3220, did the bytes object creation for _MAGIC_NUMBER in-place (i.e. no separate function), and then in the C code just got _RAW_MAGIC_NUMBER and did the MAGIC macro work there. As for what is CPython-specific and what isn't, only the other VMs can state that officially, so I'm not going to worry about that yet (but I will ask before Python 3.3 goes out so as to minimize backporting patches in the future). But importlib needs to stabilize more before that can happen. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 21:58:44 2012 From: report at bugs.python.org (Eric Snow) Date: Sun, 22 Apr 2012 19:58:44 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335124724.87.0.426608175563.issue13959@psf.upfronthosting.co.za> Eric Snow added the comment: Good feedback. The some of that code was the result of directly translating the C. I'll get a new, simpler patch up probably tomorrow night. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 22:16:20 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 22 Apr 2012 20:16:20 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: <1332849673.66.0.0828799259938.issue14423@psf.upfronthosting.co.za> Message-ID: <1335125780.82.0.117927999218.issue14423@psf.upfronthosting.co.za> Mark Dickinson added the comment: By the way, I don't think the algorithm used in the current patch is correct. For 'date.from_iso_week(2009, 1)' I get 2009/1/1, which was a Thursday. The documentation seems to indicate that a Monday should be returned. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 22:22:31 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 22 Apr 2012 20:22:31 +0000 Subject: [issue14643] Security page out of date In-Reply-To: <1335086892.52.0.709735016989.issue14643@psf.upfronthosting.co.za> Message-ID: <1335126151.86.0.258847900733.issue14643@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I fixed the 2.7.3 page. Hmm, I think the changes don't really help: the page now states that 2.7.2 is affected, but the reader doesn't know whether previous versions (at least on the 2.7 branch) were also affected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 22:23:57 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 22 Apr 2012 20:23:57 +0000 Subject: [issue14646] Require loaders set __loader__ and __package__ In-Reply-To: <1335123473.69.0.487132909443.issue14646@psf.upfronthosting.co.za> Message-ID: <1335126237.15.0.749143005597.issue14646@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 22:25:25 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 22 Apr 2012 20:25:25 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: <1335125780.82.0.117927999218.issue14423@psf.upfronthosting.co.za> Message-ID: <4F94692A.5080608@egenix.com> Marc-Andre Lemburg added the comment: Mark Dickinson wrote: > > By the way, I don't think the algorithm used in the current patch is correct. For 'date.from_iso_week(2009, 1)' I get 2009/1/1, which was a Thursday. The documentation seems to indicate that a Monday should be returned. True, the correct date is 2008-12-29. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 22 23:12:46 2012 From: report at bugs.python.org (=?utf-8?q?Esben_Agerb=C3=A6k_Black?=) Date: Sun, 22 Apr 2012 21:12:46 +0000 Subject: [issue14423] Getting the starting date of iso week from a week number and a year. In-Reply-To: <1332849673.66.0.0828799259938.issue14423@psf.upfronthosting.co.za> Message-ID: <1335129166.32.0.601954187503.issue14423@psf.upfronthosting.co.za> Esben Agerb?k Black added the comment: I somehow re-uploaded an old patch, this one contains buggy c-code, but fixes the python implementation. Any pointers to how to get started on the c bi would be greatly appreciated. ---------- Added file: http://bugs.python.org/file25306/isodates.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 00:25:34 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 22 Apr 2012 22:25:34 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: <1335133534.42.0.514534615379.issue14642@psf.upfronthosting.co.za> Martin v. L?wis added the comment: My point is: ISTM that everything is already as it should be, I can see no problem in the status quo. If there is a problem, can you please rephrase it? If you want a shell script just to have one, here is one #!/bin/sh make Python/importlib.h ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 00:46:37 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 22 Apr 2012 22:46:37 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: <1335134797.56.0.938158206564.issue14642@psf.upfronthosting.co.za> Brett Cannon added the comment: No, I don't want a shell script just to have one. =) The status quo seems to work, but people like Georg think it's partially luck that it does and if hg changes its semantics that will cause us trouble. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 01:17:57 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 22 Apr 2012 23:17:57 +0000 Subject: [issue14647] imp.reload() on a package leads to a GC assertion failure Message-ID: <1335136677.5.0.49699953472.issue14647@psf.upfronthosting.co.za> New submission from Brett Cannon : > ./python.exe -c "import urllib.parse as x; import imp; imp.reload(x)" Assertion failed: (gc->gc.gc_refs != 0), function visit_decref, file Modules/gcmodule.c, line 327. zsh: abort ./python.exe -c "import urllib.parse as x; import imp; imp.reload(x)" I even triggered a segfault that I can't reproduce. ---------- components: Library (Lib) messages: 158993 nosy: brett.cannon priority: release blocker severity: normal stage: test needed status: open title: imp.reload() on a package leads to a GC assertion failure versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 01:21:14 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 22 Apr 2012 23:21:14 +0000 Subject: [issue14647] imp.reload() on a package leads to a segfault or a GC assertion failure In-Reply-To: <1335136677.5.0.49699953472.issue14647@psf.upfronthosting.co.za> Message-ID: <1335136874.58.0.377230162712.issue14647@psf.upfronthosting.co.za> Brett Cannon added the comment: Segfault: > ./python.exe -c "import importlib.abc as x; import imp; imp.reload(x)" Traceback (most recent call last): File "", line 1, in File "", line 611, in load_module File "", line 271, in module_for_loader_wrapper File "", line 499, in _load_module File "/Users/bcannon/Developer/repo/cpython/py3k/Lib/importlib/abc.py", line 2, in from . import _bootstrap ImportError: cannot import name _bootstrap zsh: segmentation fault ./python.exe -c "import importlib.abc as x; import imp; imp.reload(x)" ---------- title: imp.reload() on a package leads to a GC assertion failure -> imp.reload() on a package leads to a segfault or a GC assertion failure type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 02:53:26 2012 From: report at bugs.python.org (Eric Snow) Date: Mon, 23 Apr 2012 00:53:26 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335142406.22.0.427866596386.issue13959@psf.upfronthosting.co.za> Eric Snow added the comment: How consistent do the semantics of reload() need to remain? (The C version does more type checking than the Python version probably needs to worry about. reload() seems to be one of those bits that doesn't have much test coverage.) Also, what's the best way to exercise the changes one makes to the C code? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 03:41:25 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 23 Apr 2012 01:41:25 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335145285.35.0.643217064969.issue14605@psf.upfronthosting.co.za> Brett Cannon added the comment: Attached is my (failing) attempt at making import explicit. Unfortunately I have four failing tests, 3 of which revolve around __main__ (which is why I added Nick to see if he had any ideas): test_cmd_line_script test_runpy test_threaded_import test_zipimport_support ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 03:41:56 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 23 Apr 2012 01:41:56 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335145316.73.0.239664691046.issue14605@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- keywords: +patch Added file: http://bugs.python.org/file25307/explicit.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 03:42:09 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 23 Apr 2012 01:42:09 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335145329.7.0.691375746643.issue14605@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 03:43:07 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Apr 2012 01:43:07 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 1da623513b26 by Brett Cannon in branch 'default': Issue #14605: Expose importlib.abc.FileLoader and http://hg.python.org/cpython/rev/1da623513b26 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 04:42:28 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 23 Apr 2012 02:42:28 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335148948.61.0.98004020614.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: Loosening the type restrictions is fine. As for testing, that's what the test suite is supposed to do. So if need be just write tests in Python that exercise the C code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 06:22:37 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 23 Apr 2012 04:22:37 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335154957.07.0.833297266301.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: To try and narrow down the issue, I now have separate patches for an explicit sys.meta_path and a sys.path_hooks. Both fail on tests, but for different reasons. The explicit sys.meta_path is still failing on the __main__ issue on three of the tests and for threaded imports on the other. The explicit sys.path_hooks patch fails on two tests: one on threading and then test_cmd_line_script on apparently lacking an absolute file path thanks to issue #8202 (and why an explicit sys.path_hooks triggers that I don't know). Both failures Nick might know about. ---------- Added file: http://bugs.python.org/file25308/explicit_meta_path.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 06:23:02 2012 From: report at bugs.python.org (Brett Cannon) Date: Mon, 23 Apr 2012 04:23:02 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335154982.18.0.0371914617903.issue13959@psf.upfronthosting.co.za> Changes by Brett Cannon : Added file: http://bugs.python.org/file25309/explicit_path_hooks.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 07:52:53 2012 From: report at bugs.python.org (Hobs) Date: Mon, 23 Apr 2012 05:52:53 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335160373.35.0.0681250805861.issue3177@psf.upfronthosting.co.za> Hobs added the comment: @eric.araujo, @giampaolo.rodola, (http://bugs.python.org/issue3177#msg140275) I'm not sure I understand why this was moved to shutil.open. It seems appropriate to try to accomplish what os.startfile() does in a cross-platform way. Don't many of the other os.* calls do this--check os.name and then "do the right thing". This is the first os.* call I've found that doesn't work on linux (though I'm sure there are many others). Is the reason because the name 'startfile' is a Windows creation and sounds Windowsy? If so, shouldn't os.startfile() be renamed to something generic like os.launch() or .launchfile()? But then you'd have reverse-compatibility issues. Why not just enhance os.startfile() so it doesn't barf if you try to use it on posix/mac? I'll try to contribute to the shutil.open() effort too. ---------- nosy: +Hobson.Lane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 09:37:29 2012 From: report at bugs.python.org (Stefano Taschini) Date: Mon, 23 Apr 2012 07:37:29 +0000 Subject: [issue1065986] Fix pydoc crashing on unicode strings Message-ID: <1335166649.97.0.398064218667.issue1065986@psf.upfronthosting.co.za> Changes by Stefano Taschini : ---------- nosy: +taschini _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 10:04:32 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 23 Apr 2012 08:04:32 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335168272.94.0.452281761174.issue3177@psf.upfronthosting.co.za> Chris Rebert added the comment: Here's a quick stab at 2/3rds of an implementation, and some docs. ---------- Added file: http://bugs.python.org/file25310/shutil_open.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 10:28:37 2012 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 23 Apr 2012 08:28:37 +0000 Subject: [issue14644] test_logging failure on OS X Tiger In-Reply-To: <1335097784.55.0.606093462856.issue14644@psf.upfronthosting.co.za> Message-ID: <1335169717.73.0.887215590599.issue14644@psf.upfronthosting.co.za> Vinay Sajip added the comment: I've increased the SMTPHandler timeouts and the tests now seem to be passing, so I'll close this now. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 10:41:24 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 23 Apr 2012 08:41:24 +0000 Subject: [issue14616] subprocess docs should mention pipes.quote/shlex.quote In-Reply-To: <1334769157.78.0.557014485739.issue14616@psf.upfronthosting.co.za> Message-ID: <1335170484.03.0.563285757173.issue14616@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 11:24:01 2012 From: report at bugs.python.org (Robert Elsner) Date: Mon, 23 Apr 2012 09:24:01 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334944587.74.0.953878168402.issue14596@psf.upfronthosting.co.za> Message-ID: <4F951FAC.5010609@googlemail.com> Robert Elsner added the comment: Well then at least the docs need an update. I simply fail to see how a cache memory leak constitutes "just fine" (while the caching behavior of struct.unpack is not documented - if somebody wants caching, he ought to use struct.Struct.unpack which does cache and does not leak). Something like a warning: "struct.unpack might display memory leaks when parsing big files using large format strings" might be sufficient. I do not like the idea of code failing outside some not-documented "use-case". Especially as those problems usually indicate some underlying design flaw. I did not review the proposed patch but might find time to have a look in a few months. cheers Am 20.04.2012 19:56, schrieb Mark Dickinson: > > Mark Dickinson added the comment: > > IMO, the struct module does what it's intended to do just fine here. I don't a big need for any change. I'd propose closing this as "won't fix". > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 12:29:21 2012 From: report at bugs.python.org (Hobs) Date: Mon, 23 Apr 2012 10:29:21 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335176961.7.0.980631890875.issue3177@psf.upfronthosting.co.za> Hobs added the comment: Test passes on Ubuntu Oneiric Linux and 'open' action appropriately defaults to launching an editor for my particular OS settings. Tests on Windows in work. ---------- Added file: http://bugs.python.org/file25311/shutil_launch.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 12:39:45 2012 From: report at bugs.python.org (Hobs) Date: Mon, 23 Apr 2012 10:39:45 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335177585.75.0.958021846979.issue3177@psf.upfronthosting.co.za> Hobs added the comment: Implement shutil.launch() & fix minor shutil.disk_usage() doctext typo Name changed from shutil.open to shutil.launch due to namespace conflict with open() builtin within the shutil module and for users that do from shutil import * On Ubuntu Oneiric Linux shutil.launch() doctest passes and `./python -m test -j3` doesn't change (OS-appropriate tests all pass). Windows tests in work. Need Mac testing too. ---------- Added file: http://bugs.python.org/file25312/shutil_open.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 13:30:44 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 23 Apr 2012 11:30:44 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335180644.92.0.143667984069.issue3177@psf.upfronthosting.co.za> Chris Rebert added the comment: > # or os.name == 'mac' ??? Nope, that refers to retro Mac OS 9 (and probably lower). Mac OS X is 'posix' for os.name purposes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 13:53:33 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 23 Apr 2012 11:53:33 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335182013.36.0.802943288691.issue3177@psf.upfronthosting.co.za> Chris Rebert added the comment: `operation` seems questionable. IMO, the verbs seem stronger / more important than mere optional suggestions (particularly "open" vs. "edit" for files with read-only viewers), and only Windows supports them (so anyone requiring that feature might as well just use startfile() directly). By virtue of this function being cross-platform, we're kinda limited to just supporting the lowest common denominator. Hobs, can you explain `gui`? Also, does startfile() raise exceptions for either of the basic error conditions ("no such file" and "no associated application")? If not, I believe using the lower-level ShellExecute (http://msdn.microsoft.com/en-us/library/windows/desktop/bb762153%28v=vs.85%29.aspx ) or similar Windows API function would allow us to report such errors, as the other platform implementations currently do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 14:20:53 2012 From: report at bugs.python.org (Ram Rachum) Date: Mon, 23 Apr 2012 12:20:53 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335183653.66.0.126831022576.issue3177@psf.upfronthosting.co.za> Changes by Ram Rachum : ---------- nosy: -cool-RR _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 14:25:44 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 12:25:44 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335183944.7.0.412065282472.issue3177@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 14:30:42 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 23 Apr 2012 12:30:42 +0000 Subject: [issue14616] subprocess docs should mention pipes.quote/shlex.quote In-Reply-To: <1334769157.78.0.557014485739.issue14616@psf.upfronthosting.co.za> Message-ID: <1335184242.14.0.701648706586.issue14616@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 14:34:35 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 12:34:35 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335184475.28.0.913005726595.issue3177@psf.upfronthosting.co.za> R. David Murray added the comment: Is the error raising PEP 3151 compliant? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 14:49:08 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 23 Apr 2012 12:49:08 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335185348.36.0.672444948294.issue3177@psf.upfronthosting.co.za> Chris Rebert added the comment: No, it isn't. Changing the `IOError(errno.ENOENT, "...`s to `FileNotFoundError("...`s would half fix it. The other half, the `OSError(errno.ENOSYS)`s, has a FIXME for what's the right error to raise in that case ("no application associated with files of this type"). I have no idea myself. None of the new PEP 3151 errors apply. Nor did any of the errnos strictly speaking AFAICT; ENOSYS was the closest approximation I could find. Thoughts? Custom error class? Different errno? Something else? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 14:54:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Apr 2012 12:54:40 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335185680.78.0.514754808977.issue3177@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > ENOSYS was the closest approximation I could find. Thoughts? Custom > error class? Different errno? Something else? Why not ValueError? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 14:58:48 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 12:58:48 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1335185928.48.0.065907621204.issue14596@psf.upfronthosting.co.za> R. David Murray added the comment: Other of our functions that do caching have been fixed so that the cache does not grow unbounded (usually by using lrucache, I think). IMO a cache that is unbounded by default is a bug. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 15:00:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Apr 2012 13:00:19 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1335186019.06.0.902675487884.issue14596@psf.upfronthosting.co.za> Antoine Pitrou added the comment: AFAIU, it's not unbounded, but it's the memory footprint of individual cached objects which can grow senseless. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 15:05:09 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 13:05:09 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1335186309.63.0.985971403159.issue14596@psf.upfronthosting.co.za> R. David Murray added the comment: If that is the case, then a doc footnote that a large repeat count will result in a large cache seems appropriate. Some way to control the max size of the cache would also be a reasonable enhancement request, at which point the cache size issue could be documented along with the cache control. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 15:18:07 2012 From: report at bugs.python.org (Dmitry Dvoinikov) Date: Mon, 23 Apr 2012 13:18:07 +0000 Subject: [issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..." Message-ID: <1335187087.5.0.315362932474.issue14648@psf.upfronthosting.co.za> New submission from Dmitry Dvoinikov : Using Python 3.3.0a2 (default, Apr 1 2012, 19:34:58) [MSC v.1500 64 bit (AMD64)] on win32. This line of code "{0:s}{1:s}".format("ABC", "\u0410\u0411\u0412") results in SystemError: Cannot copy UCS2 characters into a string of ascii characters ---------- components: Interpreter Core messages: 159014 nosy: ddvoinikov priority: normal severity: normal status: open title: Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..." type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 15:45:08 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 13:45:08 +0000 Subject: [issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..." In-Reply-To: <1335187087.5.0.315362932474.issue14648@psf.upfronthosting.co.za> Message-ID: <1335188708.97.0.140811332304.issue14648@psf.upfronthosting.co.za> R. David Murray added the comment: I get this result on a debug build of default on linux: >>> "{0:s}{1:s}".format("ABC", "\u0410\u0411\u0412") python: Objects/unicodeobject.c:1223: _copy_characters: Assertion `ch <= to_maxchar' failed. ---------- nosy: +haypo, loewis, r.david.murray priority: normal -> release blocker stage: -> needs patch type: behavior -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 15:48:35 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 23 Apr 2012 13:48:35 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1335188915.33.0.553396866075.issue1521950@psf.upfronthosting.co.za> ?ric Araujo added the comment: > I'd like to take a look at this (I wasn't aware of it before). Are you interested in shlex in general or only this bug? If the former, then I?ll try to remember to make you nosy on future issues. BTW, what is the shlex unicode bug you mentioned a few times on Rietveld? The one I know is fixed now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 15:50:26 2012 From: report at bugs.python.org (Mark Shannon) Date: Mon, 23 Apr 2012 13:50:26 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1335189026.71.0.327757883638.issue13903@psf.upfronthosting.co.za> Changes by Mark Shannon : Added file: http://bugs.python.org/file25313/73423916a242.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 15:58:39 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 23 Apr 2012 13:58:39 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335189519.14.0.0959687899532.issue3177@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for relaunching this! > I'm not sure I understand why this was moved to shutil.open. It seems appropriate to try to accomplish what > os.startfile() does in a cross-platform way. Don't many of the other os.* calls do this--check os.name and > then "do the right thing". They don?t. The os module is a thin wrapper on top of system functions. Cross-platform compat is not achieved with os.name checks but with platform-specific code in the C files. As Windows provides a call named startfile, it is exposed. When we want to provide a higher-level API on top of system calls, we use other modules such as shutil. > fix minor shutil.disk_usage() doctext typo Would you report this on another bug report or simply with a mail to the docs at python.org mailing list? Thanks. > Name changed from shutil.open to shutil.launch due to namespace conflict with open() builtin within the shutil > module and for users that do from shutil import * I don?t think these are good arguments. A lot of modules expose a function named open: tarfile, codecs, tokenize... Python has namespaces, let?s use them. The argument about import * is not strong either in my opinion, because all our docs recommend against this idiom. One argument against open is that the other open functions I mention above return a file object, like the builtin open. With this in mind I agree that a better name should be found. I dislike launch though because it brings to my mind the idea of running/executing a program, not opening it in the appropriate program. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 15:59:48 2012 From: report at bugs.python.org (Mark Shannon) Date: Mon, 23 Apr 2012 13:59:48 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1335189588.48.0.161523148564.issue13903@psf.upfronthosting.co.za> Mark Shannon added the comment: I've updated the repository and uploaded a new patch in response to Benjamin's review. (And the contributor form is in the post). One remaining issue is the return value of __sizeof__(). If it is an int, then it cannot accurately reflect the memory use, but returning a float may seem rather surprising. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 16:04:37 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 14:04:37 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1335189877.1.0.15067244642.issue1521950@psf.upfronthosting.co.za> R. David Murray added the comment: I am interested in shell stuff in general. The unicode bug is issue 1170. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 16:12:58 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 14:12:58 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335190378.05.0.111417830624.issue3177@psf.upfronthosting.co.za> R. David Murray added the comment: Launch is far better than open for this, I think. If someone can come up with an even better name, that would be good. But I would not like to use open for this function, because it does not behave like other open functions. The one exception I know of is webbrowser. Webbrowser uses open, but the recommended way to call it is webbrowser.open(), which makes it clear you are opening it in the webbrowser (and opening the webbrowser if needed). shutil.open would convey no such connotation, to my mind. (Only windows does extension based application opening from the *shell* as far as I know.) Perhaps 'wmopen' (for Window Manager Open)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 16:42:07 2012 From: report at bugs.python.org (Gunnar Eikman) Date: Mon, 23 Apr 2012 14:42:07 +0000 Subject: [issue10942] xml.etree.ElementTree.tostring returns type bytes, expected type str In-Reply-To: <1295395949.96.0.0409847573272.issue10942@psf.upfronthosting.co.za> Message-ID: <1335192127.32.0.976609832348.issue10942@psf.upfronthosting.co.za> Gunnar Eikman added the comment: I moved a working script from Ubuntu (Python 3.1.2) to Windows (Python 3.2.3) today. Had to revise script. The tostring method returns a string on Linux (contradicts this issue), but bytes on Windows (as described in this issue)... I used tostring with a single argument "tostring(theXml)" Is there an explanation for this? I am not an advanced Python hacker... Be careful when moving from one environment to another! ---------- nosy: +Gunnar.Eikman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 16:54:21 2012 From: report at bugs.python.org (Chris Jerdonek) Date: Mon, 23 Apr 2012 14:54:21 +0000 Subject: [issue14649] doctest.DocTestSuite error misleading when module has no docstrings Message-ID: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za> New submission from Chris Jerdonek : When invoking doctest.DocTestSuite's constructor with a module that has no docstrings, doctest raises the following exception: ... File "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/doctest.py", line 2280, in DocTestSuite raise ValueError(module, "has no tests") ValueError: (, 'has no tests') The error message is misleading because the exception is not raised for modules that have docstrings but no doctests, only for modules that have no docstrings. To be accurate, the message should be something like 'has no docstrings'. ---------- components: Library (Lib) messages: 159022 nosy: cjerdonek priority: normal severity: normal status: open title: doctest.DocTestSuite error misleading when module has no docstrings type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 16:55:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Apr 2012 14:55:37 +0000 Subject: [issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..." In-Reply-To: <1335187087.5.0.315362932474.issue14648@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset c7163a7f7cd2 by Benjamin Peterson in branch 'default': inherit maxchar of field value where needed (closes #14648) http://hg.python.org/cpython/rev/c7163a7f7cd2 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 16:59:56 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 14:59:56 +0000 Subject: [issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..." In-Reply-To: <1335187087.5.0.315362932474.issue14648@psf.upfronthosting.co.za> Message-ID: <1335193196.09.0.00611968817932.issue14648@psf.upfronthosting.co.za> R. David Murray added the comment: A test needs to be added for this. ---------- keywords: +easy priority: release blocker -> normal stage: committed/rejected -> test needed status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 17:04:09 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 23 Apr 2012 15:04:09 +0000 Subject: [issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..." In-Reply-To: <1335187087.5.0.315362932474.issue14648@psf.upfronthosting.co.za> Message-ID: <1335193449.77.0.651747326976.issue14648@psf.upfronthosting.co.za> Benjamin Peterson added the comment: What makes you think there isn't one? ---------- nosy: +benjamin.peterson status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 17:22:19 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Apr 2012 15:22:19 +0000 Subject: [issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..." In-Reply-To: Message-ID: STINNER Victor added the comment: > New changeset c7163a7f7cd2 by Benjamin Peterson in branch 'default': > inherit maxchar of field value where needed (closes #14648) > http://hg.python.org/cpython/rev/c7163a7f7cd2 The patch is wrong if the format only gets a substring instead of the full string. I have a pending patch for this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 17:23:20 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 23 Apr 2012 15:23:20 +0000 Subject: [issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..." In-Reply-To: <1335187087.5.0.315362932474.issue14648@psf.upfronthosting.co.za> Message-ID: <1335194600.19.0.574831101058.issue14648@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Ah, you are right. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 17:24:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Apr 2012 15:24:58 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 6e5855854a2e by Benjamin Peterson in branch 'default': Implement PEP 412: Key-sharing dictionaries (closes #13903) http://hg.python.org/cpython/rev/6e5855854a2e ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 17:25:01 2012 From: report at bugs.python.org (Hobs) Date: Mon, 23 Apr 2012 15:25:01 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1335190378.05.0.111417830624.issue3177@psf.upfronthosting.co.za> Message-ID: Hobs added the comment: Does no one like "os.startfile" as a home for this? Besides myself and the original 2008 proposer, of course. Can anyone explain to us newbies why it's a bad idea to have the cross-platform module do things identically across platforms? @David, `shutils.wmopen` locks you into never implementing the shell application launching option (`gui`=False in my crude implementation) that so many projects need. Each project currently implements it in their own nonstandard way (e.g. Mercurial and Bazaar), sometimes with not so `nice` consequences. You're right that only launching from Linux/Mac shell requires manual selection of an app, but that's exactly the inconvenience that I was hoping to solve. Many Ubuntu GUI apps use extensions and MIME-types (associated with extensions) to recognize their files rather than probing magic headers. Why shouldn't their shell apps be allowed a standard way to do the same? If I implemented *exactly* os.startfile() functionality across the 3 major platforms, would that be enough to interest the community in an os.startfile() refinement rather than a new shutils.launch()? I'd drop the distracting `gui` option to make it completely identical, if that helps. Or, if the community preferred I could *add* the `gui` option to startfile() across the board so that even Windows users could have the option of choosing to edit a file within their shell (if they've installed such an editor, of course). @Chris, Thanks for the tip on where to find low level exception information in Windows. Sounds like a good idea to try to be as identical to os.startfile() as possible. But that's why I thought the `operation` option would be attractive to the community. I'll test on windows (unless someone else chimes in with Windows experience) and see what I can learn about exceptions and what it would take to make os.startfile() truly OS-agnostic, all the way down to each exception raised. `gui` allows the user to chose to launch a shell-based text editor (emacs, vi/vim, nano, $EDITOR, based on user settings). It standardizes what bzr, hg and other popular cross-platform python projects that launch shell editors do already. On Mon, Apr 23, 2012 at 10:12 PM, R. David Murray wrote: > > R. David Murray added the comment: > > Launch is far better than open for this, I think. If someone can come up > with an even better name, that would be good. But I would not like to use > open for this function, because it does not behave like other open > functions. > > The one exception I know of is webbrowser. Webbrowser uses open, but the > recommended way to call it is webbrowser.open(), which makes it clear you > are opening it in the webbrowser (and opening the webbrowser if needed). > shutil.open would convey no such connotation, to my mind. (Only windows > does extension based application opening from the *shell* as far as I know.) > > Perhaps 'wmopen' (for Window Manager Open)? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 17:26:40 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 23 Apr 2012 15:26:40 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335194800.72.0.456003330779.issue3177@psf.upfronthosting.co.za> ?ric Araujo added the comment: Please trust us that this is our policy. os is a thin wrapper only. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 17:28:03 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 23 Apr 2012 15:28:03 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1335194883.85.0.743844141678.issue13903@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Okay. I committed the latest patch. Subtleties like __sizeof__ can be worked out as people start using it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 17:40:57 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 23 Apr 2012 15:40:57 +0000 Subject: [issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..." In-Reply-To: <1335187087.5.0.315362932474.issue14648@psf.upfronthosting.co.za> Message-ID: <1335195657.57.0.7968872722.issue14648@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 17:41:32 2012 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 23 Apr 2012 15:41:32 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1335195692.24.0.35056346911.issue13903@psf.upfronthosting.co.za> Yury Selivanov added the comment: Mark, did you add the test that your patch initially was failing with? http://mail.python.org/pipermail/python-dev/2012-February/116605.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 17:47:14 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 15:47:14 +0000 Subject: [issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..." In-Reply-To: <1335187087.5.0.315362932474.issue14648@psf.upfronthosting.co.za> Message-ID: <1335196034.85.0.867927361207.issue14648@psf.upfronthosting.co.za> R. David Murray added the comment: > What makes you think there isn't one? Poor eyesight? Sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 17:52:09 2012 From: report at bugs.python.org (Hobs) Date: Mon, 23 Apr 2012 15:52:09 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1335189519.14.0.0959687899532.issue3177@psf.upfronthosting.co.za> Message-ID: Hobs added the comment: @?ric Thanks for clearing up my misunderstanding of os and shutil. I get it now. I'm sure you know this, and it's clear you agree with changing the name, but just to add fire to your resolve, the difference between shutil.open() and the other `*.open()` modules you mention is that most of the others began their life with `open()` in their namespace (I think). A new `open()` in shutil, this late in its life, would break a *lot* of old code, sometimes invisibly. Apps might launch invisibly on servers with X-windows configured to display remotely, fail to raise exceptions, and leave a lot of admins dumbfounded and cursing the python standard library migration. Seems like pretty draconian punishment for bad (but not forbidden or deprecated) idioms. I'd rather not have my code be one of the rocks in that stoning. A few would surely fly my way. On Mon, Apr 23, 2012 at 9:58 PM, ?ric Araujo wrote: > > ?ric Araujo added the comment: > > Thanks for relaunching this! > > > I'm not sure I understand why this was moved to shutil.open. It seems > appropriate to try to accomplish what > > os.startfile() does in a cross-platform way. Don't many of the other > os.* calls do this--check os.name and > > then "do the right thing". > They don?t. The os module is a thin wrapper on top of system functions. > Cross-platform compat is not achieved with os.name checks but with > platform-specific code in the C files. As Windows provides a call named > startfile, it is exposed. When we want to provide a higher-level API on > top of system calls, we use other modules such as shutil. > > > fix minor shutil.disk_usage() doctext typo > Would you report this on another bug report or simply with a mail to the > docs at python.org mailing list? Thanks. > > > Name changed from shutil.open to shutil.launch due to namespace conflict > with open() builtin within the shutil > > module and for users that do from shutil import * > I don?t think these are good arguments. A lot of modules expose a > function named open: tarfile, codecs, tokenize... Python has namespaces, > let?s use them. The argument about import * is not strong either in my > opinion, because all our docs recommend against this idiom. > > One argument against open is that the other open functions I mention above > return a file object, like the builtin open. With this in mind I agree > that a better name should be found. I dislike launch though because it > brings to my mind the idea of running/executing a program, not opening it > in the appropriate program. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 17:54:28 2012 From: report at bugs.python.org (Hobs) Date: Mon, 23 Apr 2012 15:54:28 +0000 Subject: [issue14650] 1-character typo in shutils doctext Message-ID: <1335196468.35.0.0445432965745.issue14650@psf.upfronthosting.co.za> New submission from Hobs : This patch fixes a 1-character typo in the docstring for shutil.disk_usage(). ---------- assignee: docs at python components: Documentation files: shutil_disk_usage_doc.patch keywords: patch messages: 159035 nosy: Hobson.Lane, docs at python, eric.araujo priority: normal severity: normal status: open title: 1-character typo in shutils doctext type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25314/shutil_disk_usage_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 17:57:06 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Apr 2012 15:57:06 +0000 Subject: [issue13684] httplib tunnel infinite loop In-Reply-To: <1325260587.05.0.642107056326.issue13684@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 790ae45b52be by Senthil Kumaran in branch '2.7': Fix for Issue13684 - httplib tunnel infinite loop http://hg.python.org/cpython/rev/790ae45b52be New changeset 7787a9aebdc6 by Senthil Kumaran in branch '3.2': 3.2 - Fix for Issue13684 - httplib tunnel infinite loop http://hg.python.org/cpython/rev/7787a9aebdc6 New changeset f98fb46ff273 by Senthil Kumaran in branch '2.7': news for issue13684 http://hg.python.org/cpython/rev/f98fb46ff273 New changeset 26631c56d81f by Senthil Kumaran in branch '3.2': news for issue13684 http://hg.python.org/cpython/rev/26631c56d81f New changeset 1acb252a3858 by Senthil Kumaran in branch 'default': 3.2 - Fix for Issue13684 - httplib tunnel infinite loop http://hg.python.org/cpython/rev/1acb252a3858 New changeset 246abd64e830 by Senthil Kumaran in branch 'default': news for issue13684 http://hg.python.org/cpython/rev/246abd64e830 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 18:09:46 2012 From: report at bugs.python.org (Hobs) Date: Mon, 23 Apr 2012 16:09:46 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335197386.34.0.912246135757.issue3177@psf.upfronthosting.co.za> Hobs added the comment: New patch incorporates improvements from pitrou, cvrebert, r.david.murray, eric.araujo, cool-RR ---------- Added file: http://bugs.python.org/file25315/shutil_open.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 18:12:39 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 16:12:39 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335197559.82.0.0453968805953.issue3177@psf.upfronthosting.co.za> R. David Murray added the comment: Initially this issue was about implementing a startfile-equivalent on posix. But if you have to add a gui option to startfile to not lanuch a GUI, and your real goal is a consistent way to launch non-gui programs on posix, then I don't see that this is about implementing startfile, and the enhancement should *definitely* not go in os. Setting that aside for a moment, let me say something about the wrapper argument. There *is* a lot of compatibility code in os. We do have to jump through hoops to get posix equivalent functionality on Windows. So doing the reverse to get windows-equivalent functionality on posix would seem fair turnabout. However, it is also true that those hoops we jump through for windows involve calling Windows APIs (the equivalent of the posix system calls we are wrapping). So while the hoops aren't necessarily all that "thin", they are wrappers around APIs at the OS level (thus the name of the module). In this case the hoops are not system calls. So even disregarding my initial comments above, while I don't think the argument is quite as clear cut as ?ric does, I do think in this case the code, which is *not* operating at the C API level, does not belong in OS. Finally, I'm still against shutil.open as the name. It does not suggest to me that an application is being run. (Neither does 'startfile', by the way). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 18:15:24 2012 From: report at bugs.python.org (Sven Marnach) Date: Mon, 23 Apr 2012 16:15:24 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335197724.43.0.996683581038.issue3177@psf.upfronthosting.co.za> Sven Marnach added the comment: The semantics of "associated application" change considerably from operating system to operating system. As an example, ``os.startfile("a.py")`` will usually run `a.py` in the Python interpreter, while ``xdg-open a.py`` it will usually open the source code in an editor on Linux. This might reduce the overall usefulness of the proposed ``shutil.launch()`` function. ---------- nosy: +smarnach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 18:19:44 2012 From: report at bugs.python.org (Takayuki SHIMIZUKAWA) Date: Mon, 23 Apr 2012 16:19:44 +0000 Subject: [issue14651] `pysetup run [cmd]` can't handle option values in the setup.cfg Message-ID: <1335197984.07.0.198109730361.issue14651@psf.upfronthosting.co.za> New submission from Takayuki SHIMIZUKAWA : `pysetup run [cmd]` can't handle option values in the setup.cfg setup.cfg:: [sdist] formats = gztar dist-dir = _dist run on windows:: C:> pysetup run sdist That command generate `dist/package-version.zip` instead of `_dist/packcage-version.tar.gz`. attached patch will fix it. ---------- assignee: eric.araujo components: Distutils2 files: use-setupcfg-options-r13146.patch keywords: patch messages: 159040 nosy: alexis, eric.araujo, shimizukawa, tarek priority: normal severity: normal status: open title: `pysetup run [cmd]` can't handle option values in the setup.cfg type: behavior versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file25316/use-setupcfg-options-r13146.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 18:24:59 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 23 Apr 2012 16:24:59 +0000 Subject: [issue14650] 1-character typo in shutil docstring In-Reply-To: <1335196468.35.0.0445432965745.issue14650@psf.upfronthosting.co.za> Message-ID: <1335198299.4.0.256065457846.issue14650@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks. Can you check if the typo is also present in the documentation (i.e. in Doc/library)? ---------- title: 1-character typo in shutils doctext -> 1-character typo in shutil docstring _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 18:27:02 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 23 Apr 2012 16:27:02 +0000 Subject: [issue14651] pysetup run cmd can't handle option values in the setup.cfg In-Reply-To: <1335197984.07.0.198109730361.issue14651@psf.upfronthosting.co.za> Message-ID: <1335198422.61.0.901522192013.issue14651@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the report. This is weird, given that the code for setting command options in setup.cfg directly comes from distutils and works there. I think that this error may come from another bug in pysetup (i.e. in distutils2.run) where the config file is parsed too late; I discovered that bug a week ago and did not find the time to apply the fix. I?ll keep you updated on this. ---------- title: `pysetup run [cmd]` can't handle option values in the setup.cfg -> pysetup run cmd can't handle option values in the setup.cfg versions: +3rd party, Python 3.3 -Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 18:30:10 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 23 Apr 2012 16:30:10 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335198610.17.0.449791242444.issue3177@psf.upfronthosting.co.za> ?ric Araujo added the comment: > The semantics of "associated application" change considerably from > operating system to operating system. As an example, > ``os.startfile("a.py")`` will usually run `a.py` in the Python > interpreter, while ``xdg-open a.py`` it will usually open the source > code in an editor on Linux. Outch. I think the behavior should be more similar than that, i.e. that the function should use startfile with the edit action on Windows. About the name: I thought about ?edit?; it really means open_file_in_editor. BTW shutil feels the wrong place for this but I don?t think we have anything better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 18:34:07 2012 From: report at bugs.python.org (Hobs) Date: Mon, 23 Apr 2012 16:34:07 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335198847.71.0.672115279423.issue3177@psf.upfronthosting.co.za> Hobs added the comment: Last patch was invalid and untested. New patch passes `make patchtest`, but still doing the full test suite on Windows and Linux. Still unsure if I raised the right exceptions with the right arguments. ---------- Added file: http://bugs.python.org/file25317/shutil_open.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 18:52:49 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 16:52:49 +0000 Subject: [issue14635] telnetlib uses select instead of poll - limited to FD_SETSIZE fds In-Reply-To: <1334949623.77.0.295518189269.issue14635@psf.upfronthosting.co.za> Message-ID: <1335199969.14.0.969267333891.issue14635@psf.upfronthosting.co.za> R. David Murray added the comment: ?ric: there are devices that still only allow telnet. Older cisco routers (*many* of which are still in the field) are just one example I'm familiar with. I don't currently have any tools that use telnetlib to talk to them, but I've got at least two I'd like to find time to write...and I can easily imagine this limitation coming up as a real issue at Google :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 19:05:36 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 23 Apr 2012 17:05:36 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1335122190.86.0.99243390963.issue14632@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Charles-Fran?ois: Certainly I can reduce the iterations to make the test > faster. As it is, I did reproduce the failure on my dev system, but only > once, after running John's test script about a dozen times: every other > time, it completed successfully :-( Juste reduce the sleep times, e.g.: """ @@ -17,7 +17,7 @@ os.unlink(fname) except OSError: pass - stime = 0.04 * random.randint(0, 4) + stime = 0.004 * random.randint(0, 4) time.sleep(stime) @@ -50,7 +50,7 @@ log.setLevel(logging.INFO) for ii in range(LOGCOUNT): - stime = 0.05 # * random.randint(0, 4) + stime = 0.005 # * random.randint(0, 4) time.sleep(stime) log.warning('Foo bar %d', ii) """ With this change, I can trigger a failure reliably in around 1s, and my computer is rather slow. > Isn't it simpler if I just replace the os.path.exists() calls with > os.stat(), and check for ENOENT if an exception of type OSError or > WindowsError occurs? The problem is that it would leave a race window if the file is changed between the time it's opened (I guess in logging.FileHandler.__init__()) and the first call to stat(). John's patch is safe in this regard, thanks to fstat(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 19:11:33 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 17:11:33 +0000 Subject: [issue14638] pydoc error on instance of a custom class In-Reply-To: <1334954723.85.0.214601064543.issue14638@psf.upfronthosting.co.za> Message-ID: <1335201093.33.0.331752938775.issue14638@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- assignee: -> r.david.murray nosy: +r.david.murray stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 19:27:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Apr 2012 17:27:52 +0000 Subject: [issue14638] pydoc error on instance of a custom class In-Reply-To: <1334954723.85.0.214601064543.issue14638@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2a35dfbe3d99 by R David Murray in branch '3.2': #14638: pydoc now treats non-str __name__ as None instead of raising http://hg.python.org/cpython/rev/2a35dfbe3d99 New changeset 86b4b54bb0fa by R David Murray in branch 'default': merge #14638: pydoc now treats non-str __name__ as None instead of raising http://hg.python.org/cpython/rev/86b4b54bb0fa New changeset 501651b93cb0 by R David Murray in branch '2.7': #14638: pydoc now treats non-str __name__ as None instead of raising http://hg.python.org/cpython/rev/501651b93cb0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 19:30:05 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 17:30:05 +0000 Subject: [issue14638] pydoc error on instance of a custom class In-Reply-To: <1334954723.85.0.214601064543.issue14638@psf.upfronthosting.co.za> Message-ID: <1335202205.16.0.84451040647.issue14638@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks Peter. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 19:34:34 2012 From: report at bugs.python.org (Mark Shannon) Date: Mon, 23 Apr 2012 17:34:34 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1335202474.49.0.633733672219.issue13903@psf.upfronthosting.co.za> Mark Shannon added the comment: I fixed it back then, but didn't add the test. It subsequently regressed. Should know better. Patch (with test this time) attached. ---------- resolution: fixed -> status: closed -> open Added file: http://bugs.python.org/file25318/str_subclass.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 19:34:49 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 23 Apr 2012 17:34:49 +0000 Subject: [issue10731] UnicodeDecodeError in OS X tkinter when binding to In-Reply-To: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za> Message-ID: <1335202489.68.0.632804120773.issue10731@psf.upfronthosting.co.za> Ned Deily added the comment: A potential fix has been generated for Tk. I'll close this issue once the fix has been verified with _tkinter. ---------- resolution: -> out of date stage: needs patch -> status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 19:35:05 2012 From: report at bugs.python.org (Hobs) Date: Mon, 23 Apr 2012 17:35:05 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335202505.08.0.779090262252.issue3177@psf.upfronthosting.co.za> Hobs added the comment: I'll be happy to code, test, and use the new ____.____() function wherever it ends up and whatever it is named... but... > Initially this issue was about implementing a startfile-equivalent on > posix. But if you have to add a gui option to startfile to not lanuch > a GUI, and your real goal is a consistent way to launch non-gui > programs on posix Actually, my real goal was a consistent way of launching any editor or viewer (or even interpreter) on any platform with graceful fallback from the caller's preferred action to the others. I wanted my application that called the new idiomatic standard library function to do something smarter (in my mind) than what OSes do by default and more consistent and robust than what hg and bzr do by design. Perhaps the fallback should only be within the read/write/execute "silos", but that should be configurable as well, defaulting to do the safe thing (fallback within editors or within viewers only). GUI viewer (IE, then Firefox, then Chrome, then Safari) GUI editor (notepad, then ...) shell editor ($EDITOR, then vim, then vi, then nano, etc) shell viewer (less, then more, then cat) Obviously this isn't feasible. At least not for my first patch. ---------- Added file: http://bugs.python.org/file25319/shutil_open.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 19:47:25 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Apr 2012 17:47:25 +0000 Subject: [issue14641] Minor fixes in sockets.rst In-Reply-To: <1335016157.05.0.701229655848.issue14641@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f24d8dc1a986 by Sandro Tosi in branch '2.7': Issue #14641: minor fixes to sockets Howto; patch by Dionysios Kalofonos http://hg.python.org/cpython/rev/f24d8dc1a986 New changeset 9bb9604519ce by Sandro Tosi in branch '3.2': Issue #14641: minor fixes to sockets Howto; patch by Dionysios Kalofonos http://hg.python.org/cpython/rev/9bb9604519ce New changeset caf39de79819 by Sandro Tosi in branch 'default': Issue #14641: merge with 3.2 http://hg.python.org/cpython/rev/caf39de79819 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 19:48:03 2012 From: report at bugs.python.org (=?utf-8?q?Sidney_San_Mart=C3=ADn?=) Date: Mon, 23 Apr 2012 17:48:03 +0000 Subject: [issue14652] Better error messages for wsgiref validator failures Message-ID: <1335203283.28.0.579235394721.issue14652@psf.upfronthosting.co.za> New submission from Sidney San Mart?n : wsgiref?s validation middleware is missing messages for many of its assertions, and its docstring doesn?t reflect read() now requiring an argument (said that it took an optional argument). Here?s a patch to add some and update the comment. ---------- components: Library (Lib) files: ssm_validate.patch keywords: patch messages: 159053 nosy: ssm priority: normal severity: normal status: open title: Better error messages for wsgiref validator failures type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25320/ssm_validate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 19:48:06 2012 From: report at bugs.python.org (Sandro Tosi) Date: Mon, 23 Apr 2012 17:48:06 +0000 Subject: [issue14641] Minor fixes in sockets.rst In-Reply-To: <1335016157.05.0.701229655848.issue14641@psf.upfronthosting.co.za> Message-ID: <1335203286.37.0.120935429001.issue14641@psf.upfronthosting.co.za> Sandro Tosi added the comment: Thanks for your contribution! ---------- nosy: +sandro.tosi resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 19:50:15 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Apr 2012 17:50:15 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 34b6998efd2c by Benjamin Peterson in branch 'default': fix instance dicts with str subclasses (#13903) http://hg.python.org/cpython/rev/34b6998efd2c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 19:53:02 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 23 Apr 2012 17:53:02 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335203582.89.0.830071281989.issue3177@psf.upfronthosting.co.za> Chris Rebert added the comment: >> ENOSYS was the closest approximation I could find. Thoughts? Custom >> error class? Different errno? Something else? > > Why not ValueError? Because the value they provided was perfectly valid (the file/directory *did* exist), so the caller's request was reasonable. It's the system(/ its (lack of) configuration) that failed the caller in finding an opener application. The "fix" after encountering the exception is to add an association to the system configuration (and/or install a new application), not to pass a different path to the function. IMO, it feels like an EnvironmentError or RuntimeError of some sort; hence the current use of OSError. (Or NotImplementedError, but we're already using that exception to indicate a different failure condition, so that's out.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 19:57:55 2012 From: report at bugs.python.org (Hobs) Date: Mon, 23 Apr 2012 17:57:55 +0000 Subject: [issue14650] 1-character typo in shutil docstring In-Reply-To: <1335196468.35.0.0445432965745.issue14650@psf.upfronthosting.co.za> Message-ID: <1335203875.28.0.0577401850184.issue14650@psf.upfronthosting.co.za> Hobs added the comment: Eric, the documentation (shutil.rst) looks fine. Just a code comment typo. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 19:58:18 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 23 Apr 2012 17:58:18 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335203898.27.0.025798663639.issue3177@psf.upfronthosting.co.za> Chris Rebert added the comment: Hobs, why is exit code 4 of xdg-open (which the manpage describes as the extremely generic "The action failed.") interpreted as FileNotFoundError in your new version? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 20:05:41 2012 From: report at bugs.python.org (Hobs) Date: Mon, 23 Apr 2012 18:05:41 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1335203898.27.0.025798663639.issue3177@psf.upfronthosting.co.za> Message-ID: Hobs added the comment: Because that's how I caused the exception in Ubuntu--shutil.launch('file_that_doesnt_exist'). That's why I changed the message to "file may not exist" for both 2 and 4, but should probably prove that 2 sometimes happens when the file does exist (like with permission or visiblity/hidden errors in some OSes). Interestingly I got it to quietly, insidiously fail on Ubuntu by passing it a path to an empty file named empty.exe with the executeable bit set (but permissions and executable bit didn't seem to make a difference). No app was launched (or too quickly disappeared for me to see) and shutil.launch() did not complain. On Tue, Apr 24, 2012 at 1:58 AM, Chris Rebert wrote: > > Chris Rebert added the comment: > > Hobs, why is exit code 4 of xdg-open (which the manpage describes as the > extremely generic "The action failed.") interpreted as FileNotFoundError in > your new version? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 20:08:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Apr 2012 18:08:50 +0000 Subject: [issue14650] 1-character typo in shutil docstring In-Reply-To: <1335196468.35.0.0445432965745.issue14650@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 629d4c2faa87 by Sandro Tosi in branch 'default': Issue #14650: fix typo in shutil.disk_usage() docstring; patch by Hobson Lane http://hg.python.org/cpython/rev/629d4c2faa87 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 20:09:35 2012 From: report at bugs.python.org (Sandro Tosi) Date: Mon, 23 Apr 2012 18:09:35 +0000 Subject: [issue14650] 1-character typo in shutil docstring In-Reply-To: <1335196468.35.0.0445432965745.issue14650@psf.upfronthosting.co.za> Message-ID: <1335204575.16.0.791337924171.issue14650@psf.upfronthosting.co.za> Sandro Tosi added the comment: Thanks for your contribution! ---------- nosy: +sandro.tosi resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 20:09:37 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 23 Apr 2012 18:09:37 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335204577.4.0.483347930926.issue3177@psf.upfronthosting.co.za> Chris Rebert added the comment: Also: The FileNotFoundErrors quote the path twice: Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53) >>> path = "/foo/bar" >>> print "Path '%s' may not exist" % repr(path) Path ''/foo/bar'' may not exist The ValueError error message isn't grammatically correct and doesn't account for the possibility that the path is a directory (consider the case of a Unix system where the GUI file manager has been uninstalled; directories would then fail to open). May I suggest my original message?: "No application is associated with files/directories of the given type" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 20:21:34 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 23 Apr 2012 18:21:34 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335205294.3.0.646383706382.issue3177@psf.upfronthosting.co.za> Chris Rebert added the comment: The xdg-open source code (http://cgit.freedesktop.org/xdg/xdg-utils/tree/scripts/xdg-open ) shows that exit code 4 is used whenever an invocation of another opener script (e.g. kde-open, gnome-open) fails for any reason besides said script not being installed. So I'm not so sure we can jump to the conclusion that 4 automatically means FileNotFound. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 20:33:03 2012 From: report at bugs.python.org (Hobs) Date: Mon, 23 Apr 2012 18:33:03 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1335204577.4.0.483347930926.issue3177@psf.upfronthosting.co.za> Message-ID: Hobs added the comment: Yea, I hosed up the path quoting in a misguided attempt at shortening for 80-col line-wrapping. Yours is better, will revert. On Tue, Apr 24, 2012 at 2:09 AM, Chris Rebert wrote: > > Chris Rebert added the comment: > > Also: > > The FileNotFoundErrors quote the path twice: > Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53) > >>> path = "/foo/bar" > >>> print "Path '%s' may not exist" % repr(path) > Path ''/foo/bar'' may not exist > > The ValueError error message isn't grammatically correct and doesn't > account for the possibility that the path is a directory (consider the case > of a Unix system where the GUI file manager has been uninstalled; > directories would then fail to open). May I suggest my original message?: > "No application is associated with files/directories of the given type" > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 20:45:39 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 23 Apr 2012 18:45:39 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335206739.56.0.492901035376.issue3177@psf.upfronthosting.co.za> Chris Rebert added the comment: >> The semantics of "associated application" change considerably from >> operating system to operating system. As an example, >> ``os.startfile("a.py")`` will usually run `a.py` in the Python >> interpreter, while ``xdg-open a.py`` it will usually open the source >> code in an editor on Linux. > > Outch. I think the behavior should be more similar than that, i.e. that the function should use startfile with the edit action on Windows. It's a universal problem on all 3 platforms. Given a script file argument, a generic "open" (as opposed to "edit") procedure will either run the script or open it in an editor, depending entirely upon the user's system configuration. Same thing happens when double-clicking a script in the file manager, which is IMO what we're trying to emulate here. It sounds like some people want a generic "(text) edit" procedure, which IMO is different enough to warrant a separate bug since there are different/more design issues to tackle (e.g. if someone edit()s an image file (or a file of uncertain type) on Unix, what application is opened, and how is that determined?). And no peeking at Mercurial's code; it's under GPLv2, whereas Python is under BSD/MIT-like licensing, making them incompatible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 20:47:17 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Apr 2012 18:47:17 +0000 Subject: [issue14640] Typos in pyporting.rst In-Reply-To: <1335001975.37.0.452902157881.issue14640@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f7b002e5cac7 by R David Murray in branch '3.2': #14640: Fix typos/syntax in pyporting.rst. http://hg.python.org/cpython/rev/f7b002e5cac7 New changeset 13c30fe3f427 by R David Murray in branch 'default': Merge #14640: Fix typos/syntax in pyporting.rst. http://hg.python.org/cpython/rev/13c30fe3f427 New changeset 758f5585ce52 by R David Murray in branch '2.7': #14640: Fix typos/syntax in pyporting.rst. http://hg.python.org/cpython/rev/758f5585ce52 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 20:48:31 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 18:48:31 +0000 Subject: [issue14640] Typos in pyporting.rst In-Reply-To: <1335001975.37.0.452902157881.issue14640@psf.upfronthosting.co.za> Message-ID: <1335206911.88.0.044552905181.issue14640@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Dionysios. ---------- nosy: +r.david.murray resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 21:37:02 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 19:37:02 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335209822.04.0.639614091885.issue3177@psf.upfronthosting.co.za> R. David Murray added the comment: I'm not a lawyer (duh), but my understanding is that *looking* at GPL code (as opposed to proprietary code, where someone might sue you about it and not looking is a good defense) is OK, you just can't copy it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 21:47:41 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Apr 2012 19:47:41 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1335209822.04.0.639614091885.issue3177@psf.upfronthosting.co.za> Message-ID: <1335210380.3411.6.camel@localhost.localdomain> Antoine Pitrou added the comment: > I'm not a lawyer (duh), but my understanding is that *looking* at GPL > code (as opposed to proprietary code, where someone might sue you > about it and not looking is a good defense) is OK, you just can't copy > it. You could probably copy a one- or two-liner, especially if it's not a very creative one. By that I mean that putting "i = i + 1" under the GPL is not enough to prevent anyone else to write the same line of code :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 22:02:55 2012 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 23 Apr 2012 20:02:55 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: Message-ID: <1335211374.15337.YahooMailNeo@web171306.mail.ir2.yahoo.com> Vinay Sajip added the comment: [snip] >With this change, I can trigger a failure reliably in around 1s, and >my computer is rather slow. I'm working in a VM, and although I can get John's script to fail more regularly (with the reduced timeouts and counts of 1000), a version of the test which I added to test_logging always succeeds. That code is: ?? ?@unittest.skipUnless(threading, 'Threading required for this test.') ?? ?def test_race(self): ?? ? ? ?# Issue #14632 refers. ?? ? ? ?def remove_loop(fname, tries): ?? ? ? ? ? ?for _ in range(tries): ?? ? ? ? ? ? ? ?try: ?? ? ? ? ? ? ? ? ? ?os.unlink(fname) ?? ? ? ? ? ? ? ?except OSError: ?? ? ? ? ? ? ? ? ? ?pass ?? ? ? ? ? ? ? ?time.sleep(0.004 * random.randint(0, 4)) ?? ? ? ?def cleanup(remover, fn, handler): ?? ? ? ? ? ?handler.close() ?? ? ? ? ? ?remover.join() ?? ? ? ? ? ?if os.path.exists(fn): ?? ? ? ? ? ? ? ?os.unlink(fn) ?? ? ? ?fd, fn = tempfile.mkstemp('.log', 'test_logging-3-') ?? ? ? ?os.close(fd) ?? ? ? ?del_count = 1000 ?? ? ? ?log_count = 1000 ?? ? ? ?remover = threading.Thread(target=remove_loop, args=(fn, del_count)) ?? ? ? ?remover.daemon = True ?? ? ? ?remover.start() ?? ? ? ?h = logging.handlers.WatchedFileHandler(fn) ?? ? ? ?self.addCleanup(cleanup, remover, fn, h) ?? ? ? ?f = logging.Formatter('%(asctime)s: %(levelname)s: %(message)s') ?? ? ? ?h.setFormatter(f) ?? ? ? ?for _ in range(log_count): ?? ? ? ? ? ?time.sleep(0.005) ?? ? ? ? ? ?r = logging.makeLogRecord({'msg': 'testing' }) ?? ? ? ? ? ?h.handle(r) I can't see why this always works, while John's script sometimes fails. >The problem is that it would leave a race window if the file is >changed between the time it's opened (I guess in >logging.FileHandler.__init__()) and the first call to stat(). >John's patch is safe in this regard, thanks to fstat(). Oh, right - missed that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 22:12:23 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 23 Apr 2012 20:12:23 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1335211943.02.0.294521555718.issue11618@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Any thougts? Is a 60% performance increase for the common case of acquiring an uncontested lock worth doing? Btw, for our console game I also opted for non-semaphore based locks in thread_pthread.h, because our console profilers were alarmed at all the kernel transitions caused by the GIL being ticked.... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 22:21:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Apr 2012 20:21:27 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1335212487.97.0.195419742459.issue11618@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Is a 60% performance increase for the common case of acquiring an > uncontested lock worth doing? Yes, I agree it is. However, the Vista-specific path seems uninteresting, if it's really 2% faster. > our console profilers were alarmed at all the kernel transitions caused > by the GIL being ticked.... That's the old GIL. The new GIL uses a fixed timeout with a condition variable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 22:29:20 2012 From: report at bugs.python.org (Raphael Cruzeiro) Date: Mon, 23 Apr 2012 20:29:20 +0000 Subject: [issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu In-Reply-To: <1334734810.54.0.87567518387.issue14610@psf.upfronthosting.co.za> Message-ID: <1335212960.55.0.151981646531.issue14610@psf.upfronthosting.co.za> Raphael Cruzeiro added the comment: Here is the output of sh -x ./configure ---------- Added file: http://bugs.python.org/file25321/output_sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 22:33:32 2012 From: report at bugs.python.org (Mitar) Date: Mon, 23 Apr 2012 20:33:32 +0000 Subject: [issue14653] Improve mktime_tz to use calendar.timegm instead of time.mktime Message-ID: <1335213212.56.0.724242644314.issue14653@psf.upfronthosting.co.za> New submission from Mitar : I would suggest improvement of mktime_tz to use calendar.timegm internally instead of time.mktime. The problem is that on Windows mktime_tz fails with "mktime argument out of range" for this code: mktime_tz(parsedate_tz('Thu, 1 Jan 1970 00:00:00 GMT')) if user is in GMT+X timezone. Obviously, "Thu, 1 Jan 1970 00:00:00 GMT" is not out of range. But because mktime_tz uses internally time.mktime which takes into the account local time (and local timezone) and then compensate for the timeline, out of range condition happens. I would suggest such implementation: def mktime_tz(data): """Turn a 10-tuple as returned by parsedate_tz() into a UTC timestamp.""" if data[9] is None: # No zone info, so localtime is better assumption than GMT return time.mktime(data[:8] + (-1,)) else: t = calendar.timegm(data[:8] + (0,)) return t - data[9] It does not raise and exception, and it is also much cleaner: directly using GMT function and not localtime with timezone compensation. ---------- components: Library (Lib) messages: 159074 nosy: mitar priority: normal severity: normal status: open title: Improve mktime_tz to use calendar.timegm instead of time.mktime type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 22:55:35 2012 From: report at bugs.python.org (Raphael Cruzeiro) Date: Mon, 23 Apr 2012 20:55:35 +0000 Subject: [issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu In-Reply-To: <1334734810.54.0.87567518387.issue14610@psf.upfronthosting.co.za> Message-ID: <1335214535.54.0.037053632097.issue14610@psf.upfronthosting.co.za> Raphael Cruzeiro added the comment: Posting the strac output ---------- Added file: http://bugs.python.org/file25322/strace.output.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 23:00:54 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Apr 2012 21:00:54 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1334954469.29.0.182446723784.issue14339@psf.upfronthosting.co.za> Message-ID: <1335208113.3101.0.camel@raxxla> Serhiy Storchaka added the comment: I can only do this tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 23:01:20 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Apr 2012 21:01:20 +0000 Subject: [issue14624] Faster utf-16 decoder In-Reply-To: <1334869141.17.0.802149162715.issue14624@psf.upfronthosting.co.za> Message-ID: <1335214143.3101.240.camel@raxxla> Serhiy Storchaka added the comment: Here are the results of benchmarking (numbers in MB/s). On 32-bit Linux, AMD Athlon 64 X2 4600+ @ 2.4GHz: Py2.7 Py3.2 Py3.3 patch utf-16le 'A'*10000 504 (+282%) 1905 (+1%) 565 (+241%) 1927 utf-16le '\x80'*10000 503 (+264%) 1894 (-3%) 417 (+340%) 1833 utf-16le '\x80'+'A'*9999 504 (+264%) 1890 (-3%) 422 (+335%) 1834 utf-16le '\u0100'*10000 503 (+249%) 1896 (-7%) 357 (+391%) 1754 utf-16le '\u0100'+'A'*9999 504 (+252%) 1896 (-6%) 360 (+393%) 1776 utf-16le '\u0100'+'\x80'*9999 503 (+249%) 1890 (-7%) 357 (+392%) 1756 utf-16le '\u8000'*10000 503 (-18%) 355 (+16%) 75 (+449%) 412 utf-16le '\u8000'+'A'*9999 504 (+254%) 1892 (-6%) 359 (+397%) 1783 utf-16le '\u8000'+'\x80'*9999 503 (+249%) 1896 (-7%) 357 (+392%) 1755 utf-16le '\u8000'+'\u0100'*9999 503 (+258%) 1901 (-5%) 359 (+402%) 1802 utf-16le '\U00010000'*10000 484 (-14%) 379 (+9%) 103 (+303%) 415 utf-16le '\U00010000'+'A'*9999 504 (+244%) 1905 (-9%) 353 (+392%) 1735 utf-16le '\U00010000'+'\x80'*9999 503 (+245%) 1899 (-9%) 348 (+398%) 1733 utf-16le '\U00010000'+'\u0100'*9999 503 (+244%) 1882 (-8%) 348 (+397%) 1729 utf-16le '\U00010000'+'\u8000'*9999 503 (-18%) 355 (+16%) 71 (+482%) 413 utf-16be 'A'*10000 504 (+284%) 1553 (+24%) 469 (+312%) 1933 utf-16be '\x80'*10000 504 (+251%) 1551 (+14%) 387 (+357%) 1770 utf-16be '\x80'+'A'*9999 504 (+261%) 1549 (+17%) 386 (+371%) 1819 utf-16be '\u0100'*10000 503 (+175%) 1544 (-10%) 333 (+316%) 1384 utf-16be '\u0100'+'A'*9999 505 (+178%) 1548 (-9%) 335 (+319%) 1403 utf-16be '\u0100'+'\x80'*9999 503 (+179%) 1552 (-9%) 336 (+318%) 1405 utf-16be '\u8000'*10000 503 (-2%) 415 (+19%) 75 (+559%) 494 utf-16be '\u8000'+'A'*9999 504 (+179%) 1551 (-9%) 335 (+320%) 1408 utf-16be '\u8000'+'\x80'*9999 504 (+178%) 1551 (-10%) 336 (+317%) 1402 utf-16be '\u8000'+'\u0100'*9999 504 (+179%) 1549 (-9%) 336 (+318%) 1404 utf-16be '\U00010000'*10000 483 (-7%) 407 (+10%) 105 (+326%) 447 utf-16be '\U00010000'+'A'*9999 504 (+149%) 1554 (-19%) 317 (+295%) 1253 utf-16be '\U00010000'+'\x80'*9999 503 (+153%) 1543 (-17%) 317 (+302%) 1275 utf-16be '\U00010000'+'\u0100'*9999 503 (+153%) 1537 (-17%) 317 (+302%) 1274 utf-16be '\U00010000'+'\u8000'*9999 503 (-2%) 415 (+19%) 71 (+597%) 495 On 32-bit Linux, Intel Atom N570 @ 1.66GHz: Py2.7 Py3.2 Py3.3 patch utf-16le 'A'*10000 136 (+417%) 584 (+20%) 184 (+282%) 703 utf-16le '\x80'*10000 136 (+392%) 580 (+15%) 160 (+318%) 669 utf-16le '\x80'+'A'*9999 136 (+398%) 582 (+16%) 159 (+326%) 677 utf-16le '\u0100'*10000 137 (+346%) 583 (+5%) 129 (+374%) 611 utf-16le '\u0100'+'A'*9999 136 (+358%) 582 (+7%) 129 (+383%) 623 utf-16le '\u0100'+'\x80'*9999 136 (+348%) 580 (+5%) 129 (+372%) 609 utf-16le '\u8000'*10000 136 (+18%) 127 (+27%) 38 (+324%) 161 utf-16le '\u8000'+'A'*9999 136 (+357%) 582 (+7%) 129 (+382%) 622 utf-16le '\u8000'+'\x80'*9999 136 (+351%) 581 (+6%) 128 (+380%) 614 utf-16le '\u8000'+'\u0100'*9999 136 (+349%) 581 (+5%) 129 (+374%) 611 utf-16le '\U00010000'*10000 153 (-3%) 140 (+6%) 53 (+181%) 149 utf-16le '\U00010000'+'A'*9999 136 (+296%) 581 (-7%) 131 (+311%) 538 utf-16le '\U00010000'+'\x80'*9999 136 (+289%) 584 (-9%) 131 (+304%) 529 utf-16le '\U00010000'+'\u0100'*9999 136 (+290%) 579 (-8%) 130 (+308%) 530 utf-16le '\U00010000'+'\u8000'*9999 136 (+25%) 128 (+33%) 38 (+347%) 170 utf-16be 'A'*10000 136 (+331%) 441 (+33%) 166 (+253%) 586 utf-16be '\x80'*10000 136 (+309%) 440 (+26%) 145 (+283%) 556 utf-16be '\x80'+'A'*9999 136 (+312%) 442 (+27%) 145 (+286%) 560 utf-16be '\u0100'*10000 136 (+231%) 441 (+2%) 120 (+275%) 450 utf-16be '\u0100'+'A'*9999 136 (+232%) 442 (+2%) 120 (+276%) 451 utf-16be '\u0100'+'\x80'*9999 136 (+231%) 438 (+3%) 119 (+278%) 450 utf-16be '\u8000'*10000 136 (+22%) 127 (+31%) 38 (+337%) 166 utf-16be '\u8000'+'A'*9999 136 (+232%) 439 (+3%) 120 (+276%) 451 utf-16be '\u8000'+'\x80'*9999 136 (+230%) 439 (+2%) 120 (+274%) 449 utf-16be '\u8000'+'\u0100'*9999 136 (+232%) 439 (+3%) 120 (+276%) 451 utf-16be '\U00010000'*10000 153 (-1%) 139 (+9%) 52 (+192%) 152 utf-16be '\U00010000'+'A'*9999 136 (+211%) 440 (-4%) 121 (+250%) 423 utf-16be '\U00010000'+'\x80'*9999 136 (+210%) 440 (-4%) 122 (+246%) 422 utf-16be '\U00010000'+'\u0100'*9999 136 (+210%) 441 (-5%) 121 (+248%) 421 utf-16be '\U00010000'+'\u8000'*9999 136 (+27%) 128 (+35%) 38 (+355%) 173 ---------- Added file: http://bugs.python.org/file25323/decodebench.py Added file: http://bugs.python.org/file25324/bench-diff.py _______________________________________ Python tracker _______________________________________ -------------- next part -------------- # -*- coding: utf-8 -*- from __future__ import division, print_function, unicode_literals import sys import timeit import math try: ascii except NameError: ascii = repr def bench_decode(encoding, string): try: x = eval(string).encode(encoding) assert x.decode(encoding) == eval(string) except UnicodeEncodeError: return setup = ''' import codecs d = codecs.getdecoder({0!r}) x = {1!r} '''.format(encoding, x) repeat = 10 number = 100 r = timeit.repeat('d(x)', setup, repeat=repeat, number=number) best = min(r) usec = best * 1e6 / number print("%-8s %-30s %.0f" % (encoding, string.replace("u'", "'"), len(x) / usec)) sys.stdout.flush() n = 10000 chars = ('A', '\u0080', '\u0100', '\u8000', '\U00010000') encodings = sys.argv[1:] if not encodings: encodings = ('ascii', 'latin1', 'utf-8', 'utf-16le', 'utf-16be', 'utf-32le', 'utf-32be') for encoding in encodings: for i, ch1 in enumerate(chars): bench_decode(encoding, '%s*%d' % (ascii(ch1), n)) # for ch2 in chars[:i]: # bench_decode(encoding, ' %s+%s*%d' % (ascii(ch1), ascii(ch2), n - 1)) # for ch2 in chars[i + 1:]: # bench_decode(encoding, ' %s*%d+%s' % (ascii(ch1), n - 1, ascii(ch2))) print() -------------- next part -------------- #!/usr/bin/env python3 # -*- coding: utf-8 -*- import sys import re fs = [sys.stdin if fn == '-' else open(fn, 'rt') for fn in sys.argv[1:]] for lines in zip(*fs): m1 = re.match(r'(\S+\s+\S+\s+)(\S+)', lines[-1]) if m1: x1 = float(m1.group(2)) print(m1.group(1), end='') for line in lines[:-1]: m2 = re.match(r'(\S+\s+\S+\s+)(\S+)', line) x2 = float(m2.group(2)) print('%s (%+.0f%%)\t' % (m2.group(2), 100 * (x1 - x2) / x2,), end='') print('%s' % (m1.group(2),)) else: print() for f in fs: f.close() From report at bugs.python.org Mon Apr 23 23:01:40 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Apr 2012 21:01:40 +0000 Subject: [issue14625] Faster utf-32 decoder In-Reply-To: <1334869197.32.0.159275934867.issue14625@psf.upfronthosting.co.za> Message-ID: <1335214152.3101.241.camel@raxxla> Serhiy Storchaka added the comment: Here are the results of benchmarking (numbers in MB/s). On 32-bit Linux, AMD Athlon 64 X2 4600+ @ 2.4GHz: Py2.7 Py3.2 Py3.3 patchA patchB utf-32le 'A'*10000 461 (+215%) 454 (+220%) 292 (+398%) 1213 (+20%) 1454 utf-32le '\x80'*10000 458 (+177%) 454 (+180%) 271 (+369%) 1124 (+13%) 1270 utf-32le '\x80'+'A'*9999 462 (+171%) 454 (+175%) 271 (+361%) 1111 (+13%) 1250 utf-32le '\u0100'*10000 457 (+133%) 454 (+135%) 220 (+385%) 1002 (+6%) 1067 utf-32le '\u0100'+'A'*9999 461 (+129%) 454 (+132%) 220 (+379%) 993 (+6%) 1054 utf-32le '\u0100'+'\x80'*9999 458 (+131%) 454 (+133%) 220 (+381%) 1002 (+6%) 1059 utf-32le '\u8000'*10000 457 (+133%) 454 (+135%) 220 (+385%) 1002 (+6%) 1066 utf-32le '\u8000'+'A'*9999 462 (+128%) 454 (+132%) 220 (+379%) 994 (+6%) 1053 utf-32le '\u8000'+'\x80'*9999 457 (+132%) 454 (+134%) 220 (+382%) 1000 (+6%) 1061 utf-32le '\u8000'+'\u0100'*9999 457 (+132%) 454 (+134%) 220 (+382%) 1002 (+6%) 1061 utf-32le '\U00010000'*10000 386 (+167%) 416 (+148%) 212 (+386%) 930 (+11%) 1031 utf-32le '\U00010000'+'A'*9999 461 (+126%) 415 (+152%) 222 (+370%) 940 (+11%) 1044 utf-32le '\U00010000'+'\x80'*9999 458 (+125%) 415 (+148%) 222 (+364%) 930 (+11%) 1031 utf-32le '\U00010000'+'\u0100'*9999 458 (+125%) 415 (+148%) 212 (+386%) 930 (+11%) 1031 utf-32le '\U00010000'+'\u8000'*9999 458 (+125%) 415 (+149%) 222 (+365%) 930 (+11%) 1032 utf-32be 'A'*10000 461 (+216%) 454 (+221%) 292 (+399%) 1209 (+20%) 1456 utf-32be '\x80'*10000 457 (+177%) 454 (+179%) 271 (+368%) 1125 (+13%) 1268 utf-32be '\x80'+'A'*9999 462 (+171%) 453 (+176%) 271 (+362%) 1112 (+12%) 1251 utf-32be '\u0100'*10000 457 (+144%) 453 (+146%) 220 (+407%) 1048 (+6%) 1116 utf-32be '\u0100'+'A'*9999 462 (+139%) 454 (+143%) 220 (+402%) 1034 (+7%) 1104 utf-32be '\u0100'+'\x80'*9999 459 (+142%) 453 (+145%) 220 (+405%) 1047 (+6%) 1112 utf-32be '\u8000'*10000 457 (+144%) 453 (+147%) 220 (+408%) 1046 (+7%) 1117 utf-32be '\u8000'+'A'*9999 462 (+139%) 454 (+143%) 220 (+402%) 1034 (+7%) 1104 utf-32be '\u8000'+'\x80'*9999 459 (+142%) 453 (+145%) 220 (+405%) 1045 (+6%) 1112 utf-32be '\u8000'+'\u0100'*9999 459 (+142%) 454 (+144%) 220 (+404%) 1047 (+6%) 1109 utf-32be '\U00010000'*10000 386 (+155%) 416 (+137%) 212 (+364%) 940 (+5%) 984 utf-32be '\U00010000'+'A'*9999 461 (+116%) 415 (+140%) 213 (+367%) 948 (+5%) 994 utf-32be '\U00010000'+'\x80'*9999 458 (+115%) 415 (+137%) 222 (+343%) 938 (+5%) 983 utf-32be '\U00010000'+'\u0100'*9999 458 (+115%) 415 (+137%) 212 (+364%) 940 (+5%) 983 utf-32be '\U00010000'+'\u8000'*9999 458 (+115%) 415 (+137%) 222 (+343%) 939 (+5%) 983 On 32-bit Linux, Intel Atom N570 @ 1.66GHz: Py2.7 Py3.2 Py3.3 patchA patchB utf-32le 'A'*10000 165 (+173%) 165 (+173%) 100 (+350%) 389 (+16%) 450 utf-32le '\x80'*10000 165 (+159%) 165 (+159%) 76 (+462%) 374 (+14%) 427 utf-32le '\x80'+'A'*9999 165 (+161%) 165 (+161%) 76 (+466%) 374 (+15%) 430 utf-32le '\u0100'*10000 165 (+119%) 165 (+119%) 81 (+346%) 333 (+8%) 361 utf-32le '\u0100'+'A'*9999 165 (+120%) 165 (+120%) 81 (+348%) 334 (+9%) 363 utf-32le '\u0100'+'\x80'*9999 165 (+119%) 165 (+119%) 81 (+347%) 334 (+8%) 362 utf-32le '\u8000'*10000 165 (+119%) 165 (+119%) 80 (+352%) 333 (+9%) 362 utf-32le '\u8000'+'A'*9999 165 (+119%) 165 (+119%) 81 (+347%) 334 (+8%) 362 utf-32le '\u8000'+'\x80'*9999 165 (+119%) 165 (+119%) 81 (+347%) 334 (+8%) 362 utf-32le '\u8000'+'\u0100'*9999 165 (+118%) 165 (+118%) 81 (+343%) 333 (+8%) 359 utf-32le '\U00010000'*10000 155 (+130%) 151 (+136%) 80 (+346%) 324 (+10%) 357 utf-32le '\U00010000'+'A'*9999 165 (+117%) 165 (+117%) 80 (+348%) 325 (+10%) 358 utf-32le '\U00010000'+'\x80'*9999 165 (+118%) 165 (+118%) 80 (+349%) 325 (+10%) 359 utf-32le '\U00010000'+'\u0100'*9999 165 (+116%) 165 (+116%) 80 (+346%) 324 (+10%) 357 utf-32le '\U00010000'+'\u8000'*9999 165 (+117%) 165 (+117%) 80 (+348%) 324 (+10%) 358 utf-32be 'A'*10000 165 (+172%) 165 (+172%) 100 (+348%) 390 (+15%) 448 utf-32be '\x80'*10000 165 (+159%) 165 (+159%) 75 (+469%) 373 (+14%) 427 utf-32be '\x80'+'A'*9999 165 (+160%) 165 (+160%) 75 (+472%) 375 (+14%) 429 utf-32be '\u0100'*10000 165 (+119%) 165 (+119%) 81 (+347%) 334 (+8%) 362 utf-32be '\u0100'+'A'*9999 165 (+120%) 165 (+120%) 81 (+348%) 335 (+8%) 363 utf-32be '\u0100'+'\x80'*9999 165 (+119%) 165 (+119%) 81 (+347%) 335 (+8%) 362 utf-32be '\u8000'*10000 165 (+119%) 165 (+119%) 81 (+347%) 334 (+8%) 362 utf-32be '\u8000'+'A'*9999 165 (+120%) 165 (+120%) 81 (+348%) 334 (+9%) 363 utf-32be '\u8000'+'\x80'*9999 165 (+119%) 165 (+119%) 81 (+347%) 335 (+8%) 362 utf-32be '\u8000'+'\u0100'*9999 165 (+118%) 165 (+118%) 81 (+344%) 335 (+7%) 360 utf-32be '\U00010000'*10000 155 (+130%) 151 (+136%) 80 (+346%) 324 (+10%) 357 utf-32be '\U00010000'+'A'*9999 165 (+117%) 165 (+117%) 80 (+348%) 325 (+10%) 358 utf-32be '\U00010000'+'\x80'*9999 165 (+118%) 165 (+118%) 80 (+349%) 325 (+10%) 359 utf-32be '\U00010000'+'\u0100'*9999 165 (+117%) 165 (+117%) 80 (+348%) 324 (+10%) 358 utf-32be '\U00010000'+'\u8000'*9999 165 (+117%) 165 (+117%) 80 (+348%) 325 (+10%) 358 For scripts see issue14624. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 23:01:56 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Apr 2012 21:01:56 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334592597.05.0.199517355143.issue14596@psf.upfronthosting.co.za> Message-ID: <1335214650.3101.263.camel@raxxla> Serhiy Storchaka added the comment: Here is a patch that implements method __sizeof__ for Struct. This can be used to limit the caching. In any case, it is useful to know the real memory consumption of the object. I'm not sure of the correctness of the method implementation. ---------- Added file: http://bugs.python.org/file25325/struct_sizeof.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r c820aa9c0c00 Modules/_struct.c --- a/Modules/_struct.c Fri Apr 20 18:04:03 2012 -0400 +++ b/Modules/_struct.c Mon Apr 23 16:57:18 2012 +0300 @@ -1752,6 +1752,19 @@ return PyLong_FromSsize_t(self->s_size); } +static PyObject * +s_sizeof(PyStructObject *self, void *unused) +{ + Py_ssize_t res; + formatcode *code; + + res = sizeof(PyStructObject) + sizeof(formatcode); + for (code = self->s_codes; code->fmtdef != NULL; code++) { + res += sizeof(formatcode); + } + return PyLong_FromSsize_t(res); +} + /* List of functions */ static struct PyMethodDef s_methods[] = { @@ -1760,6 +1773,8 @@ {"unpack", s_unpack, METH_O, s_unpack__doc__}, {"unpack_from", (PyCFunction)s_unpack_from, METH_VARARGS|METH_KEYWORDS, s_unpack_from__doc__}, + {"__sizeof__", (PyCFunction)s_sizeof, METH_NOARGS, + "Returns size in memory, in bytes"}, {NULL, NULL} /* sentinel */ }; From report at bugs.python.org Mon Apr 23 23:04:08 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Apr 2012 21:04:08 +0000 Subject: [issue14654] More fast utf-8 decoding Message-ID: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : The utf-8 decoder is already well optimized. I propose a patch, which accelerates the utf-8 decoder for some of the frequent cases even more (+10-30%). In particular, for 2-bites non-latin1 codes will get about +30%. This is not the final result of optimization. It may be possible to optimize the decoding of the ascii and mostly-ascii text (up to the speed of memcpy), decoding of text with occasional errors, reduce code duplication. But I'm not sure of the success. Related issues: [issue4868] Faster utf-8 decoding [issue13417] faster utf-8 decoding [issue14419] Faster ascii decoding [issue14624] Faster utf-16 decoder [issue14625] Faster utf-32 decoder ---------- components: Interpreter Core files: decode_utf8.patch keywords: patch messages: 159080 nosy: haypo, pitrou, storchaka priority: normal severity: normal status: open title: More fast utf-8 decoding type: performance versions: Python 3.3 Added file: http://bugs.python.org/file25326/decode_utf8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 23:05:42 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 23 Apr 2012 21:05:42 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1335215142.21.0.612906709668.issue11618@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: The vista specific path is included there for completeness, if and when code moves to that platform, besides showing what the "emulated CV" is actually emulating. Also, I am aware of the old/new GIL, but our console game uses python 2.7 and the old GIL will be living on for many a good year, just like 2.7 will. But you make a good point. I had forgotten that the new GIL is actually implemented with emulated condition variables (current version contributed by myself :). I think a different patch is in order, where ceval_gil.h makes use of the platform specific "condition variable" services as declared in thread_platform.h. There is no point in duplicating code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 23:06:57 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 23 Apr 2012 21:06:57 +0000 Subject: [issue14654] More fast utf-8 decoding In-Reply-To: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za> Message-ID: <1335215364.3101.289.camel@raxxla> Serhiy Storchaka added the comment: Here are the results of benchmarking (numbers in MB/s). On 32-bit Linux, AMD Athlon 64 X2 4600+ @ 2.4GHz: Py2.7 Py3.2 Py3.3 patch utf-8 'A'*10000 191 (+790%) 1170 (+45%) 1664 (+2%) 1700 utf-8 '\x80'*10000 187 (+4%) 219 (-11%) 172 (+13%) 194 utf-8 '\x80'+'A'*9999 191 (+98%) 1152 (-67%) 376 (+1%) 378 utf-8 '\u0100'*10000 188 (+15%) 221 (-2%) 164 (+32%) 217 utf-8 '\u0100'+'A'*9999 191 (+103%) 1150 (-66%) 382 (+1%) 387 utf-8 '\u0100'+'\x80'*9999 188 (+15%) 221 (-2%) 164 (+32%) 217 utf-8 '\u8000'*10000 244 (-12%) 263 (-18%) 191 (+13%) 215 utf-8 '\u8000'+'A'*9999 191 (+102%) 1174 (-67%) 382 (+1%) 386 utf-8 '\u8000'+'\x80'*9999 188 (+15%) 216 (+0%) 164 (+32%) 217 utf-8 '\u8000'+'\u0100'*9999 188 (+15%) 216 (+0%) 164 (+32%) 217 utf-8 '\U00010000'*10000 251 (-15%) 248 (-14%) 199 (+7%) 213 utf-8 '\U00010000'+'A'*9999 191 (+97%) 1173 (-68%) 372 (+1%) 376 utf-8 '\U00010000'+'\x80'*9999 188 (+21%) 221 (+3%) 180 (+26%) 227 utf-8 '\U00010000'+'\u0100'*9999 188 (+21%) 221 (+3%) 180 (+26%) 227 utf-8 '\U00010000'+'\u8000'*9999 244 (-9%) 263 (-16%) 201 (+10%) 221 On 32-bit Linux, Intel Atom N570 @ 1.66GHz: Py2.7 Py3.2 Py3.3 patch utf-8 'A'*10000 117 (+414%) 349 (+72%) 597 (+1%) 601 utf-8 '\x80'*10000 86 (-5%) 89 (-8%) 67 (+22%) 82 utf-8 '\x80'+'A'*9999 117 (+6%) 340 (-64%) 126 (-2%) 124 utf-8 '\u0100'*10000 86 (-2%) 89 (-6%) 66 (+27%) 84 utf-8 '\u0100'+'A'*9999 117 (+5%) 339 (-64%) 78 (+58%) 123 utf-8 '\u0100'+'\x80'*9999 86 (-2%) 89 (-6%) 66 (+27%) 84 utf-8 '\u8000'*10000 109 (-26%) 98 (-17%) 71 (+14%) 81 utf-8 '\u8000'+'A'*9999 116 (+7%) 339 (-63%) 78 (+59%) 124 utf-8 '\u8000'+'\x80'*9999 86 (-3%) 89 (-7%) 66 (+26%) 83 utf-8 '\u8000'+'\u0100'*9999 86 (-3%) 89 (-7%) 66 (+26%) 83 utf-8 '\U00010000'*10000 106 (-14%) 105 (-13%) 81 (+12%) 91 utf-8 '\U00010000'+'A'*9999 116 (+12%) 338 (-62%) 127 (+2%) 130 utf-8 '\U00010000'+'\x80'*9999 86 (+6%) 88 (+3%) 69 (+32%) 91 utf-8 '\U00010000'+'\u0100'*9999 86 (+6%) 88 (+3%) 69 (+32%) 91 utf-8 '\U00010000'+'\u8000'*9999 109 (-24%) 98 (-15%) 74 (+12%) 83 The results were ambiguous (everywhere plus, but in different ways). I would like to see the results for 64-bit platforms. For scripts see issue14624. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 23:12:08 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Apr 2012 21:12:08 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335215528.04.0.604116089554.issue3177@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: -haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 23:16:08 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Apr 2012 21:16:08 +0000 Subject: [issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..." In-Reply-To: <1335188708.97.0.140811332304.issue14648@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: >>>> "{0:s}{1:s}".format("ABC", "\u0410\u0411\u0412") > python: Objects/unicodeobject.c:1223: _copy_characters: Assertion `ch <= to_maxchar' failed. Attached patch fixes this issue. ---------- keywords: +patch Added file: http://bugs.python.org/file25327/format_nonascii.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 6762b943ee59 Lib/test/test_unicode.py --- a/Lib/test/test_unicode.py Tue Apr 17 21:42:07 2012 -0400 +++ b/Lib/test/test_unicode.py Mon Apr 23 16:25:13 2012 +0200 @@ -924,6 +924,14 @@ class UnicodeTest(string_tests.CommonTes self.assertRaises(ValueError, format, '', '#') self.assertRaises(ValueError, format, '', '#20') + # Non-ASCII + self.assertEqual("{0:s}{1:s}".format("ABC", "\u0410\u0411\u0412"), + 'ABC\u0410\u0411\u0412') + self.assertEqual("{0:.3s}".format("ABC\u0410\u0411\u0412"), + 'ABC') + self.assertEqual("{0:.0s}".format("ABC\u0410\u0411\u0412"), + '') + def test_format_map(self): self.assertEqual(''.format_map({}), '') self.assertEqual('a'.format_map({}), 'a') diff -r 6762b943ee59 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Tue Apr 17 21:42:07 2012 -0400 +++ b/Objects/unicodeobject.c Mon Apr 23 16:25:13 2012 +0200 @@ -1957,6 +1957,37 @@ PyUnicode_FromKindAndData(int kind, cons } } +Py_UCS4 +_PyUnicode_FindMaxChar(PyObject *unicode, Py_ssize_t start, Py_ssize_t end) +{ + enum PyUnicode_Kind kind; + void *startptr, *endptr; + + assert(PyUnicode_IS_READY(unicode)); + assert(0 <= start); + assert(end <= PyUnicode_GET_LENGTH(unicode)); + assert(start <= end); + + if (start == 0 && end == PyUnicode_GET_LENGTH(unicode)) + return PyUnicode_MAX_CHAR_VALUE(unicode); + + if (start == end) + return 127; + + kind = PyUnicode_KIND(unicode); + startptr = PyUnicode_DATA(unicode); + endptr = (char*)startptr + end * kind; + if (start) + startptr = (char*)startptr + start * kind; + switch(kind) + { + case PyUnicode_1BYTE_KIND: return ucs1lib_find_max_char(startptr, endptr); + case PyUnicode_2BYTE_KIND: return ucs2lib_find_max_char(startptr, endptr); + default: + case PyUnicode_4BYTE_KIND: return ucs4lib_find_max_char(startptr, endptr); + } +} + /* Ensure that a string uses the most efficient storage, if it is not the case: create a new string with of the right kind. Write NULL into *p_unicode on error. */ diff -r 6762b943ee59 Python/formatter_unicode.c --- a/Python/formatter_unicode.c Tue Apr 17 21:42:07 2012 -0400 +++ b/Python/formatter_unicode.c Mon Apr 23 16:25:13 2012 +0200 @@ -713,10 +713,10 @@ format_string_internal(PyObject *value, Py_ssize_t lpad; Py_ssize_t rpad; Py_ssize_t total; - Py_ssize_t pos; + Py_ssize_t i, pos; Py_ssize_t len = PyUnicode_GET_LENGTH(value); PyObject *result = NULL; - Py_UCS4 maxchar = 127; + Py_UCS4 ch, maxchar = 127; /* sign is not allowed on strings */ if (format->sign != '\0') { @@ -752,8 +752,12 @@ format_string_internal(PyObject *value, if (lpad != 0 || rpad != 0) maxchar = Py_MAX(maxchar, format->fill_char); + ch = _PyUnicode_FindMaxChar(value, 0, len); + maxchar = Py_MAX(maxchar, ch); + /* allocate the resulting string */ result = PyUnicode_New(total, maxchar); + printf("maxchar = 0x%x\n", maxchar); if (result == NULL) goto done; From report at bugs.python.org Mon Apr 23 23:22:52 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 21:22:52 +0000 Subject: [issue14655] traceback module docs should show how to print/fomat an exception object Message-ID: <1335216172.17.0.173976069373.issue14655@psf.upfronthosting.co.za> New submission from R. David Murray : Suppose you have an exception object acquired from somewhere. The exception is no longer active on the stack. Now you want to format the exception like format_exception would (to log it, perhaps). To do this you apparently need to call: format_exception(type(exc), exc, exc.__traceback__) This seems redundant, so it would be nice to have a simpler call. Too bad the name format_exception is already taken. But, leaving that aside, the above is not documented in the traceback module. The last example shows the (type(exc), exc) call form for format_exception_only, but that's as close as it gets. ---------- messages: 159084 nosy: r.david.murray priority: normal severity: normal stage: needs patch status: open title: traceback module docs should show how to print/fomat an exception object type: enhancement versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 23:23:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Apr 2012 21:23:13 +0000 Subject: [issue14654] More fast utf-8 decoding In-Reply-To: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za> Message-ID: <1335216193.84.0.395160670632.issue14654@psf.upfronthosting.co.za> Antoine Pitrou added the comment: 64-bit Linux, Intel Core i5-2500K CPU @ 3.30GHz: vanilla 3.3 patched utf-8 'A'*10000 6668 (+7%) 7145 utf-8 'A'*9999+'\x80' 2358 (+3%) 2418 utf-8 'A'*9999+'\u0100' 2306 (+0%) 2311 utf-8 'A'*9999+'\u8000' 2299 (+0%) 2309 utf-8 'A'*9999+'\U00010000' 2373 (-4%) 2278 utf-8 '\x80'*10000 366 (+53%) 559 utf-8 '\x80'+'A'*9999 859 (+1%) 868 utf-8 '\x80'*9999+'\u0100' 529 (+5%) 558 utf-8 '\x80'*9999+'\u8000' 529 (+5%) 558 utf-8 '\x80'*9999+'\U00010000' 529 (+5%) 558 utf-8 '\u0100'*10000 520 (+6%) 549 utf-8 '\u0100'+'A'*9999 822 (+0%) 823 utf-8 '\u0100'+'\x80'*9999 519 (+6%) 549 utf-8 '\u0100'*9999+'\u8000' 520 (+6%) 549 utf-8 '\u0100'*9999+'\U00010000' 520 (+6%) 549 utf-8 '\u8000'*10000 470 (+4%) 491 utf-8 '\u8000'+'A'*9999 822 (+0%) 822 utf-8 '\u8000'+'\x80'*9999 509 (+8%) 549 utf-8 '\u8000'+'\u0100'*9999 509 (+8%) 549 utf-8 '\u8000'*9999+'\U00010000' 470 (-4%) 451 utf-8 '\U00010000'*10000 483 (-6%) 453 utf-8 '\U00010000'+'A'*9999 938 (-1%) 926 utf-8 '\U00010000'+'\x80'*9999 561 (+6%) 595 utf-8 '\U00010000'+'\u0100'*9999 561 (+6%) 595 utf-8 '\U00010000'+'\u8000'*9999 503 (-4%) 482 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 23:33:13 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Apr 2012 21:33:13 +0000 Subject: [issue14654] More fast utf-8 decoding In-Reply-To: <1335216193.84.0.395160670632.issue14654@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > 64-bit Linux, Intel Core i5-2500K CPU @ 3.30GHz: (...) Hum, the patch doesn't look very interesting if it only optimize one specific case: > utf-8 ? ? '\x80'*10000 ? ? ? ? ? ? ? ? ? ?366 (+53%) ? ?559 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 23:43:13 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 23 Apr 2012 21:43:13 +0000 Subject: [issue14648] Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..." In-Reply-To: <1335187087.5.0.315362932474.issue14648@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 139c3ae84772 by Victor Stinner in branch 'default': Close #14648: Compute correctly maxchar in str.format() for substrin http://hg.python.org/cpython/rev/139c3ae84772 ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 23:52:11 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 23 Apr 2012 21:52:11 +0000 Subject: [issue14656] Add a macro for unreachable code Message-ID: <1335217931.89.0.157136074708.issue14656@psf.upfronthosting.co.za> New submission from Benjamin Peterson : It would be nice to have a macro Py_UNREACHABLE to keep compiler warnings away in unreachable code. This is can call __builtin_unreachable on gcc and abort elsewhere. ---------- components: Interpreter Core keywords: easy messages: 159088 nosy: benjamin.peterson priority: normal severity: normal stage: needs patch status: open title: Add a macro for unreachable code type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 23:53:04 2012 From: report at bugs.python.org (Marc Abramowitz) Date: Mon, 23 Apr 2012 21:53:04 +0000 Subject: [issue14572] 2.7.3: sqlite module does not build on centos 5 In-Reply-To: <1334354952.88.0.487562486207.issue14572@psf.upfronthosting.co.za> Message-ID: <1335217984.19.0.269725989233.issue14572@psf.upfronthosting.co.za> Marc Abramowitz added the comment: This patch worked for me as well. Thanks, Joakim! $ cat /etc/redhat-release CentOS release 5.5 (Final) ---------- nosy: +Marc.Abramowitz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 23:57:21 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Apr 2012 21:57:21 +0000 Subject: [issue14624] Faster utf-16 decoder In-Reply-To: <1334869141.17.0.802149162715.issue14624@psf.upfronthosting.co.za> Message-ID: <1335218241.27.0.705338209525.issue14624@psf.upfronthosting.co.za> Antoine Pitrou added the comment: 64 bit Linux, Intel Core i5-2500K @ 3.30GHz: vanilla 3.3 patched utf-16le 'A'*10000 1384 (+278%) 5233 utf-16le 'A'*9999+'\x80' 1303 (+259%) 4684 utf-16le 'A'*9999+'\u0100' 953 (+195%) 2813 utf-16le 'A'*9999+'\u8000' 953 (+195%) 2814 utf-16le 'A'*9999+'\U00010000' 979 (+197%) 2903 utf-16le '\x80'*10000 1243 (+321%) 5230 utf-16le '\x80'+'A'*9999 1256 (+313%) 5188 utf-16le '\x80'*9999+'\u0100' 880 (+214%) 2765 utf-16le '\x80'*9999+'\u8000' 880 (+214%) 2763 utf-16le '\x80'*9999+'\U00010000' 899 (+218%) 2860 utf-16le '\u0100'*10000 1047 (+370%) 4917 utf-16le '\u0100'+'A'*9999 1046 (+369%) 4906 utf-16le '\u0100'+'\x80'*9999 1047 (+370%) 4920 utf-16le '\u0100'*9999+'\u8000' 1047 (+369%) 4906 utf-16le '\u0100'*9999+'\U00010000' 791 (+253%) 2793 utf-16le '\u8000'*10000 230 (+410%) 1173 utf-16le '\u8000'+'A'*9999 1043 (+371%) 4911 utf-16le '\u8000'+'\x80'*9999 1044 (+345%) 4645 utf-16le '\u8000'+'\u0100'*9999 1041 (+350%) 4681 utf-16le '\u8000'*9999+'\U00010000' 215 (+357%) 983 utf-16le '\U00010000'*10000 362 (+170%) 976 utf-16le '\U00010000'+'A'*9999 985 (+210%) 3052 utf-16le '\U00010000'+'\x80'*9999 985 (+211%) 3066 utf-16le '\U00010000'+'\u0100'*9999 983 (+209%) 3042 utf-16le '\U00010000'+'\u8000'*9999 245 (+329%) 1052 utf-16be 'A'*10000 1268 (+313%) 5240 utf-16be 'A'*9999+'\x80' 1199 (+297%) 4758 utf-16be 'A'*9999+'\u0100' 896 (+211%) 2786 utf-16be 'A'*9999+'\u8000' 897 (+211%) 2788 utf-16be 'A'*9999+'\U00010000' 919 (+214%) 2885 utf-16be '\x80'*10000 1154 (+341%) 5087 utf-16be '\x80'+'A'*9999 1155 (+343%) 5112 utf-16be '\x80'*9999+'\u0100' 829 (+229%) 2728 utf-16be '\x80'*9999+'\u8000' 828 (+229%) 2726 utf-16be '\x80'*9999+'\U00010000' 852 (+232%) 2832 utf-16be '\u0100'*10000 981 (+332%) 4241 utf-16be '\u0100'+'A'*9999 981 (+330%) 4220 utf-16be '\u0100'+'\x80'*9999 977 (+331%) 4213 utf-16be '\u0100'*9999+'\u8000' 982 (+331%) 4237 utf-16be '\u0100'*9999+'\U00010000' 748 (+237%) 2520 utf-16be '\u8000'*10000 230 (+413%) 1180 utf-16be '\u8000'+'A'*9999 979 (+331%) 4218 utf-16be '\u8000'+'\x80'*9999 974 (+333%) 4215 utf-16be '\u8000'+'\u0100'*9999 972 (+335%) 4226 utf-16be '\u8000'*9999+'\U00010000' 215 (+361%) 992 utf-16be '\U00010000'*10000 362 (+170%) 978 utf-16be '\U00010000'+'A'*9999 924 (+232%) 3064 utf-16be '\U00010000'+'\x80'*9999 921 (+223%) 2979 utf-16be '\U00010000'+'\u0100'*9999 921 (+233%) 3064 utf-16be '\U00010000'+'\u8000'*9999 245 (+329%) 1052 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 23 23:59:38 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 23 Apr 2012 21:59:38 +0000 Subject: [issue14654] More fast utf-8 decoding In-Reply-To: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za> Message-ID: <1335218378.31.0.564369381674.issue14654@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 00:04:28 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 23 Apr 2012 22:04:28 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <1335217931.89.0.157136074708.issue14656@psf.upfronthosting.co.za> Message-ID: <1335218668.5.0.217206505372.issue14656@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 00:08:46 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 23 Apr 2012 22:08:46 +0000 Subject: [issue14655] traceback module docs should show how to print/fomat an exception object In-Reply-To: <1335216172.17.0.173976069373.issue14655@psf.upfronthosting.co.za> Message-ID: <1335218926.02.0.26583807706.issue14655@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Why not reuse format_exception(exc)? in 2.7 you could write "raise type, value, traceback", or "raise value". I suggest that traceback.format_exception take the same route, and accept both (type, value, traceback) and (value). ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 00:08:59 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Apr 2012 22:08:59 +0000 Subject: [issue14080] Sporadic test_imp failure In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za> Message-ID: <1335218939.02.0.0516665565808.issue14080@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Happened again on one of the Windows buildbots: http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6436/steps/test/logs/stdio ====================================================================== FAIL: test_package___file__ (test.test_imp.PEP3147Tests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_imp.py", line 329, in test_package___file__ self.assertEqual(m.__file__, expected___file__, (m.__file__, m.__path__, sys.path, sys.path_importer_cache)) AssertionError: 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\build\\test_python [truncated]... != '.\\pep3147\\__init__.py' - D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\build\test_python_3480\pep3147\__init__.py + .\pep3147\__init__.py : ('D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\build\\test_python_3480\\pep3147\\__init__.py', ['D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\build\\test_python_3480\\pep3147'], ['.', 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\PCbuild\\python33_d.zip', 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\DLLs', 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\lib', 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\PCbuild', 'C:\\Documents and Settings\\db3l\\Application Data\\Python\\Python33\\site-packages', 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build', 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\lib\\site-packages'], {'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\lib\\lib2to3\\fixes': <_frozen_importlib.FileFinder object at 0x103CC4D0>, 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\lib\\site-packages': , 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\lib\\xml\\etree': None, 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\lib\\lib2to3\\tests\\data\\fixers\\myfixes': <_frozen_importlib.FileFinder object at 0x103CC658>, 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\lib\\test': <_frozen_importlib.FileFinder object at 0x07CAFE38>, 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\PCbuild\\python33_d.zip': , 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\lib': , 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\PCbuild': , 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build': , 'C:\\Documents and Settings\\db3l\\Application Data\\Python\\Python33\\site-packages': , 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\lib\\lib2to3\\tests': <_frozen_importlib.FileFinder object at 0x09E031C0>, 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\lib\\lib2to3\\tests\\data\\fixers': <_frozen_importlib.FileFinder object at 0x103CC118>, 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\lib\\lib2to3': <_frozen_importlib.FileFinder object at 0x09E03B60>, 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\DLLs': }) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 00:11:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Apr 2012 22:11:11 +0000 Subject: [issue14080] Sporadic test_imp failure In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za> Message-ID: <1335219071.32.0.721009527049.issue14080@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Some entries in sys.path_importer_cache are named _frozen_importlib.FileFinder, and others are named importlib._bootstrap.FileFinder. Isn't that a bit worrying? Two copies of importlib are loaded in memory? (and functioning independently?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 00:12:07 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 23 Apr 2012 22:12:07 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <1335217931.89.0.157136074708.issue14656@psf.upfronthosting.co.za> Message-ID: <1335219127.33.0.144441842196.issue14656@psf.upfronthosting.co.za> Martin v. L?wis added the comment: What's the specific warning that you want to eliminate? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 00:19:35 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 23 Apr 2012 22:19:35 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <1335219127.33.0.144441842196.issue14656@psf.upfronthosting.co.za> Message-ID: Benjamin Peterson added the comment: 2012/4/23 Martin v. L?wis : > > Martin v. L?wis added the comment: > > What's the specific warning that you want to eliminate? "control reaches end of non-void function without return" Basically, whenever you see "assert(0)" today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 00:34:04 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Apr 2012 22:34:04 +0000 Subject: [issue14657] Avoid two importlib copies Message-ID: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This patch avoids creating a second copy of importlib._bootstrap when a first one exists as _frozen_importlib. This isn't perfect as it mutates the module when importlib is imported for the first time, but I think it's better than the status quo. Also, importlib itself could be imported somewhere along the startup phase, so that all this is invisible to the user. I'm not sure how to test this, since _frozen_importlib is an implementation detail, and changing that module's name would probably defeat the test already. ---------- components: Interpreter Core, Library (Lib) files: unique_importlib.patch keywords: patch messages: 159096 nosy: brett.cannon, ncoghlan, pitrou priority: normal severity: normal stage: patch review status: open title: Avoid two importlib copies type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file25328/unique_importlib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 00:42:05 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Apr 2012 22:42:05 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335220925.08.0.940972626082.issue14657@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file25328/unique_importlib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 00:42:35 2012 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 23 Apr 2012 22:42:35 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335220955.5.0.295223670935.issue14657@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 00:43:14 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Apr 2012 22:43:14 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335220994.39.0.87548701102.issue14657@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Added file: http://bugs.python.org/file25329/unique_importlib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 00:45:08 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 23 Apr 2012 22:45:08 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: Message-ID: <20120424004507.Horde.BWpocKGZi1VPldtzCRAXVNA@webmail.df.eu> Martin v. L?wis added the comment: >> What's the specific warning that you want to eliminate? > > "control reaches end of non-void function without return" > > Basically, whenever you see "assert(0)" today. Sorry, what I meant is: what specific line (in what specific source file) is that warning on? If there is an assert(0) somewhere, there should be no subsequent code, so no such warning should be generated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 00:50:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Apr 2012 22:50:27 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335221427.95.0.760831225668.issue14657@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New patch with tests. ---------- Added file: http://bugs.python.org/file25330/unique_importlib2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 00:53:33 2012 From: report at bugs.python.org (Albert Zeyer) Date: Mon, 23 Apr 2012 22:53:33 +0000 Subject: [issue14658] Overwriting dict.__getattr__ is inconsistent Message-ID: <1335221613.52.0.779214050633.issue14658@psf.upfronthosting.co.za> New submission from Albert Zeyer : ``` class Foo1(dict): def __getattr__(self, key): return self[key] def __setattr__(self, key, value): self[key] = value class Foo2(dict): __getattr__ = dict.__getitem__ __setattr__ = dict.__setitem__ o1 = Foo1() o1.x = 42 print(o1, o1.x) o2 = Foo2() o2.x = 42 print(o2, o2.x) ``` With CPython 2.5, 2.6 (similarly in 3.2), I get: ({'x': 42}, 42) ({}, 42) With PyPy 1.5.0, I get the expected output:: ({'x': 42}, 42) ({'x': 42}, 42) I asked this also on SO: http://stackoverflow.com/questions/6305267/python-inconsistence-in-the-way-you-define-the-function-setattr >From the answers, I am not exactly sure wether this is considered as a bug in CPython or not. Anyway, I just wanted to post this here. ---------- components: None messages: 159099 nosy: Albert.Zeyer priority: normal severity: normal status: open title: Overwriting dict.__getattr__ is inconsistent type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 00:54:14 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Apr 2012 22:54:14 +0000 Subject: [issue14658] Overwriting dict.__getattr__ is inconsistent In-Reply-To: <1335221613.52.0.779214050633.issue14658@psf.upfronthosting.co.za> Message-ID: <1335221654.57.0.422337650056.issue14658@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 01:01:27 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 23 Apr 2012 23:01:27 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335222087.77.0.604542170457.issue14657@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New patch also avoids calling _setup() a second time (which can be annoying since _setup() has a list.append() call somewhere). ---------- Added file: http://bugs.python.org/file25331/unique_importlib3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 01:06:33 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 23 Apr 2012 23:06:33 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <20120424004507.Horde.BWpocKGZi1VPldtzCRAXVNA@webmail.df.eu> Message-ID: Benjamin Peterson added the comment: 2012/4/23 Martin v. L?wis : > > Martin v. L?wis added the comment: > >>> What's the specific warning that you want to eliminate? >> >> "control reaches end of non-void function without return" >> >> Basically, whenever you see "assert(0)" today. > > Sorry, what I meant is: what specific line (in what specific > source file) is that warning on? > > If there is an assert(0) somewhere, there should be no > subsequent code, so no such warning should be generated. Right, we currently avoid this problem by writing "assert(0)" for example in lookdict_split in dictobject.c. What I'm saying is that instead writing "assert(0)", we could use Py_UNREACHABLE. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 01:36:50 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 23 Apr 2012 23:36:50 +0000 Subject: [issue14655] traceback module docs should show how to print/fomat an exception object In-Reply-To: <1335216172.17.0.173976069373.issue14655@psf.upfronthosting.co.za> Message-ID: <1335224210.27.0.892558690814.issue14655@psf.upfronthosting.co.za> R. David Murray added the comment: Sounds OK to me, though I am worried others will think that kind of variable signature (where the type of the first argument depends on the number of arguments passed) is bad. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 01:45:18 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 23 Apr 2012 23:45:18 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: Message-ID: <20120424014517.Horde.9sDyd6GZi1VPlemNbpdnb6A@webmail.df.eu> Martin v. L?wis added the comment: > Right, we currently avoid this problem by writing "assert(0)" for > example in lookdict_split in dictobject.c. What I'm saying is that > instead writing "assert(0)", we could use Py_UNREACHABLE. I don't understand. The assert(0) is not there to silence any compiler warnings, is it? Instead, ISTM that it is there to truly assert that the code is not reached, which isn't actually obvious at all (IIUC, it's not reached because there must be some empty slot eventually unless the key is in there already). Instead, ISTM that is actually the "return 0;" that should silence the compiler warning about not having a return statement. If that's all true, I fail to see what __builtin_unreachable would achieve: we certainly have to preserve the return statement, for compilers not supporting such a declaration. Wouldn't this actually have the undesirable effect of complaining about the return statement when compiling with -Wunreachable-code? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 01:53:32 2012 From: report at bugs.python.org (Chris Rebert) Date: Mon, 23 Apr 2012 23:53:32 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335225212.09.0.211587187231.issue3177@psf.upfronthosting.co.za> Changes by Chris Rebert : Added file: http://bugs.python.org/file25332/shutil_open.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 02:09:19 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 24 Apr 2012 00:09:19 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335226159.96.0.796734092427.issue14657@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 02:41:42 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 24 Apr 2012 00:41:42 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335228102.81.0.191480459618.issue14657@psf.upfronthosting.co.za> Brett Cannon added the comment: So why the mutation? Are you that worried someone is going to import importlib._bootstrap directly? This also costs in development complexity because not only do you have to run 'make' to get changes to be testable, but it also leads to difficult debugging situations where if you are not totally sure you got something working you won't find out until you see e.g. that the standard I/O streams were not initialized. If you really feel the need to hide _frozen_importlib then it would be better to do the minimum required to get import up and running (should be once the encodings are up in Py_Initialize) and then pull in importlib._bootstrap and have that clear out what _frozen_importlib set like __import__(), sys.path_importer_cache(), and eventually sys.meta_path and sys.path_hooks (I wouldn't touch sys.modules, though, thanks to built-ins and extensions not liking to be reloaded). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 02:42:33 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 24 Apr 2012 00:42:33 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1335228153.78.0.882148018063.issue10941@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I still get conflicts: $ patch -p0 < imaplib_Internaldate2tuple_dst_fix_python32.patch patching file Lib/imaplib.py Hunk #2 FAILED at 1312. Hunk #3 succeeded at 1347 (offset 8 lines). Hunk #4 FAILED at 1379. 2 out of 4 hunks FAILED -- saving rejects to file Lib/imaplib.py.rej patching file Lib/test/test_imaplib.py Hunk #1 FAILED at 24. 1 out of 1 hunk FAILED -- saving rejects to file Lib/test/test_imaplib.py.rej Are you sure your patch is against the head of the hg repository? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 02:43:47 2012 From: report at bugs.python.org (Andrei Paraschivescu) Date: Tue, 24 Apr 2012 00:43:47 +0000 Subject: [issue8427] toplevel jumps to another location on the screen In-Reply-To: <1271451007.13.0.573906972341.issue8427@psf.upfronthosting.co.za> Message-ID: <1335228227.05.0.495931543935.issue8427@psf.upfronthosting.co.za> Andrei Paraschivescu added the comment: "python jumpBug.py" creates two windows, "root" and "other". If the first thing you do is click on "other", then hit

, the printed geometry string will show the position of the window "root". By contrast, if you first click on "root", then on "other", followed by

, the correct position of "other" is shown. As mentioned before, this happens on OS X Tiger but not on my FreeBSD machine, or new Mac laptop running Snow Leopard. I've isolated that the erratic jumping of windows I mentioned in the initial bug report is caused by calling .geometry with incorrect geometry strings. ---------- Added file: http://bugs.python.org/file25333/jumpBug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 02:51:29 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 24 Apr 2012 00:51:29 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335228689.86.0.888213872948.issue14605@psf.upfronthosting.co.za> Brett Cannon added the comment: Updated patch for an explicit sys.path_hooks that simply tweaks the test_cmd_line_script tests to stop requiring an absolute path on the files and instead verifies that the relative paths are legit. It also adds warnings when None is found in sys.path_importer_cache and then subsequently just tries sys.path_hooks again. It also warnings when sys.path_hooks is empty. ---------- Added file: http://bugs.python.org/file25334/explicit_path_hooks.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 02:53:01 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 24 Apr 2012 00:53:01 +0000 Subject: [issue14080] Sporadic test_imp failure In-Reply-To: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za> Message-ID: <1335228781.51.0.596433266207.issue14080@psf.upfronthosting.co.za> Brett Cannon added the comment: Issue #14657 is tracking the discussion of _frozen_importlib/importlib._bootstrap. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 02:56:36 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 24 Apr 2012 00:56:36 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335228996.18.0.111099591654.issue14657@psf.upfronthosting.co.za> Brett Cannon added the comment: I should also mention that all of this becomes much less important once issue #14605 is finished because at that point sys.meta_path and sys.path_hooks will have _frozen_importlib objects and that will be what importlib works off of directly. But I still understand the desire to eliminate _frozen_importlib from being exposed, it's just a matter of coming up with a reasonable solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 03:45:23 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 24 Apr 2012 01:45:23 +0000 Subject: [issue14658] Overwriting dict.__getattr__ is inconsistent In-Reply-To: <1335221613.52.0.779214050633.issue14658@psf.upfronthosting.co.za> Message-ID: <1335231923.69.0.812323282427.issue14658@psf.upfronthosting.co.za> Benjamin Peterson added the comment: It's a CPython bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 04:18:48 2012 From: report at bugs.python.org (Ned Deily) Date: Tue, 24 Apr 2012 02:18:48 +0000 Subject: [issue8427] toplevel jumps to another location on the screen In-Reply-To: <1271451007.13.0.573906972341.issue8427@psf.upfronthosting.co.za> Message-ID: <1335233928.41.0.074605316008.issue8427@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for supplying the test case. I can reproduce the incorrect behavior by using Python 2.7 and the Apple-supplied system Tcl/Tk 8.4 on OS X 10.4. But if a current ActiveState Tcl/Tk 8.4 is used with the same Python and OS X, the correct behavior is seen. The Apple-supplied Tcl/Tk on OS X 10.4 is very old; if you need to use Tkinter-based applications there, you should install an ActiveState Tcl/Tk 8.4 and a current Python that is supported with it, for example, from the current 32-bit-only Python 2.7.3 or 3.2.3 python.org installers. More info here: http://www.python.org/download/mac/tcltk/ ---------- nosy: +ned.deily resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 04:21:13 2012 From: report at bugs.python.org (Joe Peterson) Date: Tue, 24 Apr 2012 02:21:13 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1335234073.32.0.772319966581.issue10941@psf.upfronthosting.co.za> Joe Peterson added the comment: The one you tried is the old patch. Here are the two new patches. Use these: Python 2: issue10941_python2.diff Python 3: issue10941_python3.diff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 04:27:44 2012 From: report at bugs.python.org (Andrei Paraschivescu) Date: Tue, 24 Apr 2012 02:27:44 +0000 Subject: [issue8427] toplevel jumps to another location on the screen In-Reply-To: <1271451007.13.0.573906972341.issue8427@psf.upfronthosting.co.za> Message-ID: <1335234464.54.0.0673420138585.issue8427@psf.upfronthosting.co.za> Andrei Paraschivescu added the comment: Ned, thanks for the quick response. I will give that a go. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 06:33:29 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 24 Apr 2012 04:33:29 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335242009.82.0.389480681311.issue14605@psf.upfronthosting.co.za> Nick Coghlan added the comment: I put those explicit path checks in there deliberately. I really don't want to go back to having any __file__ attributes that are sensitive to sys.path changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 06:35:34 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 24 Apr 2012 04:35:34 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335242134.61.0.609519793523.issue14605@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oops: s/sensitive to sys.path changes/sensitive to current working directory changes/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 06:40:18 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 24 Apr 2012 04:40:18 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335242418.38.0.457809991662.issue14657@psf.upfronthosting.co.za> Nick Coghlan added the comment: My preference would also be for _frozen_importlib._bootstrap to overwrite as much evidence of itself as it can with the "real" one. This would also mean that changes to importlib._bootstrap would actually take effect for user code almost immediately, *without* rebuilding Python, as the frozen version would *only* be used to get hold of the pure Python version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 06:48:06 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 24 Apr 2012 04:48:06 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335242886.53.0.746191609338.issue14657@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 06:52:26 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 24 Apr 2012 04:52:26 +0000 Subject: [issue14654] More fast utf-8 decoding In-Reply-To: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za> Message-ID: <1335243146.39.0.214789344418.issue14654@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 06:54:28 2012 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 24 Apr 2012 04:54:28 +0000 Subject: [issue14369] make __closure__ writable In-Reply-To: <1332179477.04.0.11685261564.issue14369@psf.upfronthosting.co.za> Message-ID: <1335243268.13.0.492471464444.issue14369@psf.upfronthosting.co.za> Nick Coghlan added the comment: Another use case for a writeable __closure__ attribute is to make it possible to manually break reference cycles: http://blog.ccpgames.com/kristjan/2012/04/23/reference-cycles-with-closures/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 07:02:06 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 24 Apr 2012 05:02:06 +0000 Subject: [issue14655] traceback module docs should show how to print/fomat an exception object In-Reply-To: <1335216172.17.0.173976069373.issue14655@psf.upfronthosting.co.za> Message-ID: <1335243726.74.0.414035006375.issue14655@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 07:03:06 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 24 Apr 2012 05:03:06 +0000 Subject: [issue14647] imp.reload() on a package leads to a segfault or a GC assertion failure In-Reply-To: <1335136677.5.0.49699953472.issue14647@psf.upfronthosting.co.za> Message-ID: <1335243786.97.0.696086876318.issue14647@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 07:38:30 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 24 Apr 2012 05:38:30 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335245910.01.0.542822843495.issue13959@psf.upfronthosting.co.za> Eric Snow added the comment: updated patch for magic number support in imp/importlib ---------- Added file: http://bugs.python.org/file25335/issue13959_magic.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 07:40:10 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 24 Apr 2012 05:40:10 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335246010.87.0.446299470393.issue13959@psf.upfronthosting.co.za> Eric Snow added the comment: updated patch for moving TAG to importlib/imp.py ---------- Added file: http://bugs.python.org/file25336/issue13959_tag.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 08:37:16 2012 From: report at bugs.python.org (frank) Date: Tue, 24 Apr 2012 06:37:16 +0000 Subject: [issue14659] HP multi-thread environment python core in PyObject_GC_UnTrack Message-ID: <1335249436.07.0.574545520744.issue14659@psf.upfronthosting.co.za> New submission from frank : #0 0x1ffffffffdbaa480:0 in PyObject_GC_UnTrack () at Modules/gcmodule.c:1149 1149 Modules/gcmodule.c: No such file or directory. in Modules/gcmodule.c (gdb) where #0 0x1ffffffffdbaa480:0 in PyObject_GC_UnTrack () at Modules/gcmodule.c:1149 #1 0x1ffffffffdab7040:0 in tupledealloc () at Objects/tupleobject.c:137 #2 0x1ffffffffdb3c650:0 in code_dealloc () at Python/compile.c:169 #3 0x1ffffffffdc09e70:0 in func_dealloc () at Objects/funcobject.c:408 #4 0x1ffffffffda81390:0 in insertdict () at Objects/dictobject.c:390 #5 0x1ffffffffda82030:0 in PyDict_SetItem () at Objects/dictobject.c:533 #6 0x1ffffffffdb25cd0:0 in eval_frame () at Python/ceval.c:1681 #7 0x1ffffffffdb309d0:0 in PyEval_EvalCodeEx () at Python/ceval.c:2650 #8 0x1ffffffffdb2f9e0:0 in PyEval_EvalCode () at Python/ceval.c:537 #9 0x1ffffffffdb7aa10:0 in PyImport_ExecCodeModuleEx () at Python/import.c:621 #10 0x1ffffffffdb7a850:0 in PyImport_ExecCodeModule () at Python/import.c:588 who can help me, many thanks! ---------- components: Interpreter Core files: P160254_R1699958_120413075145.txt messages: 159120 nosy: njfrank priority: normal severity: normal status: open title: HP multi-thread environment python core in PyObject_GC_UnTrack type: crash versions: Python 2.6 Added file: http://bugs.python.org/file25337/P160254_R1699958_120413075145.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 09:14:06 2012 From: report at bugs.python.org (Hobs) Date: Tue, 24 Apr 2012 07:14:06 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1335182013.36.0.802943288691.issue3177@psf.upfronthosting.co.za> Message-ID: Hobs added the comment: I can see why this partial implementation of `operation` in this ver seems useless. But it is a placeholder for eventually providing Linux/Mac users with the same functionality as windows. The os.startfile() or shutil.launch() function can easily fill the gap left by the OS, which is what os does for lots of other missing OS features on one platform or another. I'll delete the OS9 ('mac') test comment and leave an implementation for those platforms up to others? `gui` is for software that intends to launch user's $EDITOR, vi, nano, emacs, etc. This is intended to generalize startfile to encompass a common pattern, e.g. in bzr, hg. Perhaps it doesn't belong in ver1 until we sort out all the other uncomfortable things about this patch. I'll test all the windows and linux exception possabilities and get back to you on what exceptions startfile() normally raises, and whether this implementation of shutil.launch() raises comparable exceptions. Cheers, H On Apr 23, 2012 7:53 PM, "Chris Rebert" wrote: > > Chris Rebert added the comment: > > `operation` seems questionable. IMO, the verbs seem stronger / more > important than mere optional suggestions (particularly "open" vs. "edit" > for files with read-only viewers), and only Windows supports them (so > anyone requiring that feature might as well just use startfile() directly). > By virtue of this function being cross-platform, we're kinda limited to > just supporting the lowest common denominator. > > Hobs, can you explain `gui`? > > Also, does startfile() raise exceptions for either of the basic error > conditions ("no such file" and "no associated application")? If not, I > believe using the lower-level ShellExecute ( > http://msdn.microsoft.com/en-us/library/windows/desktop/bb762153%28v=vs.85%29.aspx) or similar Windows API function would allow us to report such errors, as > the other platform implementations currently do. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 09:38:44 2012 From: report at bugs.python.org (frank) Date: Tue, 24 Apr 2012 07:38:44 +0000 Subject: [issue14659] HP multi-thread environment python core in PyObject_GC_UnTrack In-Reply-To: <1335249436.07.0.574545520744.issue14659@psf.upfronthosting.co.za> Message-ID: <1335253124.04.0.142285398667.issue14659@psf.upfronthosting.co.za> frank added the comment: in addtion, the version of our python is 2.3.4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 10:10:20 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 08:10:20 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335228102.81.0.191480459618.issue14657@psf.upfronthosting.co.za> Message-ID: <1335254938.3436.3.camel@localhost.localdomain> Antoine Pitrou added the comment: > So why the mutation? Are you that worried someone is going to import > importlib._bootstrap directly? Well, importing importlib *does* import importlib._bootstrap, and creates another copy of the module. importlib.__import__ is then wired to _bootstrap.__import__, which is different from the built-in __import__ (potentially using different globals, for example). > This also costs in development complexity because not only do you have > to run 'make' to get changes to be testable, but it also leads to > difficult debugging situations where if you are not totally sure you > got something working you won't find out until you see e.g. that the > standard I/O streams were not initialized. I'm worried that two different copies of importlib will lead to its own difficult debugging situations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 10:27:33 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Apr 2012 08:27:33 +0000 Subject: [issue14654] More fast utf-8 decoding In-Reply-To: <1335216193.84.0.395160670632.issue14654@psf.upfronthosting.co.za> Message-ID: <1335256196.2400.31.camel@raxxla> Serhiy Storchaka added the comment: Thank you, Antoine. It is interesting results, that on 64 bits greatly accelerated the case, which on 32 bits sped up a little. It was the pathology that a 2-byte to UCS1 was decoded in 1.5x slower than a 2-byte to UCS2. Interestingly, a small acceleration for the other cases are random deviations or consequential effect? Strange looks like the difference for ascii-only text, this branch is not affected by the patch. Except that the consequences of global optimization. The deceleration of the decoding of the 4-byte data is expected. Here is a patch, which is risky reception with signed numbers. For me, it shows the acceleration of a few percent in comparison with the previous patch. But I can not recommend it, it looks too hacker for such a small improvement. It will not work on the exotic platforms where signed numbers are implemented not as complement code (but Python is not supports such platforms). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 10:35:05 2012 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 24 Apr 2012 08:35:05 +0000 Subject: [issue14659] HP multi-thread environment python core in PyObject_GC_UnTrack In-Reply-To: <1335249436.07.0.574545520744.issue14659@psf.upfronthosting.co.za> Message-ID: <1335256505.49.0.83729769415.issue14659@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The complete call stack shows that Python is embedded in another application (OCPro). The issue is most probably with this application which makes a bad usage of the C Python API, or somehow overwrites memory. I suggest that you report this to the application developers. ---------- nosy: +amaury.forgeotdarc resolution: -> invalid status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 10:37:51 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Apr 2012 08:37:51 +0000 Subject: [issue14654] More fast utf-8 decoding In-Reply-To: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za> Message-ID: <1335256671.21.0.471656122985.issue14654@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file25338/utf8-signed.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 10:56:22 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 08:56:22 +0000 Subject: [issue14659] HP multi-thread environment python core in PyObject_GC_UnTrack In-Reply-To: <1335249436.07.0.574545520744.issue14659@psf.upfronthosting.co.za> Message-ID: <1335257782.98.0.123708845866.issue14659@psf.upfronthosting.co.za> Antoine Pitrou added the comment: In addition, Python 2.3.4 is completely outdated. The current supported versions are 2.7.x and 3.2.x. I recommend you upgrade your Python before posting further bug reports. ---------- nosy: +pitrou status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 11:06:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 09:06:19 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335242418.38.0.457809991662.issue14657@psf.upfronthosting.co.za> Message-ID: <1335258297.3436.8.camel@localhost.localdomain> Antoine Pitrou added the comment: > This would also mean that changes to importlib._bootstrap would > actually take effect for user code almost immediately, *without* > rebuilding Python, as the frozen version would *only* be used to get > hold of the pure Python version. Actually, _io, encodings and friends must be loaded before importlib gets imported from Python code, so you will still have __loader__ entries referencing the frozen importlib, unless you also rewrite these attributes. My desire here is not to hide _frozen_importlib, rather to avoid subtle issues with two instances of a module living in memory with separate global states. Whether it's the frozen version or the on-disk Python version that gets the preference is another question (a less important one in my mind). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 11:14:55 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 24 Apr 2012 09:14:55 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335258297.3436.8.camel@localhost.localdomain> Message-ID: <4F966F0B.5010800@egenix.com> Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> This would also mean that changes to importlib._bootstrap would >> actually take effect for user code almost immediately, *without* >> rebuilding Python, as the frozen version would *only* be used to get >> hold of the pure Python version. > > Actually, _io, encodings and friends must be loaded before importlib > gets imported from Python code, so you will still have __loader__ > entries referencing the frozen importlib, unless you also rewrite these > attributes. > > My desire here is not to hide _frozen_importlib, rather to avoid subtle > issues with two instances of a module living in memory with separate > global states. Whether it's the frozen version or the on-disk Python > version that gets the preference is another question (a less important > one in my mind). Why don't you freeze the whole importlib package to avoid all these issues ? As side effect, it will also load a little faster. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 11:54:08 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Apr 2012 09:54:08 +0000 Subject: [issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates In-Reply-To: <1315133370.95.0.855318807974.issue12892@psf.upfronthosting.co.za> Message-ID: <1335261248.36.0.924210945754.issue12892@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > * fix an error in the error handler for utf-16-le. (In, Python3.2 b'\xdc\x80\x00\x41'.decode('utf-16-be', 'ignore') returns "\x00" instead of "A" for some reason) The patch for issue14579 fixes this in Python 3.2. The patch for issue14624 fixes this in Python 3.3. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 13:01:37 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Apr 2012 11:01:37 +0000 Subject: [issue2857] Add "java modified utf-8" codec In-Reply-To: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za> Message-ID: <1335265297.03.0.881571661115.issue2857@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As far as I understand, this codec can be implemented in Python. There is no need to modify the interpreter core. def decode_cesu8(b): return re.sub('[\uD800-\uDBFF][\uDC00\DFFF]', lambda m: chr(0x10000 | ((ord(m.group()[0]) & 0x3FF) << 10) | (ord(m.group()[1]) & 0x3FF)), b.decode('utf-8', 'surrogatepass')) def encode_cesu8(s): return re.sub('[\U00010000-\U0010FFFF]', lambda m: chr(0xD800 | ((ord(m.group()) >> 10) & 0x3FF)) + chr(0xDC00 | (ord(m.group() & 0x3FF)), s).encode('utf-8', 'surrogatepass') def decode_mutf8(b): return decode_cesu8(b.replace(b'\xC0\x80', b'\x00')) def encode_mutf8(s): return encode_cesu8(s).replace(b'\x00', b'\xC0\x80') ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 13:08:40 2012 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 24 Apr 2012 11:08:40 +0000 Subject: [issue14660] Implement PEP 420: Implicit Namespace Packages Message-ID: <1335265720.13.0.725647299701.issue14660@psf.upfronthosting.co.za> New submission from Eric V. Smith : I have created a branch features/pep-420 where I'll be developing a proof of concept implementation of PEP 420. I've checked in a basic version, but it has these issues: - We need to decide how finders communicate that they've found part of a namespace package. Per Brett's suggestion, I'm currently returning a string that means "the returned path is part of a namespace package". I think that's an okay design. - I guess we need to create a "namespace loader", so we can initialize __loader__. It's a little odd because it would be a loader for which there's no need for a find_module method. I'm currently setting __loader__ to the finder, which is completely wrong, but keeps things working. - test_import and test_importlib both fail because they're checking that imports with no __init__.py fail. Those tests need to be removed. - There are no tests yet. ---------- assignee: eric.smith messages: 159131 nosy: barry, brett.cannon, eric.smith, jason.coombs priority: normal severity: normal status: open title: Implement PEP 420: Implicit Namespace Packages type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 13:22:06 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 24 Apr 2012 11:22:06 +0000 Subject: [issue14654] More fast utf-8 decoding In-Reply-To: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za> Message-ID: <1335266526.6.0.822959979186.issue14654@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm -1 on using signed char in the implementation. If this gives any advantage, it's because the compiler is not able to generate as efficient code for unsigned char as it does for signed char. So the performance results may again change if you switch compilers, or use the next compiler version. The code should do what is *logically* correct; IMO, UTF-8 is really a sequence of unsigned bytes, conceptually. So if you want to demonstrate any performance improvements, you need to do so with unsigned chars. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 13:28:54 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 24 Apr 2012 11:28:54 +0000 Subject: [issue2857] Add "java modified utf-8" codec In-Reply-To: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za> Message-ID: <1335266934.29.0.0321981806523.issue2857@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Serhiy: your functions to not constitute a Python codec. For example, there is no support for error handlers in them. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 13:54:00 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Apr 2012 11:54:00 +0000 Subject: [issue14654] More fast utf-8 decoding In-Reply-To: <1335266526.6.0.822959979186.issue14654@psf.upfronthosting.co.za> Message-ID: <1335268588.2400.44.camel@raxxla> Serhiy Storchaka added the comment: > I'm -1 on using signed char in the implementation. I completely agree with you, for these and for other not mentioned reasons. So I don't released this patch yesterday, and did not suggest it to accept. I showed him just out of curiosity -- whether the effect is stronger on a 64-bit platform? Although this technique will not be accepted, it sets the bar that can be achieved (if it's worth it). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 14:07:21 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 24 Apr 2012 12:07:21 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1335269241.92.0.0638703387144.issue14579@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Now I see the problem: make_decode_exception creates a new bytes object in any case, regardless of whether the error handler will update it or not. Therefore, decoding will continue in this new bytes object. I think the same issue also applies to the ASCII decoder in 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 14:07:37 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Apr 2012 12:07:37 +0000 Subject: [issue2857] Add "java modified utf-8" codec In-Reply-To: <1335266934.29.0.0321981806523.issue2857@psf.upfronthosting.co.za> Message-ID: <1335269405.2400.57.camel@raxxla> Serhiy Storchaka added the comment: > Serhiy: your functions to not constitute a Python codec. For example, there is no support for error handlers in them. Yes, it is not a codec in Python library terminology. It's just a pair of functions, the COder and DECoder, which is enough for the task of hacking Java serialized data. I don't think that such specific task leads to the change of the interpreter core. However, translators that convert the non-BMP characters to a surrogate pair and back, would be useful in the standard library. They need to work with a non-standard encodings (CESU-8, MUTF-8, cp65001, some Tk/IDLE issues). This is a fairly common task. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 14:26:37 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 24 Apr 2012 12:26:37 +0000 Subject: [issue2857] Add "java modified utf-8" codec In-Reply-To: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za> Message-ID: <1335270397.6.0.400950190881.issue2857@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ok, I'm closing this entire issue as "won't fix", then. There apparently is a need for functionality like this, but there is apparently also a concern that this is too specialized for the standard library. As it is possible to implement this as a stand-alone library, I encourage interested users to design a package for PyPI that has this functionality collected for reuse. If the library is then widely used after some time, this issue can be reconsidered. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 14:35:06 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Apr 2012 12:35:06 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1335269241.92.0.0638703387144.issue14579@psf.upfronthosting.co.za> Message-ID: <1335271055.2400.64.camel@raxxla> Serhiy Storchaka added the comment: > I think the same issue also applies to the ASCII decoder in 3.3. No, the ASCII decoder is not affected by this vulnerability. In a loop, in which unicode_decode_call_errorhandler is called, do not use any cached and not-updatable data. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 15:25:22 2012 From: report at bugs.python.org (Mark Shannon) Date: Tue, 24 Apr 2012 13:25:22 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1335273922.44.0.212856295864.issue13903@psf.upfronthosting.co.za> Mark Shannon added the comment: Failing to maintain GC tracking in setdefault and copy (for split-tables) Patch attached ---------- Added file: http://bugs.python.org/file25339/gc_tracking.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 15:58:18 2012 From: report at bugs.python.org (Anthony Kong) Date: Tue, 24 Apr 2012 13:58:18 +0000 Subject: [issue14658] Overwriting dict.__getattr__ is inconsistent In-Reply-To: <1335221613.52.0.779214050633.issue14658@psf.upfronthosting.co.za> Message-ID: <1335275898.89.0.188285598818.issue14658@psf.upfronthosting.co.za> Changes by Anthony Kong : ---------- nosy: +Anthony.Kong _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 16:01:37 2012 From: report at bugs.python.org (Stefano Taschini) Date: Tue, 24 Apr 2012 14:01:37 +0000 Subject: [issue1065986] Fix pydoc crashing on unicode strings Message-ID: <1335276097.25.0.558257586721.issue1065986@psf.upfronthosting.co.za> Stefano Taschini added the comment: Shouldn't this be reopened for Python 2.7 ? ---------- type: -> behavior versions: +Python 2.7 -Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 16:13:40 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 24 Apr 2012 14:13:40 +0000 Subject: [issue1065986] Fix pydoc crashing on unicode strings Message-ID: <1335276820.79.0.434600291964.issue1065986@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think so. We aren't promising unicode support in pydoc in 2.x, and it is too late to add it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 16:18:46 2012 From: report at bugs.python.org (Mark Shannon) Date: Tue, 24 Apr 2012 14:18:46 +0000 Subject: [issue14658] Overwriting dict.__getattr__ is inconsistent In-Reply-To: <1335221613.52.0.779214050633.issue14658@psf.upfronthosting.co.za> Message-ID: <1335277126.47.0.443809582104.issue14658@psf.upfronthosting.co.za> Changes by Mark Shannon : ---------- nosy: +Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 16:28:31 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 24 Apr 2012 14:28:31 +0000 Subject: [issue11603] Python crashes or hangs when rebinding __repr__ as __str__ In-Reply-To: <1300482917.38.0.116490632242.issue11603@psf.upfronthosting.co.za> Message-ID: <1335277711.8.0.263566654872.issue11603@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I claim the correct behavior of this is actually to give an recursion provoked RuntimeError. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 16:34:01 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 14:34:01 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 507a6703d6a3 by Benjamin Peterson in branch 'default': fix dict gc tracking (#13903) http://hg.python.org/cpython/rev/507a6703d6a3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 16:36:58 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 24 Apr 2012 14:36:58 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1335278218.22.0.703532987884.issue10941@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: My bad. For some reason I assumed that the latest patch would be at the top of the files list. David, the patch is good. Should I go ahead and commit? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 16:40:00 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 24 Apr 2012 14:40:00 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335278400.65.0.969055425869.issue14605@psf.upfronthosting.co.za> Brett Cannon added the comment: Of course you did because you just like making my life a living hell when it comes to the __file__ attribute. =) OK, I will have another look when I get home, but last time I dealt with this the issue is some tests expect a relative path while others expect an absolute one. And allowing an empty string for the current directory is just evil. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 16:42:25 2012 From: report at bugs.python.org (Joe Peterson) Date: Tue, 24 Apr 2012 14:42:25 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1335278545.3.0.204527576725.issue10941@psf.upfronthosting.co.za> Joe Peterson added the comment: Great to hear, Alexander. Thanks for reviewing! Is it also possible to get the pyhton2.7 version one in? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 16:42:33 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 24 Apr 2012 14:42:33 +0000 Subject: [issue14660] Implement PEP 420: Implicit Namespace Packages In-Reply-To: <1335265720.13.0.725647299701.issue14660@psf.upfronthosting.co.za> Message-ID: <1335278553.48.0.432874788761.issue14660@psf.upfronthosting.co.za> Brett Cannon added the comment: Loaders are not meant to have a find_module method; that is purely for finders which can be distinct objects. So having a namespace loader is expected and there is no expectation that it have a find_module method (actually almost all of the loaders in importlib lack a find_module method). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 16:47:33 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 24 Apr 2012 14:47:33 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1335278545.3.0.204527576725.issue10941@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: On Tue, Apr 24, 2012 at 10:42 AM, Joe Peterson wrote: .. > ?Is it also possible to get the pyhton2.7 version one in? I don't see any reason not to. This is a bug fix and should go into a maintenance release. I will wait to hear from David, who is the maintainer of this module, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 16:49:40 2012 From: report at bugs.python.org (Lohoris) Date: Tue, 24 Apr 2012 14:49:40 +0000 Subject: [issue13756] Python3.2.2 make fail on cygwin In-Reply-To: <1326199459.04.0.575648132034.issue13756@psf.upfronthosting.co.za> Message-ID: <1335278980.63.0.73930617452.issue13756@psf.upfronthosting.co.za> Changes by Lohoris : ---------- nosy: +Lohoris type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 16:52:03 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 24 Apr 2012 14:52:03 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1335278400.65.0.969055425869.issue14605@psf.upfronthosting.co.za> Message-ID: <4F96BE10.5080402@egenix.com> Marc-Andre Lemburg added the comment: Brett Cannon wrote: > I am not exposing SourcelessFileLoader because importlib publicly tries to discourage the shipping of .pyc files w/o their corresponding source files. Otherwise all objects as used by importlib for performing imports will become public. What's the reasoning behind this idea ? Is Python 3.3 no longer meant to be used for closed source applications ? ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 17:00:32 2012 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 24 Apr 2012 15:00:32 +0000 Subject: [issue14660] Implement PEP 420: Implicit Namespace Packages In-Reply-To: <1335265720.13.0.725647299701.issue14660@psf.upfronthosting.co.za> Message-ID: <1335279632.96.0.544114569879.issue14660@psf.upfronthosting.co.za> Eric V. Smith added the comment: Right, that's a typo. I meant load_module(). I'm currently working on implementing the loader for namespace modules, so my comment about the loader is premature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 17:04:58 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 24 Apr 2012 15:04:58 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: <1335279898.03.0.724540672796.issue10941@psf.upfronthosting.co.za> R. David Murray added the comment: If you are satisfied with the time logic then yes, please apply it. I suspect that the number of people using the code and not aware of the problem (or not caring enough to do anything about it) exceeds the number aware of it who have coded a workaround, so I think putting it in 2.7 (and 3.2) is better than not doing so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 17:09:29 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 15:09:29 +0000 Subject: [issue11603] Python crashes or hangs when rebinding __repr__ as __str__ In-Reply-To: <1300482917.38.0.116490632242.issue11603@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 971865f12377 by Benjamin Peterson in branch '3.2': don't use a slot wrapper from a different special method (closes #14658) http://hg.python.org/cpython/rev/971865f12377 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 17:09:29 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 15:09:29 +0000 Subject: [issue14658] Overwriting dict.__getattr__ is inconsistent In-Reply-To: <1335221613.52.0.779214050633.issue14658@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 971865f12377 by Benjamin Peterson in branch '3.2': don't use a slot wrapper from a different special method (closes #14658) http://hg.python.org/cpython/rev/971865f12377 New changeset 0c1c8f8955d8 by Benjamin Peterson in branch 'default': merge 3.2 (#14658) http://hg.python.org/cpython/rev/0c1c8f8955d8 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 17:10:19 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 24 Apr 2012 15:10:19 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335280219.42.0.834697229717.issue14657@psf.upfronthosting.co.za> Brett Cannon added the comment: To start, I'm *not* going to make the final call on this issue's solution. I'm inches away from importlib burnout and general integration frustration with trying to clean up the implicit behaviour. So to prevent me from making a bad decision I will you guys make the final call. Anyway, I see two options here. One is the "let _frozen_importlib be *the* implementation, period" argument put forth by Antoine (MAL's "freeze everything" also falls under this since it suffers from the same issues). This is the easiest solution for the issue of not having overlapping implementations and cause potential mix-ups, etc. The issue becomes development difficulty goes up as now you are adding a compile step where if you screw up you can get really bad error messages (e.g. "standard streams could not be created" kind of stuff). This could theoretically be overcome if the importlib tests all used a manually created module directly from the source code to verify things before rebuilding (as well as making sure sys.path_importer_cache was cleaned out). With a restructuring of importlib's tests to use a common TestCase with the proper setUp()/teardown() for keeping things clean along with class and module fixtures to prevent obscene stuff like re-importing for every test method. Another option is we hide the source as _importlib or something to allow direct importation w/o any tricks under a protected name. Then there is Nick's proposal of using _frozen_importlib to start up and then swap out with a new version created from the source during startup. This keeps development simple since the tests run against the code *almost* all other code will use and thus eliminate the test. The problem here is that startup is a smidgen slower and it requires you blacklist what needs to get swapped out and if you mess up that will be tough to debug as well. Both get the same outcome but with different approaches, it's just a question of which one is easiest to maintain. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 17:10:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 15:10:31 +0000 Subject: [issue14658] Overwriting dict.__getattr__ is inconsistent In-Reply-To: <1335221613.52.0.779214050633.issue14658@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e3eda2d91e93 by Benjamin Peterson in branch '2.7': don't use a slot wrapper from a different special method (closes #14658) http://hg.python.org/cpython/rev/e3eda2d91e93 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 17:10:31 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 15:10:31 +0000 Subject: [issue11603] Python crashes or hangs when rebinding __repr__ as __str__ In-Reply-To: <1300482917.38.0.116490632242.issue11603@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e3eda2d91e93 by Benjamin Peterson in branch '2.7': don't use a slot wrapper from a different special method (closes #14658) http://hg.python.org/cpython/rev/e3eda2d91e93 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 17:12:43 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 24 Apr 2012 15:12:43 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335280363.22.0.807702965043.issue14605@psf.upfronthosting.co.za> Brett Cannon added the comment: That initial comment is out-of-date. If you look that the commit I made I documented importlib.machinery._SourcelessFileLoader. I am continuing the discouragement of using bytecode files as an obfuscation technique (because it's a bad one), but I decided to at least document the class so people can use it at their own peril and know about it if they happen to come across the object during execution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 17:16:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 15:16:11 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335280219.42.0.834697229717.issue14657@psf.upfronthosting.co.za> Message-ID: <1335280488.3436.9.camel@localhost.localdomain> Antoine Pitrou added the comment: Le mardi 24 avril 2012 ? 15:10 +0000, Brett Cannon a ?crit : > Both get the same outcome but with different approaches, it's just a > question of which one is easiest to maintain. I don't have any strong preference. Nick's proposal sounds slightly better but Nick hasn't uploaded a patch yet :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 17:22:53 2012 From: report at bugs.python.org (Sandro Tosi) Date: Tue, 24 Apr 2012 15:22:53 +0000 Subject: [issue13934] sqlite3 test typo In-Reply-To: <1328294661.43.0.135509150445.issue13934@psf.upfronthosting.co.za> Message-ID: <1335280973.77.0.723878745544.issue13934@psf.upfronthosting.co.za> Sandro Tosi added the comment: poq, would you like to also prepare a patch for the documentation with what Thomas suggested? I'd be happy to review when ready ---------- nosy: +sandro.tosi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 17:26:42 2012 From: report at bugs.python.org (Stefano Taschini) Date: Tue, 24 Apr 2012 15:26:42 +0000 Subject: [issue1065986] Fix pydoc crashing on unicode strings Message-ID: <1335281202.59.0.557202642342.issue1065986@psf.upfronthosting.co.za> Stefano Taschini added the comment: Oh well, in that case I guess we'll have to work around it. Here's the monkey patch I use to overcome this limitation in pydoc, in case others wish to add it to their PYTHONSTARTUP or sitecustomize: def pipepager(text, cmd): """Page through text by feeding it to another program.""" try: import locale except ImportError: encoding = "ascii" else: encoding = locale.getpreferredencoding() pipe = os.popen(cmd, 'w') try: pipe.write(text.encode(encoding, 'xmlcharrefreplace') if isinstance(text, unicode) else text) pipe.close() except IOError: pass # Ignore broken pipes caused by quitting the pager program. import pydoc pydoc.pipepager = pipepager del pydoc, pipepager ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 17:37:49 2012 From: report at bugs.python.org (Mark Shannon) Date: Tue, 24 Apr 2012 15:37:49 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1335281869.13.0.53424044835.issue13903@psf.upfronthosting.co.za> Mark Shannon added the comment: Failed to differentiate between failure and error in make_split_table(). Patch attached ---------- Added file: http://bugs.python.org/file25340/make_split_table_error.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 17:37:59 2012 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 24 Apr 2012 15:37:59 +0000 Subject: [issue14660] Implement PEP 420: Implicit Namespace Packages In-Reply-To: <1335265720.13.0.725647299701.issue14660@psf.upfronthosting.co.za> Message-ID: <1335281879.19.0.607267120297.issue14660@psf.upfronthosting.co.za> Eric V. Smith added the comment: I created the NamespaceLoader in the feature branch. It has a load_module, but it's only ever called by the code in PathFinder.load_module: loader = NamespaceLoader(namespace_path) return loader.load_module(fullname) namespace_path is what will become module.__path__. In order to keep the load_module API (single fullname argument), I pass it in to the constructor. There's no particular need for it to follow that API, but it does. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 17:38:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 15:38:45 +0000 Subject: [issue13587] Correcting the typos error in Doc/howto/urllib2.rst In-Reply-To: <1323693654.01.0.260479490427.issue13587@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 4dda3000c932 by Sandro Tosi in branch '2.7': Issue #13587: use the right RFC2617 name for WWW-Authenticate; patch by Aaron Maenpaa http://hg.python.org/cpython/rev/4dda3000c932 New changeset 01abffa8842a by Sandro Tosi in branch '3.2': Issue #13587: use the right RFC2617 name for WWW-Authenticate; patch by Aaron Maenpaa http://hg.python.org/cpython/rev/01abffa8842a New changeset 798b9714777d by Sandro Tosi in branch 'default': Issue #13587: merge with 3.2 http://hg.python.org/cpython/rev/798b9714777d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 17:39:21 2012 From: report at bugs.python.org (Sandro Tosi) Date: Tue, 24 Apr 2012 15:39:21 +0000 Subject: [issue13587] Correcting the typos error in Doc/howto/urllib2.rst In-Reply-To: <1323693654.01.0.260479490427.issue13587@psf.upfronthosting.co.za> Message-ID: <1335281961.29.0.356037579716.issue13587@psf.upfronthosting.co.za> Sandro Tosi added the comment: Aaron: thanks for the patch! ---------- nosy: +sandro.tosi resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 17:57:17 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 24 Apr 2012 15:57:17 +0000 Subject: [issue14660] Implement PEP 420: Implicit Namespace Packages In-Reply-To: <1335265720.13.0.725647299701.issue14660@psf.upfronthosting.co.za> Message-ID: <1335283037.77.0.193603849495.issue14660@psf.upfronthosting.co.za> Brett Cannon added the comment: Yeah, having to pass in the name to load_module is silly. I'm seriously considering making it optional for some loaders when the name was passed in to the constructor. One thing I would like to see is that PathFinder take a new, keyword-only argument of 'namespace_loader' or something that takes an object which is called with the module name and the list of paths to use for __path__ (and thus __path__[0] becomes __file__). That way it can be controlled by users if desired. I'm also fine with it having a default value of NamespaceLoader to start since I don't see people needing to comprehend what they are allowing in this case as I do for general file loaders. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 18:06:07 2012 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 24 Apr 2012 16:06:07 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1335283567.01.0.231980598565.issue13903@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: -giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 18:14:01 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 16:14:01 +0000 Subject: [issue13478] No documentation for timeit.default_timer In-Reply-To: <1322208815.17.0.598781679655.issue13478@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 86b927859155 by Sandro Tosi in branch '2.7': Issue #13478: document timeit.default_timer() http://hg.python.org/cpython/rev/86b927859155 New changeset 8165b59a4000 by Sandro Tosi in branch '3.2': Issue #13478: document timeit.default_timer() http://hg.python.org/cpython/rev/8165b59a4000 New changeset e43ba06da592 by Sandro Tosi in branch 'default': Issue #13478: merge with 3.2 http://hg.python.org/cpython/rev/e43ba06da592 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 18:14:19 2012 From: report at bugs.python.org (Sandro Tosi) Date: Tue, 24 Apr 2012 16:14:19 +0000 Subject: [issue13478] No documentation for timeit.default_timer In-Reply-To: <1322208815.17.0.598781679655.issue13478@psf.upfronthosting.co.za> Message-ID: <1335284059.49.0.541537735692.issue13478@psf.upfronthosting.co.za> Changes by Sandro Tosi : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 18:27:03 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 24 Apr 2012 16:27:03 +0000 Subject: [issue1065986] Fix pydoc crashing on unicode strings Message-ID: <1335284823.39.0.888866433544.issue1065986@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. Making it not raise an error while still producing useful output would be acceptable as a bug fix if that's all it takes, I think. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 18:36:21 2012 From: report at bugs.python.org (Pino Toscano) Date: Tue, 24 Apr 2012 16:36:21 +0000 Subject: [issue14661] posix module: add O_EXEC, O_SEARCH, O_TTY_INIT Message-ID: <1335285381.34.0.139492231306.issue14661@psf.upfronthosting.co.za> New submission from Pino Toscano : The posix module exposes already quite some O_* constants, but it misses few POSIX ones (see [1]), but it misses O_EXEC, O_SEARCH, and O_TTY_INIT. The attached patch adds them. [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fcntl.h.html ---------- files: fcntl_h_constants.diff keywords: patch messages: 159168 nosy: pino priority: normal severity: normal status: open title: posix module: add O_EXEC, O_SEARCH, O_TTY_INIT type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25341/fcntl_h_constants.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 18:41:35 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 16:41:35 +0000 Subject: [issue14554] test module: correction In-Reply-To: <1334181755.32.0.776262768406.issue14554@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 22767284de99 by Sandro Tosi in branch '2.7': Issue #14554: correct example for captured_stdout() http://hg.python.org/cpython/rev/22767284de99 New changeset d1ba0421d65f by Sandro Tosi in branch '3.2': Issue #14554: correct example for captured_stdout(); patch by Tshepang Lekhonkhobe http://hg.python.org/cpython/rev/d1ba0421d65f New changeset 6f41f8ed87c8 by Sandro Tosi in branch 'default': Issue #14554: merge with 3.2 http://hg.python.org/cpython/rev/6f41f8ed87c8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 18:42:03 2012 From: report at bugs.python.org (Sandro Tosi) Date: Tue, 24 Apr 2012 16:42:03 +0000 Subject: [issue14554] test module: correction In-Reply-To: <1334181755.32.0.776262768406.issue14554@psf.upfronthosting.co.za> Message-ID: <1335285723.55.0.321716582679.issue14554@psf.upfronthosting.co.za> Sandro Tosi added the comment: Thanks for the patch, Tshepang! ---------- nosy: +sandro.tosi resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 18:49:05 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 24 Apr 2012 16:49:05 +0000 Subject: [issue14653] Improve mktime_tz to use calendar.timegm instead of time.mktime In-Reply-To: <1335213212.56.0.724242644314.issue14653@psf.upfronthosting.co.za> Message-ID: <1335286145.71.0.660775248989.issue14653@psf.upfronthosting.co.za> R. David Murray added the comment: I think that what is going to happen is that both of these functions are going to be deprecated in favor of functions that use datetimes. That said, this might be a worthwhile as a bug fix. I'm adding Alexander as nosy to see what he thinks. (mktime_tz is located in email.utils, with the source in Lib/email/_parseaddr.py). ---------- assignee: -> r.david.murray nosy: +belopolsky, r.david.murray versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 19:14:39 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 17:14:39 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b044e0568be2 by Martin v. Loewis in branch 'default': Account for shared keys in type's __sizeof__ (#13903). http://hg.python.org/cpython/rev/b044e0568be2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 19:37:01 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 24 Apr 2012 17:37:01 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335280219.42.0.834697229717.issue14657@psf.upfronthosting.co.za> Message-ID: <4F96E4B9.9030208@egenix.com> Marc-Andre Lemburg added the comment: test me thod. Another option is we hide the source as _importlib or something to allow direct importation w/o any tricks under a protected name. Using the freeze everything approach you make things easier for the implementation, since you don't have to think about whether certain pieces of code are already available or not. For development, you can also have the package load bytecode or source from an external package instead of running (all of) the module's bytecode that was compiled into the binary. This is fairly easy to do, since the needed exec() does not depend on the import machinery. The only downside is big if statement to isolate the frozen version from the loaded one - would be great if we had a command to stop module execution or code execution for a block to make that more elegant, e.g. "break" at module scope :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 19:40:57 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 17:40:57 +0000 Subject: [issue14661] posix module: add O_EXEC, O_SEARCH, O_TTY_INIT In-Reply-To: <1335285381.34.0.139492231306.issue14661@psf.upfronthosting.co.za> Message-ID: <1335289257.43.0.248757077006.issue14661@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +neologix stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 19:46:16 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Apr 2012 17:46:16 +0000 Subject: [issue14654] More fast utf-8 decoding In-Reply-To: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za> Message-ID: <1335289716.2400.169.camel@raxxla> Serhiy Storchaka added the comment: Here are two new patches. The first one takes into account the Martin wishes about comments. The second also rejects optimization for ASCII. On the Intel Atom last patch annihilates acceleration for some cases (mostly-ascii with UCS2 data): vanilla patch1 patch3 utf-8 'A'*9999+'\u0100' 124 (+8%) 288 (-53%) 134 utf-8 'A'*9999+'\u8000' 124 (+8%) 291 (-54%) 134 utf-8 '\u0100'+'A'*9999 78 (+5%) 123 (-33%) 82 utf-8 '\u8000'+'A'*9999 78 (+5%) 124 (-34%) 82 On the AMD Athlon there is no noticeable effect. ---------- Added file: http://bugs.python.org/file25342/decode_utf8_2.patch Added file: http://bugs.python.org/file25343/decode_utf8_3.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r c820aa9c0c00 Objects/stringlib/codecs.h --- a/Objects/stringlib/codecs.h Fri Apr 20 18:04:03 2012 -0400 +++ b/Objects/stringlib/codecs.h Tue Apr 24 19:51:31 2012 +0300 @@ -21,7 +21,6 @@ const char **src_pos, Py_ssize_t *dest_index) { int ret; - Py_ssize_t n; const char *s = start; const char *aligned_end = (const char *) ((size_t) end & ~LONG_PTR_MASK); STRINGLIB_CHAR *p = dest; @@ -48,15 +47,33 @@ unsigned long value = *(unsigned long *) _s; if (value & ASCII_CHAR_MASK) break; - _p[0] = _s[0]; - _p[1] = _s[1]; - _p[2] = _s[2]; - _p[3] = _s[3]; -#if (SIZEOF_LONG == 8) - _p[4] = _s[4]; - _p[5] = _s[5]; - _p[6] = _s[6]; - _p[7] = _s[7]; +#ifdef BYTEORDER_IS_LITTLE_ENDIAN + _p[0] = (STRINGLIB_CHAR)(value & 0xFFu); + _p[1] = (STRINGLIB_CHAR)((value >> 8) & 0xFFu); + _p[2] = (STRINGLIB_CHAR)((value >> 16) & 0xFFu); + _p[3] = (STRINGLIB_CHAR)((value >> 24) & 0xFFu); +#if SIZEOF_LONG == 8 + _p[4] = (STRINGLIB_CHAR)((value >> 32) & 0xFFu); + _p[5] = (STRINGLIB_CHAR)((value >> 40) & 0xFFu); + _p[6] = (STRINGLIB_CHAR)((value >> 48) & 0xFFu); + _p[7] = (STRINGLIB_CHAR)((value >> 56) & 0xFFu); +#endif +#else +#if SIZEOF_LONG == 8 + _p[0] = (STRINGLIB_CHAR)((value >> 56) & 0xFFu); + _p[1] = (STRINGLIB_CHAR)((value >> 48) & 0xFFu); + _p[2] = (STRINGLIB_CHAR)((value >> 40) & 0xFFu); + _p[3] = (STRINGLIB_CHAR)((value >> 32) & 0xFFu); + _p[4] = (STRINGLIB_CHAR)((value >> 24) & 0xFFu); + _p[5] = (STRINGLIB_CHAR)((value >> 16) & 0xFFu); + _p[6] = (STRINGLIB_CHAR)((value >> 8) & 0xFFu); + _p[7] = (STRINGLIB_CHAR)(value & 0xFFu); +#else + _p[0] = (STRINGLIB_CHAR)((value >> 24) & 0xFFu); + _p[1] = (STRINGLIB_CHAR)((value >> 16) & 0xFFu); + _p[2] = (STRINGLIB_CHAR)((value >> 8) & 0xFFu); + _p[3] = (STRINGLIB_CHAR)(value & 0xFFu); +#endif #endif _s += SIZEOF_LONG; _p += SIZEOF_LONG; @@ -67,78 +84,114 @@ break; ch = (unsigned char)*s; } + if (ch < 0x80) { + s++; + *p++ = ch; + continue; + } } - if (ch < 0x80) { - s++; + if (ch < 0xC2) { + /* invalid sequence + \x80-\xBF -- continuation byte + \xC0-\xC1 -- fake 0000-007F */ + goto _error; + } + + if (ch < 0xE0) { + /* \xC2\x80-\xDF\xBF -- 0080-07FF */ + Py_UCS4 ch2; + if (end - s < 2) { + /* unexpected end of data: the caller will decide whether + it's an error or not */ + goto _error; + } + ch2 = (unsigned char)s[1]; + if ((ch2 & 0xc0) != 0x80) + /* invalid continuation byte */ + goto _error; + ch = (ch << 6) + ch2 - 030200; + assert ((ch > 0x007F) && (ch <= 0x07FF)); + s += 2; *p++ = ch; continue; } - n = utf8_code_length[ch]; - - if (s + n > end) { - /* unexpected end of data: the caller will decide whether - it's an error or not */ - goto _error; - } - - switch (n) { - case 0: - /* invalid start byte */ - goto _error; - case 1: - /* internal error */ - goto _error; - case 2: - if ((s[1] & 0xc0) != 0x80) - /* invalid continuation byte */ +#if STRINGLIB_SIZEOF_CHAR >= 2 + if (ch < 0xF0) { + /* \xE0\xA0\x80-\xEF\xBF\xBF -- 0800-FFFF */ + Py_UCS4 ch2, ch3; + if (end - s < 3) { + /* unexpected end of data: the caller will decide whether + it's an error or not */ goto _error; - ch = ((s[0] & 0x1f) << 6) + (s[1] & 0x3f); - assert ((ch > 0x007F) && (ch <= 0x07FF)); - s += 2; - *p++ = ch; - break; - - case 3: - /* Decoding UTF-8 sequences in range \xed\xa0\x80-\xed\xbf\xbf - will result in surrogates in range d800-dfff. Surrogates are - not valid UTF-8 so they are rejected. - See http://www.unicode.org/versions/Unicode5.2.0/ch03.pdf - (table 3-7) and http://www.rfc-editor.org/rfc/rfc3629.txt */ - if ((s[1] & 0xc0) != 0x80 || - (s[2] & 0xc0) != 0x80 || - ((unsigned char)s[0] == 0xE0 && - (unsigned char)s[1] < 0xA0) || - ((unsigned char)s[0] == 0xED && - (unsigned char)s[1] > 0x9F)) { + } + ch2 = (unsigned char)s[1]; + ch3 = (unsigned char)s[2]; + if ((ch2 & 0xc0) != 0x80 || + (ch3 & 0xc0) != 0x80) { /* invalid continuation byte */ goto _error; } - ch = ((s[0] & 0x0f) << 12) + ((s[1] & 0x3f) << 6) + (s[2] & 0x3f); + if (ch == 0xE0) { + if (ch2 < 0xA0) + /* invalid sequence + \xE0\x80\x80-\xE0\x9F\xBF -- fake 0000-0800 */ + goto _error; + } + else if (ch == 0xED && ch2 > 0x9F) { + /* Decoding UTF-8 sequences in range \xED\xA0\x80-\xED\xBF\xBF + will result in surrogates in range D800-DFFF. Surrogates are + not valid UTF-8 so they are rejected. + See http://www.unicode.org/versions/Unicode5.2.0/ch03.pdf + (table 3-7) and http://www.rfc-editor.org/rfc/rfc3629.txt */ + goto _error; + } + ch = (ch << 12) + (ch2 << 6) + ch3 - 03420200; assert ((ch > 0x07FF) && (ch <= 0xFFFF)); s += 3; *p++ = ch; - break; + continue; + } - case 4: - if ((s[1] & 0xc0) != 0x80 || - (s[2] & 0xc0) != 0x80 || - (s[3] & 0xc0) != 0x80 || - ((unsigned char)s[0] == 0xF0 && - (unsigned char)s[1] < 0x90) || - ((unsigned char)s[0] == 0xF4 && - (unsigned char)s[1] > 0x8F)) { +#if STRINGLIB_SIZEOF_CHAR >= 4 + if (ch < 0xF5) { + /* \xF0\x90\x80\80-\xF4\x8F\xBF\xBF -- 10000-10FFFF */ + Py_UCS4 ch2, ch3, ch4; + if (end - s < 4) { + /* unexpected end of data: the caller will decide whether + it's an error or not */ + goto _error; + } + ch2 = (unsigned char)s[1]; + ch3 = (unsigned char)s[2]; + ch4 = (unsigned char)s[3]; + if ((ch2 & 0xc0) != 0x80 || + (ch3 & 0xc0) != 0x80 || + (ch4 & 0xc0) != 0x80) { /* invalid continuation byte */ goto _error; } - ch = ((s[0] & 0x7) << 18) + ((s[1] & 0x3f) << 12) + - ((s[2] & 0x3f) << 6) + (s[3] & 0x3f); + if (ch == 0xF0) { + if (ch2 < 0x90) + /* invalid sequence + \xF0\x80\x80\80-\xF0\x80\xBF\xBF -- fake 0000-FFFF */ + goto _error; + } + else if (ch == 0xF4 && ch2 > 0x8F) { + /* invalid sequence + \xF4\x90\x80\80- -- 110000- overflow */ + goto _error; + } + ch = (ch << 18) + (ch2 << 12) + (ch3 << 6) + ch4 - 0362020200; assert ((ch > 0xFFFF) && (ch <= 0x10ffff)); s += 4; *p++ = ch; - break; + continue; } +#endif +#endif + goto _error; } ret = 0; goto _ok; -------------- next part -------------- diff -r c820aa9c0c00 Objects/stringlib/codecs.h --- a/Objects/stringlib/codecs.h Fri Apr 20 18:04:03 2012 -0400 +++ b/Objects/stringlib/codecs.h Tue Apr 24 19:12:40 2012 +0300 @@ -21,7 +21,6 @@ const char **src_pos, Py_ssize_t *dest_index) { int ret; - Py_ssize_t n; const char *s = start; const char *aligned_end = (const char *) ((size_t) end & ~LONG_PTR_MASK); STRINGLIB_CHAR *p = dest; @@ -67,78 +66,114 @@ break; ch = (unsigned char)*s; } + if (ch < 0x80) { + s++; + *p++ = ch; + continue; + } } - if (ch < 0x80) { - s++; + if (ch < 0xC2) { + /* invalid sequence + \x80-\xBF -- continuation byte + \xC0-\xC1 -- fake 0000-007F */ + goto _error; + } + + if (ch < 0xE0) { + /* \xC2\x80-\xDF\xBF -- 0080-07FF */ + Py_UCS4 ch2; + if (end - s < 2) { + /* unexpected end of data: the caller will decide whether + it's an error or not */ + goto _error; + } + ch2 = (unsigned char)s[1]; + if ((ch2 & 0xc0) != 0x80) + /* invalid continuation byte */ + goto _error; + ch = (ch << 6) + ch2 - 030200; + assert ((ch > 0x007F) && (ch <= 0x07FF)); + s += 2; *p++ = ch; continue; } - n = utf8_code_length[ch]; - - if (s + n > end) { - /* unexpected end of data: the caller will decide whether - it's an error or not */ - goto _error; - } - - switch (n) { - case 0: - /* invalid start byte */ - goto _error; - case 1: - /* internal error */ - goto _error; - case 2: - if ((s[1] & 0xc0) != 0x80) - /* invalid continuation byte */ +#if STRINGLIB_SIZEOF_CHAR >= 2 + if (ch < 0xF0) { + /* \xE0\xA0\x80-\xEF\xBF\xBF -- 0800-FFFF */ + Py_UCS4 ch2, ch3; + if (end - s < 3) { + /* unexpected end of data: the caller will decide whether + it's an error or not */ goto _error; - ch = ((s[0] & 0x1f) << 6) + (s[1] & 0x3f); - assert ((ch > 0x007F) && (ch <= 0x07FF)); - s += 2; - *p++ = ch; - break; - - case 3: - /* Decoding UTF-8 sequences in range \xed\xa0\x80-\xed\xbf\xbf - will result in surrogates in range d800-dfff. Surrogates are - not valid UTF-8 so they are rejected. - See http://www.unicode.org/versions/Unicode5.2.0/ch03.pdf - (table 3-7) and http://www.rfc-editor.org/rfc/rfc3629.txt */ - if ((s[1] & 0xc0) != 0x80 || - (s[2] & 0xc0) != 0x80 || - ((unsigned char)s[0] == 0xE0 && - (unsigned char)s[1] < 0xA0) || - ((unsigned char)s[0] == 0xED && - (unsigned char)s[1] > 0x9F)) { + } + ch2 = (unsigned char)s[1]; + ch3 = (unsigned char)s[2]; + if ((ch2 & 0xc0) != 0x80 || + (ch3 & 0xc0) != 0x80) { /* invalid continuation byte */ goto _error; } - ch = ((s[0] & 0x0f) << 12) + ((s[1] & 0x3f) << 6) + (s[2] & 0x3f); + if (ch == 0xE0) { + if (ch2 < 0xA0) + /* invalid sequence + \xE0\x80\x80-\xE0\x9F\xBF -- fake 0000-0800 */ + goto _error; + } + else if (ch == 0xED && ch2 > 0x9F) { + /* Decoding UTF-8 sequences in range \xED\xA0\x80-\xED\xBF\xBF + will result in surrogates in range D800-DFFF. Surrogates are + not valid UTF-8 so they are rejected. + See http://www.unicode.org/versions/Unicode5.2.0/ch03.pdf + (table 3-7) and http://www.rfc-editor.org/rfc/rfc3629.txt */ + goto _error; + } + ch = (ch << 12) + (ch2 << 6) + ch3 - 03420200; assert ((ch > 0x07FF) && (ch <= 0xFFFF)); s += 3; *p++ = ch; - break; + continue; + } - case 4: - if ((s[1] & 0xc0) != 0x80 || - (s[2] & 0xc0) != 0x80 || - (s[3] & 0xc0) != 0x80 || - ((unsigned char)s[0] == 0xF0 && - (unsigned char)s[1] < 0x90) || - ((unsigned char)s[0] == 0xF4 && - (unsigned char)s[1] > 0x8F)) { +#if STRINGLIB_SIZEOF_CHAR >= 4 + if (ch < 0xF5) { + /* \xF0\x90\x80\80-\xF4\x8F\xBF\xBF -- 10000-10FFFF */ + Py_UCS4 ch2, ch3, ch4; + if (end - s < 4) { + /* unexpected end of data: the caller will decide whether + it's an error or not */ + goto _error; + } + ch2 = (unsigned char)s[1]; + ch3 = (unsigned char)s[2]; + ch4 = (unsigned char)s[3]; + if ((ch2 & 0xc0) != 0x80 || + (ch3 & 0xc0) != 0x80 || + (ch4 & 0xc0) != 0x80) { /* invalid continuation byte */ goto _error; } - ch = ((s[0] & 0x7) << 18) + ((s[1] & 0x3f) << 12) + - ((s[2] & 0x3f) << 6) + (s[3] & 0x3f); + if (ch == 0xF0) { + if (ch2 < 0x90) + /* invalid sequence + \xF0\x80\x80\80-\xF0\x80\xBF\xBF -- fake 0000-FFFF */ + goto _error; + } + else if (ch == 0xF4 && ch2 > 0x8F) { + /* invalid sequence + \xF4\x90\x80\80- -- 110000- overflow */ + goto _error; + } + ch = (ch << 18) + (ch2 << 12) + (ch3 << 6) + ch4 - 0362020200; assert ((ch > 0xFFFF) && (ch <= 0x10ffff)); s += 4; *p++ = ch; - break; + continue; } +#endif +#endif + goto _error; } ret = 0; goto _ok; From report at bugs.python.org Tue Apr 24 19:48:11 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 17:48:11 +0000 Subject: [issue14448] Mention pytz in datetime's docs In-Reply-To: <1333056065.25.0.804124513061.issue14448@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e0e421133d0f by Sandro Tosi in branch '2.7': Issue #14448: mention pytz; patch by Andrew Svetlov http://hg.python.org/cpython/rev/e0e421133d0f New changeset 3aec41794584 by Sandro Tosi in branch '3.2': Issue #14448: mention pytz; patch by Andrew Svetlov http://hg.python.org/cpython/rev/3aec41794584 New changeset b46fa7bc6710 by Sandro Tosi in branch 'default': Issue #14448: merge with 3.2 http://hg.python.org/cpython/rev/b46fa7bc6710 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 19:48:59 2012 From: report at bugs.python.org (Sandro Tosi) Date: Tue, 24 Apr 2012 17:48:59 +0000 Subject: [issue14448] Mention pytz in datetime's docs In-Reply-To: <1333056065.25.0.804124513061.issue14448@psf.upfronthosting.co.za> Message-ID: <1335289739.17.0.0424749719405.issue14448@psf.upfronthosting.co.za> Sandro Tosi added the comment: I've reworded a bit the patch: thanks for it, Andrew ---------- nosy: +sandro.tosi resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 19:55:06 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 24 Apr 2012 17:55:06 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1335280363.22.0.807702965043.issue14605@psf.upfronthosting.co.za> Message-ID: <4F96E8F6.6010301@egenix.com> Marc-Andre Lemburg added the comment: Brett Cannon wrote: > > That initial comment is out-of-date. If you look that the commit I made I documented importlib.machinery._SourcelessFileLoader. I am continuing the discouragement of using bytecode files as an obfuscation technique (because it's a bad one), but I decided to at least document the class so people can use it at their own peril and know about it if they happen to come across the object during execution. It's not a perfect obfuscation technique, but a pretty simple and (legally) effective one to use. FWIW, I don't think the comment in the check-in is appropriate: """ 1.127 + It is **strongly** suggested you do not rely on this loader (hence the 1.128 + leading underscore of the class). Direct use of bytecode files (and thus not 1.129 + source code files) inhibits your modules from being usable by all Python 1.130 + implementations. It also runs the risk of your bytecode files not being 1.131 + usable by new versions of Python which change the bytecode format. This 1.132 + class is only documented as it is directly used by import and thus can 1.133 + potentially have instances show up as a module's ``__loader__`` attribute. """ The "risks" you mention there are really up to the application developers to decide how to handle, not the Python developers. Python has a long tradition of being friendly to commercial applications and I don't see any reason why we should stop that. If you do want this to change, please write a PEP. This may appear to be a small change in direction, but it does in fact have quite some impact on the usefulness of CPython in commercial settings. I also think that the SourcelessFileLoader loader should be first class citizen without the leading underscore if the importlib is to completely replace the current import mechanism. Why force developers to write their own loader instead of using the standard one just because of the leading underscore, when it's only 20 lines of code ? Thanks, -- Marc-Andre Lemburg eGenix.com ________________________________________________________________________ 2012-04-28: PythonCamp 2012, Cologne, Germany 4 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 19:58:52 2012 From: report at bugs.python.org (Fabian Groffen) Date: Tue, 24 Apr 2012 17:58:52 +0000 Subject: [issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails) Message-ID: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> New submission from Fabian Groffen : With current working dir an NFS-mounted ZFS share, and /var/tmp (OSX default) HFS+: % echo "test" > /var/tmp/testfile % python Python 2.7.3 (default, Apr 24 2012, 19:33:45) [GCC 4.2.1 (Gentoo 4.2.1_p5666, Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import shutil >>> shutil.move("/var/tmp/testfile", "./testfile"); Traceback (most recent call last): File "", line 1, in File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 299, in move copy2(src, real_dst) File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 129, in copy2 copystat(src, dst) File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 103, in copystat os.chflags(dst, st.st_flags) OSError: [Errno 45] Operation not supported: './testfile' >>> % ls /var/tmp/testfile ./testfile ./testfile /var/tmp/testfile The problem likely is that the flags stored on the HFS+ volume cannot be applied to the NFS-mounted ZFS volume. This likely also occurs when doing a bit more regular things, like e.g. moving/copying to a mounted USB disk (with FAT32 filesystem). I believe this is a "regression" introduced by http://bugs.python.org/issue8746. Python-2.7.2 works fine. While preserving flags is nice, it is questionable whether failure to do so in this case is worth dying for. In particular, leaving behind both the original as well as the copy is a bit messy. ---------- components: None messages: 159178 nosy: grobian priority: normal severity: normal status: open title: shutil.move broken in 2.7.3 on OSX (chflags fails) type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 20:03:12 2012 From: report at bugs.python.org (Armin Rigo) Date: Tue, 24 Apr 2012 18:03:12 +0000 Subject: [issue5057] Unicode-width dependent optimization leads to non-portable pyc file In-Reply-To: <1232900172.29.0.659028766072.issue5057@psf.upfronthosting.co.za> Message-ID: <1335290592.97.0.370722624003.issue5057@psf.upfronthosting.co.za> Armin Rigo added the comment: Sorry to re-open this issue. The following example shows that it was not fully resolved: def f(): return u'\U00023456abcdef'[3] import dis; dis.dis(f) print f() On a wide build it should print 'c' and on a narrow build it should print 'b'. But if the .pyc file was created on the other platform, it behaves like the other platform would. ---------- nosy: +arigo resolution: fixed -> stage: committed/rejected -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 20:07:13 2012 From: report at bugs.python.org (Nul Character) Date: Tue, 24 Apr 2012 18:07:13 +0000 Subject: [issue14663] Cannot comment out comments Message-ID: <1335290833.16.0.0579074367428.issue14663@psf.upfronthosting.co.za> New submission from Nul Character : When attempting to comment out a comment and thus nullifying it, the interpreter just double comments the line. This behavior works with multiline comments, however, the single line comments "double-comment" the line. ---------- components: Interpreter Core files: comment.py messages: 159180 nosy: nulchar priority: normal severity: normal status: open title: Cannot comment out comments type: performance versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file25344/comment.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 20:12:22 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 24 Apr 2012 18:12:22 +0000 Subject: [issue14663] Cannot comment out comments In-Reply-To: <1335290833.16.0.0579074367428.issue14663@psf.upfronthosting.co.za> Message-ID: <1335291142.82.0.254503189977.issue14663@psf.upfronthosting.co.za> R. David Murray added the comment: A comment is a comment. *All* characters after the # are ignored, including other #s. Also, Python doesn't have multiline comments. (Well, you can use a triple quoted string as a multiline comment, but it is still a string, and follows the syntax rules of strings.) ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed type: performance -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 20:19:50 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 24 Apr 2012 18:19:50 +0000 Subject: [issue14369] make __closure__ writable In-Reply-To: <1332179477.04.0.11685261564.issue14369@psf.upfronthosting.co.za> Message-ID: <1335291590.91.0.560722352047.issue14369@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Shouldn't test___closure__() also test what happens when the closure is replaced with None, or a tuple which is too long or too short or contains non-cell objects? All of these things seem to be checked when you create a new function using types.FunctionType: >>> h = types.FunctionType(g.__code__, g.__globals__, "h", g.__defaults__, None) Traceback (most recent call last): File "", line 1, in TypeError: arg 5 (closure) must be tuple >>> h = types.FunctionType(g.__code__, g.__globals__, "h", g.__defaults__, ()) Traceback (most recent call last): File "", line 1, in ValueError: g requires closure of length 2, not 0 >>> h = types.FunctionType(g.__code__, g.__globals__, "h", g.__defaults__, (1,2)) Traceback (most recent call last): File "", line 1, in TypeError: arg 5 (closure) expected cell, found int I think the setter should make similar checks. Maybe there is C code which assumes "broken" closures never happen. ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 20:20:52 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 24 Apr 2012 18:20:52 +0000 Subject: [issue14661] posix module: add O_EXEC, O_SEARCH, O_TTY_INIT In-Reply-To: <1335285381.34.0.139492231306.issue14661@psf.upfronthosting.co.za> Message-ID: <1335291652.35.0.333472542971.issue14661@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I will take care of this. ---------- assignee: -> jcea nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 20:22:36 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Tue, 24 Apr 2012 18:22:36 +0000 Subject: [issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails) In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335291756.04.0.136560522453.issue14662@psf.upfronthosting.co.za> Hynek Schlawack added the comment: I guess a ?best effort? approach would be best here. I presume Python 3.2+ have the same behavior? ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 20:26:46 2012 From: report at bugs.python.org (Fabian Groffen) Date: Tue, 24 Apr 2012 18:26:46 +0000 Subject: [issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails) In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335292006.0.0.16999946184.issue14662@psf.upfronthosting.co.za> Fabian Groffen added the comment: > I presume Python 3.2+ have the same behavior? I cannot compile that or get it working normally, so I can't tell for sure. Judging from the code, I'd say yes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 20:40:44 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 24 Apr 2012 18:40:44 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335292844.63.0.628769677923.issue14657@psf.upfronthosting.co.za> Eric Snow added the comment: > would be great if we had a > command to stop module execution or code execution for a block to > make that more elegant, e.g. "break" at module scope :-) I floated that proposal on python-list a while back and the reaction was mixed. [1] Maybe it's time to try again. (moving over to python-ideas...) [1] http://mail.python.org/pipermail/python-list/2011-June/1274424.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 20:44:08 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 24 Apr 2012 18:44:08 +0000 Subject: [issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu In-Reply-To: <1335214535.54.0.037053632097.issue14610@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Your strace output looks strange :-) Unless it's truncated, we see that the wait4() doesn't return when the test pthread executable exits... Could you try building this code : """ #include void* routine(void* p){return NULL;} int main(){ pthread_t p; if(pthread_create(&p,NULL,routine,NULL)!=0) return 1; (void)pthread_detach(p); return 0; } """ (with gcc -o test test.c -lpthread) And running it from the command line, to see your shell hangs (you might also want to try 'strace -f sh -c "test"'). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 20:44:25 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 18:44:25 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 5d5b72a71898 by Benjamin Peterson in branch 'default': distiguish between refusing to creating shared keys and error (#13903) http://hg.python.org/cpython/rev/5d5b72a71898 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 20:46:49 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 24 Apr 2012 18:46:49 +0000 Subject: [issue14661] posix module: add O_EXEC, O_SEARCH, O_TTY_INIT In-Reply-To: <1335285381.34.0.139492231306.issue14661@psf.upfronthosting.co.za> Message-ID: <1335293209.87.0.822459386195.issue14661@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I add some other constants too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 20:55:05 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 24 Apr 2012 18:55:05 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1335211374.15337.YahooMailNeo@web171306.mail.ir2.yahoo.com> Message-ID: Charles-Fran?ois Natali added the comment: > I can't see why this always works, while John's script sometimes fails. It does fail consistently on my machine. I'm attaching the diff just in case. ---------- Added file: http://bugs.python.org/file25345/test_logging_race.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff --git a/Lib/test/test_logging.py b/Lib/test/test_logging.py --- a/Lib/test/test_logging.py +++ b/Lib/test/test_logging.py @@ -33,6 +33,7 @@ import json import os import queue +import random import re import select import socket @@ -527,6 +528,39 @@ self.assertEqual(h.name, 'anothergeneric') self.assertRaises(NotImplementedError, h.emit, None) + @unittest.skipUnless(threading, 'Threading required for this test.') + def test_race(self): + # Issue #14632 refers. + def remove_loop(fname, tries): + for _ in range(tries): + try: + os.unlink(fname) + except OSError: + pass + time.sleep(0.004 * random.randint(0, 4)) + + def cleanup(remover, fn, handler): + handler.close() + remover.join() + if os.path.exists(fn): + os.unlink(fn) + + fd, fn = tempfile.mkstemp('.log', 'test_logging-3-') + os.close(fd) + del_count = 1000 + log_count = 1000 + remover = threading.Thread(target=remove_loop, args=(fn, del_count)) + remover.daemon = True + remover.start() + h = logging.handlers.WatchedFileHandler(fn) + self.addCleanup(cleanup, remover, fn, h) + f = logging.Formatter('%(asctime)s: %(levelname)s: %(message)s') + h.setFormatter(f) + for _ in range(log_count): + time.sleep(0.005) + r = logging.makeLogRecord({'msg': 'testing' }) + h.handle(r) + def test_builtin_handlers(self): # We can't actually *use* too many handlers in the tests, # but we can try instantiating them with various options From report at bugs.python.org Tue Apr 24 21:00:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 19:00:50 +0000 Subject: [issue14661] posix module: add O_EXEC, O_SEARCH, O_TTY_INIT In-Reply-To: <1335285381.34.0.139492231306.issue14661@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 34de406f566d by Jesus Cea in branch 'default': Issue #14661: posix module: add O_EXEC, O_SEARCH, O_TTY_INIT http://hg.python.org/cpython/rev/34de406f566d New changeset 2023f48b32b6 by Jesus Cea in branch 'default': Closes Issue #14661: posix module: add O_EXEC, O_SEARCH, O_TTY_INIT (I add some Solaris constants too) http://hg.python.org/cpython/rev/2023f48b32b6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 21:01:20 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 24 Apr 2012 19:01:20 +0000 Subject: [issue14661] posix module: add O_EXEC, O_SEARCH, O_TTY_INIT In-Reply-To: <1335285381.34.0.139492231306.issue14661@psf.upfronthosting.co.za> Message-ID: <1335294080.36.0.954477981037.issue14661@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 21:08:16 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Tue, 24 Apr 2012 19:08:16 +0000 Subject: [issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails) In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335294496.08.0.904694567675.issue14662@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Now that?s odd. I just looked into the code at http://hg.python.org/cpython/file/2.7/Lib/shutil.py#l103 and there is a guard against EOPNOTSUPP: try: os.chflags(dst, st.st_flags) except OSError, why: if (not hasattr(errno, 'EOPNOTSUPP') or why.errno != errno.EOPNOTSUPP): raise Does your /Library/Gentoo/usr/lib/python2.7/shutil.py look the same? Would you mind adding a `print why.errno` just before the raise? I have tried move'ing files to NTFS and FAT32 and it works just fine here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 21:09:35 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 19:09:35 +0000 Subject: [issue14160] TarFile.extractfile fails to extract targets of top-level relative symlinks In-Reply-To: <1330530660.51.0.926091322087.issue14160@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 0adf4fd8df83 by Lars Gust?bel in branch '3.2': Issue #14160: TarFile.extractfile() failed to resolve symbolic links http://hg.python.org/cpython/rev/0adf4fd8df83 New changeset 38df99776901 by Lars Gust?bel in branch 'default': Merge with 3.2: Issue #14160: TarFile.extractfile() failed to resolve symbolic http://hg.python.org/cpython/rev/38df99776901 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 21:10:45 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 24 Apr 2012 19:10:45 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <1335217931.89.0.157136074708.issue14656@psf.upfronthosting.co.za> Message-ID: <1335294645.57.0.31449154769.issue14656@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Let me explain what I meant with code. ---------- keywords: +patch Added file: http://bugs.python.org/file25346/unreachable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 21:15:46 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 24 Apr 2012 19:15:46 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335294946.35.0.673656489176.issue14605@psf.upfronthosting.co.za> Brett Cannon added the comment: I documented it explicitly so people can use it if they so choose (e.g. look at sys._getframe()). If you want to change this that's fine, but I am personally not going to put the effort in to rename the class, update the tests, and change the docs for this (we almost stopped allowing the importation of bytecode directly not so long ago but got push-back so we backed off). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 21:23:35 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 24 Apr 2012 19:23:35 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335295415.27.0.710009130636.issue14657@psf.upfronthosting.co.za> Brett Cannon added the comment: I don't quite follow what you are suggesting, MAL. Are you saying to freeze importlib.__init__ and importlib._bootstrap and somehow have improtlib.__init__ choose what to load, frozen or source? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 21:37:09 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 24 Apr 2012 19:37:09 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1335296229.44.0.239701074787.issue10142@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Added file: http://bugs.python.org/file25347/34103049559f.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 21:38:07 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 24 Apr 2012 19:38:07 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1335296287.16.0.907162888994.issue10142@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Removed file: http://bugs.python.org/file25347/34103049559f.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 21:48:03 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 24 Apr 2012 19:48:03 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1335296883.45.0.661526217783.issue10142@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Added file: http://bugs.python.org/file25348/0a5a40a4674a.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 21:51:02 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 24 Apr 2012 19:51:02 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1335297062.17.0.545944835673.issue10142@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: New version, addressing Amaury concerns and Neologix review. Please, do a final review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 21:51:50 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 24 Apr 2012 19:51:50 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335295415.27.0.710009130636.issue14657@psf.upfronthosting.co.za> Message-ID: <4F970452.70305@egenix.com> Marc-Andre Lemburg added the comment: Brett Cannon wrote: > > Brett Cannon added the comment: > > I don't quite follow what you are suggesting, MAL. Are you saying to freeze importlib.__init__ and importlib._bootstrap and somehow have improtlib.__init__ choose what to load, frozen or source? No, it always loads and runs the frozen code, but at the start of the module code it branches between the frozen bytecode and the code read from an external file. Pseudo-code in every module you wish to be able to host externally: # # MyModule # if operating_in_dev_mode and '' in __file__: exec(open('dev-area/MyModule.py', 'r).read(), globals(), globals()) else: # Normal module code class MyClass: ... # hundreds of lines of code... Aside: With a module scope "break", the code would look more elegant: # # MyModule # if operating_in_dev_mode and '' in __file__: exec(open('dev-area/MyModule.py', 'r).read(), globals(), globals()) break # Normal module code class MyClass: ... # hundreds of lines of code... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 21:57:14 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 19:57:14 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1335297434.73.0.895888998767.issue10142@psf.upfronthosting.co.za> Antoine Pitrou added the comment: - In test_posix.py: it's better to use the "with" statement when opening a file - In Misc/NEWS: the entries should be kept in reverse chronological order ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 22:00:23 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 24 Apr 2012 20:00:23 +0000 Subject: [issue1522400] irda socket support In-Reply-To: <1334151563.67.0.887827722652.issue1522400@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Here's a cleanup up patch against default. However, I don't have any IrDA capable device neither, so I won't be able to help much. I'll ask on python-dev if someone can help. As for the manual decoding, AFAICT you'll have the same issue with CAN sockets. The real question is really "how high-level should the socket module be?". Because if we added let's say and IRDASocket type, then we could easily add helper functions to and methods to e.g. list available IrDA devices, decode fields, etc. Same thing holds for CAN sockets, and one could imagine we could also maybe add a MulticastSocket that would make joining/leaving a multicast group easy (because it is a pain), etc. ---------- Added file: http://bugs.python.org/file25349/irda-default.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c --- a/Modules/socketmodule.c +++ b/Modules/socketmodule.c @@ -1262,6 +1262,16 @@ } #endif +#ifdef AF_IRDA + case AF_IRDA: + { + struct sockaddr_irda *a = (struct sockaddr_irda *)addr; + + return Py_BuildValue("iO&", a->sir_addr, + PyUnicode_DecodeFSDefault, a->sir_name); + } +#endif + /* More cases here... */ default: @@ -1759,6 +1769,47 @@ } #endif +#ifdef HAVE_IRDA_H + case AF_IRDA: + { + struct sockaddr_irda *addr; + int daddr; + PyObject *service; + addr = (struct sockaddr_irda *)addr_ret; + Py_ssize_t len; + + if (!PyArg_ParseTuple(args, "iO&", &daddr, + PyUnicode_FSConverter, &service)) + return 0; + + len = PyBytes_GET_SIZE(service); + + if (len <= 0 || len >= sizeof(addr->sir_name)) { + PyErr_SetString(PyExc_OSError, "AF_IRDA service name too long"); + Py_DECREF(service); + return 0; + } + +#ifdef HAVE_LINUX_IRDA_H + addr->sir_family = AF_IRDA; + addr->sir_lsap_sel = LSAP_ANY; + addr->sir_addr = daddr; + strcpy(addr->sir_name, PyBytes_AS_STRING(service)); +#else /* Windows */ + addr->irdaAddressFamily = AF_IRDA; + addr->irdaDeviceID[0] = (daddr >> 24) & Oxff; + addr->irdaDeviceID[1] = (daddr >> 16) & Oxff; + addr->irdaDeviceID[2] = (daddr >> 8) & Oxff; + addr->irdaDeviceID[3] = daddr & Oxff; + strcpy(addr->irdaServiceName, PyBytes_AS_STRING(service)); +#endif + + Py_DECREF(service); + *len_ret = sizeof(*addr); + return 1; + } +#endif + /* More cases here... */ default: @@ -1880,6 +1931,14 @@ } #endif +#ifdef AF_IRDA + case AF_IRDA: + { + *len_ret = sizeof (struct sockaddr_irda); + return 1; + } +#endif + /* More cases here... */ default: @@ -5823,6 +5882,14 @@ PyModule_AddIntConstant(m, "AF_SYSTEM", AF_SYSTEM); #endif +/* Infrared Data Association */ +#ifdef AF_IRDA + PyModule_AddIntConstant(m, "AF_IRDA", AF_IRDA); +#endif +#ifdef PF_IRDA + PyModule_AddIntConstant(m, "PF_IRDA", PF_IRDA); +#endif + #ifdef AF_PACKET PyModule_AddIntMacro(m, AF_PACKET); #endif @@ -5895,6 +5962,13 @@ PyModule_AddIntConstant(m, "TIPC_TOP_SRV", TIPC_TOP_SRV); #endif +#ifdef HAVE_IRDA_H + PyModule_AddIntConstant(m, "SOL_IRLMP", SOL_IRLMP); + PyModule_AddIntConstant(m, "IRLMP_ENUMDEVICES", IRLMP_ENUMDEVICES); + PyModule_AddIntConstant(m, "IRLMP_IAS_SET", IRLMP_IAS_SET); + PyModule_AddIntConstant(m, "IRLMP_IAS_QUERY", IRLMP_IAS_QUERY); +#endif + /* Socket types */ PyModule_AddIntConstant(m, "SOCK_STREAM", SOCK_STREAM); PyModule_AddIntConstant(m, "SOCK_DGRAM", SOCK_DGRAM); diff --git a/Modules/socketmodule.h b/Modules/socketmodule.h --- a/Modules/socketmodule.h +++ b/Modules/socketmodule.h @@ -87,6 +87,17 @@ #include #endif +#if (defined(MS_WINDOWS) || defined(HAVE_LINUX_IRDA_H)) +#define HAVE_IRDA_H +#ifdef HAVE_LINUX_IRDA_H +#include +#include +#else +#include +#define sockaddr_irda _SOCKADDR_IRDA +#endif +#endif + #ifndef Py__SOCKET_H #define Py__SOCKET_H #ifdef __cplusplus @@ -148,6 +159,9 @@ #ifdef HAVE_SYS_KERN_CONTROL_H struct sockaddr_ctl ctl; #endif +#ifdef HAVE_IRDA_H + struct sockaddr_irda ir; +#endif } sock_addr_t; /* The object holding a socket. It holds some extra information, diff --git a/configure b/configure --- a/configure +++ b/configure @@ -6605,6 +6605,25 @@ done +# On Linux, irda.h requires sys/socket.h +for ac_header in linux/irda.h +do : + ac_fn_c_check_header_compile "$LINENO" "linux/irda.h" "ac_cv_header_linux_irda_h" " +#ifdef HAVE_SYS_SOCKET_H +#include +#endif + +" +if test "x$ac_cv_header_linux_irda_h" = xyes; then : + cat >>confdefs.h <<_ACEOF +#define HAVE_LINUX_IRDA_H 1 +_ACEOF + +fi + +done + + # checks for typedefs was_it_defined=no { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clock_t in time.h" >&5 diff --git a/configure.ac b/configure.ac --- a/configure.ac +++ b/configure.ac @@ -1404,6 +1404,13 @@ #endif ]) +# On Linux, irda.h requires sys/socket.h +AC_CHECK_HEADERS(linux/irda.h,,,[ +#ifdef HAVE_SYS_SOCKET_H +#include +#endif +]) + # checks for typedefs was_it_defined=no AC_MSG_CHECKING(for clock_t in time.h) diff --git a/pyconfig.h.in b/pyconfig.h.in --- a/pyconfig.h.in +++ b/pyconfig.h.in @@ -501,6 +501,9 @@ /* Define to 1 if you have the header file. */ #undef HAVE_LINUX_CAN_RAW_H +/* Define to 1 if you have the header file. */ +#undef HAVE_LINUX_IRDA_H + /* Define to 1 if you have the header file. */ #undef HAVE_LINUX_NETLINK_H From report at bugs.python.org Tue Apr 24 22:15:25 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 24 Apr 2012 20:15:25 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1335298525.16.0.0951337127144.issue10142@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Added file: http://bugs.python.org/file25350/ad882ba08568.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 22:15:46 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 24 Apr 2012 20:15:46 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1335298546.59.0.0706594315116.issue10142@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Another version, after Antoine feedback. Please, review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 22:25:35 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 24 Apr 2012 20:25:35 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335299135.14.0.687406626788.issue14657@psf.upfronthosting.co.za> Brett Cannon added the comment: So basically if you are running in a checkout, grab the source file and compile it manually since its location is essentially hard-coded and thus you don't need to care about sys.path and all the other stuff required to do an import, while using the frozen code for when you are running an installed module since you would otherwise need to do the search for importlib's source file to do a load at startup properly. That's an interesting idea. How do we currently tell that the interpreter is running in a checkout? Is that exposed in any way to Python code? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 22:39:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 20:39:09 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335299135.14.0.687406626788.issue14657@psf.upfronthosting.co.za> Message-ID: <1335299864.3436.18.camel@localhost.localdomain> Antoine Pitrou added the comment: > That's an interesting idea. How do we currently tell that the > interpreter is running in a checkout? Is that exposed in any way to > Python code? Look for _BUILDDIR_COOKIE in setup.py. But that's only for non-Windows platforms (I don't think setup.py is invoked under Windows). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 22:42:24 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 24 Apr 2012 20:42:24 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335299135.14.0.687406626788.issue14657@psf.upfronthosting.co.za> Message-ID: <4F971027.2090205@egenix.com> Marc-Andre Lemburg added the comment: Brett Cannon wrote: > > Brett Cannon added the comment: > > So basically if you are running in a checkout, grab the source file and compile it manually since its location is essentially hard-coded and thus you don't need to care about sys.path and all the other stuff required to do an import, while using the frozen code for when you are running an installed module since you would otherwise need to do the search for importlib's source file to do a load at startup properly. Right. > That's an interesting idea. How do we currently tell that the interpreter is running in a checkout? Is that exposed in any way to Python code? There's some magic happening in site.py for checkouts, but I'm not sure whether any of that is persistent or even available at the time these particular imports would happen. Then again, I'm not sure you need to know whether you have a checkout or not. You just need some flag to identify whether you want the search for external module code to take place or not. sys.flags could be used for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 22:42:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 20:42:45 +0000 Subject: [issue14160] TarFile.extractfile fails to extract targets of top-level relative symlinks In-Reply-To: <1330530660.51.0.926091322087.issue14160@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset aff14bea5596 by Lars Gust?bel in branch '2.7': Issue #14160: TarFile.extractfile() failed to resolve symbolic links when http://hg.python.org/cpython/rev/aff14bea5596 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 22:46:41 2012 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Tue, 24 Apr 2012 20:46:41 +0000 Subject: [issue14160] TarFile.extractfile fails to extract targets of top-level relative symlinks In-Reply-To: <1330530660.51.0.926091322087.issue14160@psf.upfronthosting.co.za> Message-ID: <1335300401.4.0.559612771504.issue14160@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Fixed. Thanks for the report. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 22:58:23 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 20:58:23 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 08d4c2fe51ea by Antoine Pitrou in branch 'default': Issue #4892: multiprocessing Connections can now be transferred over multiprocessing Connections. http://hg.python.org/cpython/rev/08d4c2fe51ea ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 22:59:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 20:59:08 +0000 Subject: [issue4892] Sending Connection-objects over multiprocessing connections fails In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za> Message-ID: <1335301148.02.0.0173309235016.issue4892@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks, Richard. I have now committed the patch. Hopefully the Windows buildbots will be ok :) ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 23:13:15 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 24 Apr 2012 21:13:15 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335301995.55.0.753268342375.issue14657@psf.upfronthosting.co.za> Brett Cannon added the comment: Modules/getpath.c seems to be where the C code does it when getting paths for sys.path. So it would be possible to use that same algorithm to set some sys attribute (e.g. in_checkout or something) much like sys.gettotalrefcount is optional and only shown when built with --with-pydebug. Otherwise some directory structure check could be done (e.g. find importlib/_bootstrap.py off of sys.path, and then see if ../Modules/Setup or something also exists that would never show up in an installed CPython). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 23:14:36 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 24 Apr 2012 21:14:36 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1335302076.82.0.796689811181.issue11618@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Here is a new patch. I've factored out the NT condittion variable code into thread_nt_cv.h which is now used by both thread_nt.h and ceval_gil.h ---------- Added file: http://bugs.python.org/file25351/ntlocks.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 23:15:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 21:15:29 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335301995.55.0.753268342375.issue14657@psf.upfronthosting.co.za> Message-ID: <1335302044.3436.19.camel@localhost.localdomain> Antoine Pitrou added the comment: > Otherwise some directory structure check could be done (e.g. find > importlib/_bootstrap.py off of sys.path, and then see > if ../Modules/Setup or something also exists that would never show up > in an installed CPython). Well, the directory structure check *is* pybuilddir.txt (under POSIX, again; under Windows, you might want to check for Lib/importlib directly). But, agreed, this could be factored in a sys._private_something attribute. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 23:30:43 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Apr 2012 21:30:43 +0000 Subject: [issue14579] Possible vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1335303194.2400.173.camel@raxxla> Serhiy Storchaka added the comment: Here is a patch, which took into account the Martin suggestions. ---------- title: Vulnerability in the utf-16 decoder after error handling -> Possible vulnerability in the utf-16 decoder after error handling Added file: http://bugs.python.org/file25352/utf16_error_handling-3.2_3.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r b07488490001 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Apr 20 14:36:47 2012 +0200 +++ b/Objects/unicodeobject.c Tue Apr 24 23:54:58 2012 +0300 @@ -3425,7 +3425,7 @@ /* Unpack UTF-16 encoded data */ p = unicode->str; q = (unsigned char *)s; - e = q + size - 1; + e = q + size; if (byteorder) bo = *byteorder; @@ -3476,8 +3476,20 @@ #endif aligned_end = (const unsigned char *) ((size_t) e & ~LONG_PTR_MASK); - while (q < e) { + while (1) { Py_UNICODE ch; + if (e - q < 2) { + /* remaining byte at the end? (size should be even) */ + if (q == e || consumed) + break; + errmsg = "truncated data"; + startinpos = ((const char *)q) - starts; + endinpos = ((const char *)e) - starts; + outpos = p - PyUnicode_AS_UNICODE(unicode); + goto utf16Error; + /* The remaining input chars are ignored if the callback + chooses to skip the input */ + } /* First check for possible aligned read of a C 'long'. Unaligned reads are more expensive, better to defer to another iteration. */ if (!((size_t) q & LONG_PTR_MASK)) { @@ -3546,7 +3558,7 @@ } p = _p; q = _q; - if (q >= e) + if (e - q < 2) break; } ch = (q[ihi] << 8) | q[ilo]; @@ -3559,10 +3571,10 @@ } /* UTF-16 code pair: */ - if (q > e) { + if (e - q < 2) { errmsg = "unexpected end of data"; startinpos = (((const char *)q) - 2) - starts; - endinpos = ((const char *)e) + 1 - starts; + endinpos = ((const char *)e) - starts; goto utf16Error; } if (0xD800 <= ch && ch <= 0xDBFF) { @@ -3606,31 +3618,9 @@ &outpos, &p)) goto onError; - } - /* remaining byte at the end? (size should be even) */ - if (e == q) { - if (!consumed) { - errmsg = "truncated data"; - startinpos = ((const char *)q) - starts; - endinpos = ((const char *)e) + 1 - starts; - outpos = p - PyUnicode_AS_UNICODE(unicode); - if (unicode_decode_call_errorhandler( - errors, - &errorHandler, - "utf16", errmsg, - &starts, - (const char **)&e, - &startinpos, - &endinpos, - &exc, - (const char **)&q, - &unicode, - &outpos, - &p)) - goto onError; - /* The remaining input chars are ignored if the callback - chooses to skip the input */ - } + /* Update data because unicode_decode_call_errorhandler might have + changed the input object. */ + aligned_end = (const unsigned char *) ((size_t) e & ~LONG_PTR_MASK); } if (byteorder) From report at bugs.python.org Tue Apr 24 23:33:36 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 24 Apr 2012 21:33:36 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1335303216.81.0.320085181806.issue14579@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- title: Possible vulnerability in the utf-16 decoder after error handling -> Vulnerability in the utf-16 decoder after error handling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 23:34:34 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 21:34:34 +0000 Subject: [issue14664] Skipping a test mixin gives metaclass error Message-ID: <1335303274.85.0.323410405503.issue14664@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Seen on a buildbot: test test_multiprocessing crashed -- Traceback (most recent call last): File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/regrtest.py", line 1229, in runtest_inner the_package = __import__(abstest, globals(), locals(), []) File "", line 1030, in _find_and_load File "", line 611, in load_module File "", line 271, in module_for_loader_wrapper File "", line 499, in _load_module File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_multiprocessing.py", line 2430, in testcases_processes = create_test_cases(ProcessesMixin, type='processes') File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_multiprocessing.py", line 2409, in create_test_cases class Temp(base, unittest.TestCase, Mixin): TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases Here is a patch. ---------- components: Library (Lib) files: skip_mixin.patch keywords: patch messages: 159213 nosy: benjamin.peterson, michael.foord, pitrou priority: normal severity: normal stage: patch review status: open title: Skipping a test mixin gives metaclass error type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25353/skip_mixin.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 23:36:47 2012 From: report at bugs.python.org (Brett Cannon) Date: Tue, 24 Apr 2012 21:36:47 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335303407.01.0.959390135494.issue14657@psf.upfronthosting.co.za> Brett Cannon added the comment: That's why I was thinking of tying into Modules/getpath.c because I assume that would work cross-platform. Is that incorrect? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 23:37:59 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 21:37:59 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335303407.01.0.959390135494.issue14657@psf.upfronthosting.co.za> Message-ID: <1335303393.3436.20.camel@localhost.localdomain> Antoine Pitrou added the comment: > That's why I was thinking of tying into Modules/getpath.c because I > assume that would work cross-platform. Is that incorrect? Windows uses PC/getpathp.c, not Modules/getpath.c (with tons of duplicate code)... So you would have to tie into both :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 23:39:19 2012 From: report at bugs.python.org (Michael Foord) Date: Tue, 24 Apr 2012 21:39:19 +0000 Subject: [issue14664] Skipping a test mixin gives metaclass error In-Reply-To: <1335303274.85.0.323410405503.issue14664@psf.upfronthosting.co.za> Message-ID: <1335303559.94.0.562672723155.issue14664@psf.upfronthosting.co.za> Michael Foord added the comment: Patch looks good - thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 23:46:20 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 24 Apr 2012 21:46:20 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335301995.55.0.753268342375.issue14657@psf.upfronthosting.co.za> Message-ID: <4F971F28.4050108@egenix.com> Marc-Andre Lemburg added the comment: Brett Cannon wrote: > > Modules/getpath.c seems to be where the C code does it when getting paths for sys.path. So it would be possible to use that same algorithm to set some sys attribute (e.g. in_checkout or something) much like sys.gettotalrefcount is optional and only shown when built with --with-pydebug. Otherwise some directory structure check could be done (e.g. find importlib/_bootstrap.py off of sys.path, and then see if ../Modules/Setup or something also exists that would never show up in an installed CPython). Why not simply use a flag that get's set based on an environment variable, say PYTHONDEVMODE ? Adding more cruft to getpath.c or similar routines is just going to slow down startup time even more... Python 2.7 has a startup time of 70ms on my machine; compare that to Python 2.1 with 10ms and Perl 5 with just 4ms. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 23:52:02 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 21:52:02 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <4F971F28.4050108@egenix.com> Message-ID: <1335304237.3436.21.camel@localhost.localdomain> Antoine Pitrou added the comment: > Adding more cruft to getpath.c or similar routines is just going to > slow down startup time even more... The code is already there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 24 23:54:12 2012 From: report at bugs.python.org (Eric Snow) Date: Tue, 24 Apr 2012 21:54:12 +0000 Subject: [issue14660] Implement PEP 420: Implicit Namespace Packages In-Reply-To: <1335265720.13.0.725647299701.issue14660@psf.upfronthosting.co.za> Message-ID: <1335304452.15.0.485907808871.issue14660@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 00:05:15 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 24 Apr 2012 22:05:15 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1335305115.78.0.68737361055.issue14127@psf.upfronthosting.co.za> Larry Hastings added the comment: Attached is round 1 of my patch adding the ns= parameter to utime, futimes, and lutimes. Some notes: * I admit the "see utime for use of times and ns" documentation dodge (for both Doc and docstring) is lazy. Yet I'm still hoping to get away with it. * I removed futimens because it's now extraneous. * I didn't add ns= to utimensat or futimesat. That's because I'm hoping to get rid of them via #14626. (And lutimes too, come to think of it!) I hereby promise that if they survive to June 15th I'll add ns= support before 3.3 hits beta. * At last, shutil.copystat (and therefore shutil.copy2) now *exactly* preserves timestamps. :D ---------- keywords: +patch Added file: http://bugs.python.org/file25354/larry.utime.ns.1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 00:06:27 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 24 Apr 2012 22:06:27 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1331932171.45.0.56771909125.issue14339@psf.upfronthosting.co.za> Message-ID: <1335305187.61.0.0327030149603.issue14339@psf.upfronthosting.co.za> STINNER Victor added the comment: 2.100 - v = PyUnicode_DecodeASCII(p, &buffer[sz] - p, NULL); ... 2.104 + assert(p == PyUnicode_1BYTE_DATA(v)); 2.105 return v; 2.106 } You may call assert(_PyUnicode_CheckConsistency(v, 1)) to ensure that the newly created string is "consistent" (see the function for the details). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 00:10:17 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 24 Apr 2012 22:10:17 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1335305417.55.0.518855288041.issue14127@psf.upfronthosting.co.za> STINNER Victor added the comment: > I removed futimens because it's now extraneous. futimens() has nice feature: it is possible to only update atime only update mtime, or use "now" as the new atime and/or mtime. 3882 If *_nsec is specified as UTIME_NOW, the timestamp is updated to the\n\ 3883 current time.\n\ 3884 If *_nsec is specified as UTIME_OMIT, the timestamp is not updated. os.utimensat() has the same feature. Is it possible that os.utimensat() is not available whereas os.futimens() is availalble? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 00:15:16 2012 From: report at bugs.python.org (Larry Hastings) Date: Tue, 24 Apr 2012 22:15:16 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1335305716.76.0.581218793096.issue14127@psf.upfronthosting.co.za> Larry Hastings added the comment: > futimens() has nice feature: it is possible to only update atime > only update mtime, or use "now" as the new atime and/or mtime. YAGNI. Worst case, you can use call futimes twice, once with no args, then fstat() it to get the current-ish time and rewrite the fields selectively. Do you have code where you selectively use UTIME_NOW for only one of the two fields? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 00:17:15 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 22:17:15 +0000 Subject: [issue14665] faulthandler prints tracebacks in reverse order Message-ID: <1335305835.2.0.186027990116.issue14665@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Python usually prints traceback from the outer to the inner function: the inner frame is printed last. But faulthandler prints the inner frame first and the outer frame last. ---------- components: Extension Modules messages: 159223 nosy: haypo, pitrou priority: normal severity: normal status: open title: faulthandler prints tracebacks in reverse order type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 00:21:53 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 24 Apr 2012 22:21:53 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335304237.3436.21.camel@localhost.localdomain> Message-ID: <4F97277C.4080507@egenix.com> Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > >> Adding more cruft to getpath.c or similar routines is just going to >> slow down startup time even more... > > The code is already there. Code to detect whether you're running off a checkout vs. a normal installation by looking at even more directories ? I don't see any in getpath.c (and that's good). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 00:29:53 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 22:29:53 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <4F97277C.4080507@egenix.com> Message-ID: <1335306509.3436.22.camel@localhost.localdomain> Antoine Pitrou added the comment: > Code to detect whether you're running off a checkout vs. a normal > installation by looking at even more directories ? I don't > see any in getpath.c (and that's good). Look for "pybuilddir.txt". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 00:33:51 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 22:33:51 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 15a33d7d2b50 by Vinay Sajip in branch '2.7': Issue #14632: Updated WatchedFileHandler to deal with race condition. Thanks to John Mulligan for the problem report and patch. http://hg.python.org/cpython/rev/15a33d7d2b50 New changeset 5de7c3d64f2a by Vinay Sajip in branch '3.2': Issue #14632: Updated WatchedFileHandler to deal with race condition. Thanks to John Mulligan for the problem report and patch. http://hg.python.org/cpython/rev/5de7c3d64f2a New changeset 380821b47872 by Vinay Sajip in branch 'default': Issue #14632: Updated WatchedFileHandler to deal with race condition. Thanks to John Mulligan for the problem report and patch. http://hg.python.org/cpython/rev/380821b47872 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 00:38:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 22:38:13 +0000 Subject: [issue14665] faulthandler prints tracebacks in reverse order In-Reply-To: <1335305835.2.0.186027990116.issue14665@psf.upfronthosting.co.za> Message-ID: <1335307093.45.0.719724929476.issue14665@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. ---------- keywords: +patch nosy: +ncoghlan Added file: http://bugs.python.org/file25355/reverse_frames.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 00:42:11 2012 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 24 Apr 2012 22:42:11 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> Message-ID: <1335307331.41.0.0563409674208.issue14632@psf.upfronthosting.co.za> Vinay Sajip added the comment: I will leave this open for a few days and see if the buildbots throw up anything. ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 00:51:14 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 24 Apr 2012 22:51:14 +0000 Subject: [issue14665] faulthandler prints tracebacks in reverse order In-Reply-To: <1335305835.2.0.186027990116.issue14665@psf.upfronthosting.co.za> Message-ID: <1335307874.67.0.444140711184.issue14665@psf.upfronthosting.co.za> STINNER Victor added the comment: faulthandler has to be as simple as possible because Python internal state may be completly corrupted. faulthandler was written to display the traceback on bugs like invalid memory read or write. I chose to print the traceback as it is stored in memory (from the current frame to the bottom of the stack using f_back). If the traceback is corrupted in the middle of the frame stack, faulthandler displays the first half of the traceback, whereas it would not display anything with your patch. The number of frames is also limited to avoid unlimited loops. The internal state may be corrupted and I don't want to track already seen frames or something like that. With your patch, you may miss where the bug occurred if the stack contains more than 100 frames. The limit is hardcoded and cannot be changed at runtime yet. I already seen a segfault while faulthandler was trying to display the traceback of a segfault, more than once :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 01:01:57 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 24 Apr 2012 23:01:57 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread Message-ID: <1335308517.69.0.701803893151.issue14666@psf.upfronthosting.co.za> New submission from STINNER Victor : [233/364] test_multiprocessing ... [265/364] test_typechecks [266/364] test_socket Timeout (1:00:00)! Thread 0x0000000807235000: File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/socket.py", line 135 in accept File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/multiprocessing/connection.py", line 595 in accept File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/multiprocessing/connection.py", line 469 in accept File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/multiprocessing/reduction.py", line 256 in _serve File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 592 in run File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 635 in _bootstrap_inner File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 612 in _bootstrap Thread 0x0000000801407400: File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_socket.py", line 1208 in check_sendall_interrupted File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_socket.py", line 1219 in test_sendall_interrupted File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/case.py", line 385 in _executeTestPart File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/case.py", line 440 in run File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/case.py", line 492 in __call__ File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 105 in run File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 67 in __call__ File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 105 in run File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 67 in __call__ File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/runner.py", line 168 in run File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/support.py", line 1333 in _run_suite File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/support.py", line 1367 in run_unittest File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_socket.py", line 4813 in test_main File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/regrtest.py", line 1237 in runtest_inner File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/regrtest.py", line 907 in runtest File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/regrtest.py", line 710 in main File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/__main__.py", line 13 in File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/runpy.py", line 73 in _run_code File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/runpy.py", line 160 in _run_module_as_main *** Error code 1 http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/2339/steps/test/logs/stdio ---------- messages: 159230 nosy: haypo, neologix, pitrou priority: normal severity: normal status: open title: test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 01:26:10 2012 From: report at bugs.python.org (STINNER Victor) Date: Tue, 24 Apr 2012 23:26:10 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335308517.69.0.701803893151.issue14666@psf.upfronthosting.co.za> Message-ID: <1335309970.3.0.0250227213726.issue14666@psf.upfronthosting.co.za> STINNER Victor added the comment: There was a similar issue: #11753, but it was a bug in the faulthandler module. Here it looks like a bug in TestSocketSharing of test_socket which uses multiprocessing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 01:34:19 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 23:34:19 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335308517.69.0.701803893151.issue14666@psf.upfronthosting.co.za> Message-ID: <1335310459.24.0.102431082627.issue14666@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ah, this is because of the new daemon thread in ResourceSharer. That thread is never stopped and could receive signals while tests expect them to be delivered to the main thread. Either we add a (private?) facility to stop that thread, or we block signal delivery in that thread using the signal module's pthread_sigmask. What do you think? ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 01:34:53 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 23:34:53 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335308517.69.0.701803893151.issue14666@psf.upfronthosting.co.za> Message-ID: <1335310493.82.0.300392743399.issue14666@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- components: +Library (Lib) stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 01:36:29 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 24 Apr 2012 23:36:29 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335308517.69.0.701803893151.issue14666@psf.upfronthosting.co.za> Message-ID: <1335310589.52.0.549033102166.issue14666@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The pthread_sigmask() solution would allow the use of multiprocessing all the while keeping deterministic signal delivery. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 01:37:05 2012 From: report at bugs.python.org (Roundup Robot) Date: Tue, 24 Apr 2012 23:37:05 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 8aa4737d67d2 by Marc-Andre Lemburg in branch 'default': Issue #14605: Rename _SourcelessFileLoader to SourcelessFileLoader http://hg.python.org/cpython/rev/8aa4737d67d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 01:37:57 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 24 Apr 2012 23:37:57 +0000 Subject: [issue14369] make __closure__ writable In-Reply-To: <1332179477.04.0.11685261564.issue14369@psf.upfronthosting.co.za> Message-ID: <1335310677.08.0.109542213437.issue14369@psf.upfronthosting.co.za> Richard Oudkerk added the comment: The patch causes crashes. If I define def cell(o): def f(): o return f.__closure__[0] def f(): a = 1 b = 2 def g(): return a + b return g g = f() then I find g.__closure__ = None; g() -> crash g.__closure__ = (cell(3),); g() -> crash g.__closure__ = (1, 2); g() -> SystemError * g.__closure__ = (cell(3), cell(4), cell(5)); g() -> returns 7 * SystemError: ..\Objects\cellobject.c:24: bad argument to internal function ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 01:40:00 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 24 Apr 2012 23:40:00 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1335294946.35.0.673656489176.issue14605@psf.upfronthosting.co.za> Message-ID: <4F9739CC.4020308@egenix.com> Marc-Andre Lemburg added the comment: Brett Cannon wrote: > > I documented it explicitly so people can use it if they so choose (e.g. look at sys._getframe()). If you want to change this that's fine, but I am personally not going to put the effort in to rename the class, update the tests, and change the docs for this (we almost stopped allowing the importation of bytecode directly not so long ago but got push-back so we backed off). I renamed the loader and reworded the notice in the docs. Thanks, -- Marc-Andre Lemburg eGenix.com ________________________________________________________________________ 2012-04-28: PythonCamp 2012, Cologne, Germany 3 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 01:52:16 2012 From: report at bugs.python.org (R. David Murray) Date: Tue, 24 Apr 2012 23:52:16 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335311536.97.0.643239861429.issue14605@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. Some at least of the buildbots have failed to build after that patch: ./python ./Python/freeze_importlib.py \ ./Lib/importlib/_bootstrap.py Python/importlib.h make: ./python: Command not found make: *** [Python/importlib.h] Error 127 program finished with exit code 2 (http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/3771) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 01:52:18 2012 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 24 Apr 2012 23:52:18 +0000 Subject: [issue14369] make __closure__ writable In-Reply-To: <1332179477.04.0.11685261564.issue14369@psf.upfronthosting.co.za> Message-ID: <1335311538.7.0.736870688887.issue14369@psf.upfronthosting.co.za> Yury Selivanov added the comment: > The patch causes crashes. Yes, that's known. First, we need to check, that we can only write tuple of cell objects or None in __closure__ (that's easy to add). Secondly, perhaps, we can check __closure__ correctness each time we start evaluating a code object. The latter would offer us better stability, but may also introduce some slowdowns -- need to find some time to implement and benchmark this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 02:10:30 2012 From: report at bugs.python.org (Larry Hastings) Date: Wed, 25 Apr 2012 00:10:30 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1335312630.08.0.984767534511.issue14127@psf.upfronthosting.co.za> Larry Hastings added the comment: Second round of my patch, incorporating nearly all of Victor's suggestions. Thanks, Victor! ---------- Added file: http://bugs.python.org/file25356/larry.utime.ns.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 02:11:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Apr 2012 00:11:18 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e30196bfc11d by Marc-Andre Lemburg in branch 'default': Issue #14605: Revert renaming of _SourcelessFileLoader, since it caused http://hg.python.org/cpython/rev/e30196bfc11d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 02:19:00 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 25 Apr 2012 00:19:00 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335308517.69.0.701803893151.issue14666@psf.upfronthosting.co.za> Message-ID: <1335313140.91.0.16958516381.issue14666@psf.upfronthosting.co.za> Richard Oudkerk added the comment: This patch adds a ResourceSharer.stop() method. This is called from tearDownClass() in the unittest. ---------- keywords: +patch Added file: http://bugs.python.org/file25357/mp_resource_sharer_stop.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 02:27:53 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 25 Apr 2012 00:27:53 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1335311536.97.0.643239861429.issue14605@psf.upfronthosting.co.za> Message-ID: <4F974504.60100@egenix.com> Marc-Andre Lemburg added the comment: R. David Murray wrote: > > R. David Murray added the comment: > > Hmm. Some at least of the buildbots have failed to build after that patch: > > ./python ./Python/freeze_importlib.py \ > ./Lib/importlib/_bootstrap.py Python/importlib.h > make: ./python: Command not found > make: *** [Python/importlib.h] Error 127 > program finished with exit code 2 > > (http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/3771) Thanks for mentioning this. I've reverted the change for now and will have a look tomorrow. The logs of the failing bots are not very informative about what is going on: gcc -pthread -c -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Python/dynamic_annotations.o Python/dynamic_annotations.c gcc -pthread -c -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Python/errors.o Python/errors.c ./python ./Python/freeze_importlib.py \ ./Lib/importlib/_bootstrap.py Python/importlib.h make: ./python: Command not found make: *** [Python/importlib.h] Error 127 program finished with exit code 2 vs. gcc -pthread -c -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Python/dynamic_annotations.o Python/dynamic_annotations.c gcc -pthread -c -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Python/errors.o Python/errors.c gcc -pthread -c -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Python/frozen.o Python/frozen.c gcc -pthread -c -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Python/frozenmain.o Python/frozenmain.c gcc -pthread -c -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Python/future.o Python/future.c I guess some commands are not printed to stdout. Looking at the buildbots again: reverting the patch has not caused the lights to go green again. Very strange indeed. Looking further I found this line in the Makefile: ############################################################################ # Importlib Python/importlib.h: $(srcdir)/Lib/importlib/_bootstrap.py $(srcdir)/Python/freeze_importlib.py ./$(BUILDPYTHON) $(srcdir)/Python/freeze_importlib.py \ $(srcdir)/Lib/importlib/_bootstrap.py Python/importlib.h Since the patch modified _bootstrap.py, make wants to recreate importlib.h, but at that time $(BUILDPYTHON) doesn't yet exist. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 02:29:22 2012 From: report at bugs.python.org (James Lu) Date: Wed, 25 Apr 2012 00:29:22 +0000 Subject: [issue14667] No IDLE Message-ID: <1335313762.17.0.753940415621.issue14667@psf.upfronthosting.co.za> New submission from James Lu : No IDLE 3.26 need badly! High prriority ---------- components: IDLE files: python.exe messages: 159243 nosy: James.Lu priority: normal severity: normal status: open title: No IDLE type: resource usage versions: Python 3.2 Added file: http://bugs.python.org/file25358/python.exe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 02:32:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Apr 2012 00:32:26 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset a2cf07135e4f by Marc-Andre Lemburg in branch 'default': Issue #14605: Rename _SourcelessFileLoader to SourcelessFileLoader. http://hg.python.org/cpython/rev/a2cf07135e4f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 02:39:26 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 25 Apr 2012 00:39:26 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <4F974504.60100@egenix.com> Message-ID: <4F9747BA.2080708@egenix.com> Marc-Andre Lemburg added the comment: Marc-Andre Lemburg wrote: > Looking further I found this line in the Makefile: > > ############################################################################ > # Importlib > > Python/importlib.h: $(srcdir)/Lib/importlib/_bootstrap.py $(srcdir)/Python/freeze_importlib.py > ./$(BUILDPYTHON) $(srcdir)/Python/freeze_importlib.py \ > $(srcdir)/Lib/importlib/_bootstrap.py Python/importlib.h > > Since the patch modified _bootstrap.py, make wants to recreate importlib.h, > but at that time $(BUILDPYTHON) doesn't yet exist. I now ran 'make' after applying the patches to have the importlib.h recreated. This setup looks a bit fragile to me. I think it would be better to make creation of the importlib.h an explicit operation that has to be done in case the Python code changes (e.g. by creating a make target build-importlib.h), with the Makefile only warning about a needed update instead of failing completely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 03:08:48 2012 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 25 Apr 2012 01:08:48 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335316128.23.0.970780324405.issue14605@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 03:10:34 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 25 Apr 2012 01:10:34 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335316234.49.0.354343821246.issue14605@psf.upfronthosting.co.za> Brett Cannon added the comment: You can see a little discussion in http://bugs.python.org/issue14642, but it has been discussed elsewhere and the automatic rebuilding was preferred (but it is not a requirement to build as importlib.h is in hg). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 03:13:43 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 25 Apr 2012 01:13:43 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335316423.43.0.0315808384782.issue14657@psf.upfronthosting.co.za> Brett Cannon added the comment: That solves the "I'm in a checkout" problem but it doesn't tell you necessarily where the Lib directory is if you e.g. build from within another directory like Python/, which places the executable and pybuilddir.txt in the current directory. Now obviously you could argue supporting that case is not worth it for development-sake, but I figured since I knew it existed I should put it out there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 04:53:18 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 25 Apr 2012 02:53:18 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335322398.24.0.58580150308.issue14605@psf.upfronthosting.co.za> Brett Cannon added the comment: I found out why runpy was giving back an absolute file path for __file__; because pkgutil was doing that through its ImpLoader, unlike what import does by default which is just taking what path it has and appending file names (and thus not making anything absolute). So I have simply forced runpy to make absolute paths of the files it is given. Nick, can you have a look and let me know if this fix is reasonable, or if another os.path.abspath() call is needed somewhere in runpy? ---------- Added file: http://bugs.python.org/file25359/explicit_path_hooks.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 04:54:21 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 25 Apr 2012 02:54:21 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335322461.26.0.321260890589.issue14605@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: brett.cannon -> ncoghlan stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 06:02:14 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 25 Apr 2012 04:02:14 +0000 Subject: [issue14443] Distutils test failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <1335326534.01.0.240856518186.issue14443@psf.upfronthosting.co.za> Nick Coghlan added the comment: To answer my last question: plenty of people. Even within Fedora itself there are parallel python 2 and python 3 RPM stacks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 06:21:45 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 25 Apr 2012 04:21:45 +0000 Subject: [issue14443] Distutils test failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <1335327705.88.0.480687379356.issue14443@psf.upfronthosting.co.za> Nick Coghlan added the comment: It occurs to me there's a way to check my theory: if we update the failing test to explicitly check the magic cookie in at least one of the precompiled pyc files (rather than just expecting the files' existence), then it should also start failing on the 2.7 RHEL 6 buildbot. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 06:36:17 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 25 Apr 2012 04:36:17 +0000 Subject: [issue14443] Distutils test failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <1335328577.66.0.0198337767389.issue14443@psf.upfronthosting.co.za> ?ric Araujo added the comment: The most likely cause is that some code was updated to use pycache directories but other code that computes paths still uses the old way; this happened for bdist_wininst too. I?ll have a look at the code and reply to your questions tomorrow. I?ll also add links to another bug where I suggest to print the full command when distutils.spawn fails and DISTUTILS_DEBUG is set and another bug about rpm vs. rpmbuild. this-job-thing-really-takes-much-of-my-Python-time-ly yours ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 07:49:09 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 25 Apr 2012 05:49:09 +0000 Subject: [issue14665] faulthandler prints tracebacks in reverse order In-Reply-To: <1335305835.2.0.186027990116.issue14665@psf.upfronthosting.co.za> Message-ID: <1335332949.45.0.352234246799.issue14665@psf.upfronthosting.co.za> Nick Coghlan added the comment: Victor's argument makes sense to me. What I'd be inclined to do is shout at the reader a bit in the traceback header by making it: Traceback (most recent call FIRST): And put a comment in the source code with the gist of what Victor wrote above (i.e. internal state may be corrupted, we do the best we can with what we've got, and that means printing the traceback from the inside out) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 08:05:28 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 25 Apr 2012 06:05:28 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335333928.86.0.735104569145.issue14605@psf.upfronthosting.co.za> Nick Coghlan added the comment: Yeah, I was actually going to suggest forcing an absolute path for __main__.__file__ in runpy if you didn't want to do it in importlib itself. I'm much happier with that approach than changing the tests, so the updated patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 08:05:59 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 25 Apr 2012 06:05:59 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335333959.56.0.831772769325.issue14605@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: ncoghlan -> brett.cannon stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 08:17:55 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 25 Apr 2012 06:17:55 +0000 Subject: [issue14667] No IDLE In-Reply-To: <1335313762.17.0.753940415621.issue14667@psf.upfronthosting.co.za> Message-ID: <1335334675.08.0.506491617892.issue14667@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Please structure your bug report as follows: 1. this is what you did 2. this is what happened 3. this is what you want to happen instead ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 08:25:27 2012 From: report at bugs.python.org (James Lu) Date: Wed, 25 Apr 2012 06:25:27 +0000 Subject: [issue14667] No IDLE In-Reply-To: <1335334675.08.0.506491617892.issue14667@psf.upfronthosting.co.za> Message-ID: James Lu added the comment: 1,looked for python IDLE 2.NO python #.use text editor (hard) james On Wed, Apr 25, 2012 at 2:17 AM, Martin v. L?wis wrote: > > Martin v. L?wis added the comment: > > Please structure your bug report as follows: > > 1. this is what you did > 2. this is what happened > 3. this is what you want to happen instead > > ---------- > nosy: +loewis > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 08:37:52 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 25 Apr 2012 06:37:52 +0000 Subject: [issue14667] No IDLE In-Reply-To: <1335313762.17.0.753940415621.issue14667@psf.upfronthosting.co.za> Message-ID: <1335335872.44.0.511720941174.issue14667@psf.upfronthosting.co.za> Martin v. L?wis added the comment: 1. how did you look (what operating system, what mouse clicks?) 2. did you not find Python, or did you find Python, and it did not work? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 08:38:31 2012 From: report at bugs.python.org (Kurt Seifried) Date: Wed, 25 Apr 2012 06:38:31 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1335335911.78.0.752792991221.issue14579@psf.upfronthosting.co.za> Kurt Seifried added the comment: Please use CVE-2012-2135 for this issue as per http://www.openwall.com/lists/oss-security/2012/04/25/3 ---------- nosy: +kseifried at redhat.com _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 08:47:00 2012 From: report at bugs.python.org (Huzaifa Sidhpurwala) Date: Wed, 25 Apr 2012 06:47:00 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1335336420.58.0.0236541860292.issue14579@psf.upfronthosting.co.za> Huzaifa Sidhpurwala added the comment: I have not tried the patch yet, but modifying the reproducer yields a different crash. This one seems to be a heap-based buffer overflow which is slightly more serious. In the reproducer, you just need to replace ascii() with str(). Again works on python3 only. ---------- nosy: +Huzaifa.Sidhpurwala _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 08:58:38 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 25 Apr 2012 06:58:38 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1335337118.08.0.80515750079.issue3561@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Brian: The patch is fine, please apply. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 09:10:30 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Apr 2012 07:10:30 +0000 Subject: [issue14665] faulthandler prints tracebacks in reverse order In-Reply-To: <1335332949.45.0.352234246799.issue14665@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Victor's argument makes sense to me. What I'd be inclined to do is shout at the reader a bit in the traceback header by making it: > > ? ?Traceback (most recent call FIRST): The output is something like: Thread 0xf758d8d0: File "/home/edcjones/programs/python/Python-3.3.0a2/Lib/socket.py", line 407 in create_connection File "/home/edcjones/programs/python/Python-3.3.0a2/Lib/imaplib.py", line 236 in _create_socket File "/home/edcjones/programs/python/Python-3.3.0a2/Lib/imaplib.py", line 1201 in _create_socket ... "Thread 0xf758d8d0:" can be replaced with "Thread 0xf758d8d0 (most recent call FIRST):". A "reverse=False" parameter can be added to faulthandler.dump_traceback() and faulthandler.dump_tracebacks_later(). But I prefer to not add it to faulthandler.enable() nor faulthandler.register() because dump_traceback() is called from a signal handler. It may be surprising to have an option on some functions but not on all functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 10:54:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Apr 2012 08:54:58 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset acfdf46b8de1 by Marc-Andre Lemburg in branch 'default': Issue #14605 and #14642: http://hg.python.org/cpython/rev/acfdf46b8de1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 10:54:59 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Apr 2012 08:54:59 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset acfdf46b8de1 by Marc-Andre Lemburg in branch 'default': Issue #14605 and #14642: http://hg.python.org/cpython/rev/acfdf46b8de1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 10:55:35 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 25 Apr 2012 08:55:35 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1335316234.49.0.354343821246.issue14605@psf.upfronthosting.co.za> Message-ID: <4F97BC02.9000005@egenix.com> Marc-Andre Lemburg added the comment: Brett Cannon wrote: > > You can see a little discussion in http://bugs.python.org/issue14642, but it has been discussed elsewhere and the automatic rebuilding was preferred (but it is not a requirement to build as importlib.h is in hg). An automatic rebuild is fine, but only as long as the local ./python actually exists. I was unaware of make rule, so did not run make to check things before the checkin. As a result, the bootstrap module received a more recent timestamp than importlib.h and this caused all the buildbots to force a rebuild of importlib.h - which failed, since they didn't have a built ./python at that stage. I checked in a fix and added a warning to the bootstrap script. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 11:07:32 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 25 Apr 2012 09:07:32 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335306509.3436.22.camel@localhost.localdomain> Message-ID: <4F97BED0.9000200@egenix.com> Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> Code to detect whether you're running off a checkout vs. a normal >> installation by looking at even more directories ? I don't >> see any in getpath.c (and that's good). > > Look for "pybuilddir.txt". Oh dear. Another one of those hacks... why wasn't this done using constants passed in by the configure script and simple string comparison ? BTW: The startup time of python3.3 is 113ms on my machine, that's more than twice as long as python2.7. Given the history, it looks like no one cares about these things anymore... :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 12:12:54 2012 From: report at bugs.python.org (Yuval Greenfield) Date: Wed, 25 Apr 2012 10:12:54 +0000 Subject: [issue13968] Support recursive globs In-Reply-To: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za> Message-ID: <1335348774.14.0.375140317299.issue13968@psf.upfronthosting.co.za> Yuval Greenfield added the comment: I added the doublestar functionality to iglob and updated the docs and tests. Also, a few readability renames in that module were a long time coming. I'd love to hear your feedback. ---------- Added file: http://bugs.python.org/file25360/glob.doublestars.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 12:30:32 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Apr 2012 10:30:32 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1335349832.42.0.889360007116.issue14579@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I now write tests and I have a question. Should b'\xd8\x00\x41'.decode('utf-16be', 'replace') to give '\xfffd' or '\xfffd\xfffd'? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 13:37:27 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 25 Apr 2012 11:37:27 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335308517.69.0.701803893151.issue14666@psf.upfronthosting.co.za> Message-ID: <1335353847.4.0.0180946707138.issue14666@psf.upfronthosting.co.za> Richard Oudkerk added the comment: New version of patch which does signal.pthread_sigmask(signal.SIG_BLOCK, range(1, signal.NSIG)) in the thread (is that right?). It also uses a timeout when trying to join the thread. ---------- Added file: http://bugs.python.org/file25361/mp_resource_sharer_stop.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 13:49:04 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Apr 2012 11:49:04 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <4F97BED0.9000200@egenix.com> Message-ID: <1335354459.3413.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > > Look for "pybuilddir.txt". > > Oh dear. Another one of those hacks... why wasn't this done using > constants passed in by the configure script and simple string > comparison ? How would that help distinguish between an installed Python and a non-installed Python? If you have an idea about that, please open an issue and explain it precisely :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 14:06:41 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 25 Apr 2012 12:06:41 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335354459.3413.1.camel@localhost.localdomain> Message-ID: <4F97E8CC.5030602@egenix.com> Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >>> Look for "pybuilddir.txt". >> >> Oh dear. Another one of those hacks... why wasn't this done using >> constants passed in by the configure script and simple string >> comparison ? > > How would that help distinguish between an installed Python and a > non-installed Python? If you have an idea about that, please open an > issue and explain it precisely :) The question pybuildir.txt apparently tries to solve is whether Python is running from the build dir or not. It's not whether Python was installed or not. Checking for the build dir can be done by looking at the argv[0] of the executable and comparing that to the build dir. This can be compiled into the interpreter using a constant, say BUILDIR. At runtime, you'd simply compare the current argv[0] to the BUILDDIR. If it matches, you know that you can assume the build dir layout with reasonable certainty and proceed accordingly. No need for extra joins, file reads, etc. But given the enormous startup time of Python 3.3, those few stats won't make a difference anyway. This would need a completely different holistic approach. Perhaps something for SoC project. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 14:12:28 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Apr 2012 12:12:28 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <4F97E8CC.5030602@egenix.com> Message-ID: <1335355862.3413.5.camel@localhost.localdomain> Antoine Pitrou added the comment: > The question pybuildir.txt apparently tries to solve is whether Python > is running from the build dir or not. It's not whether Python was > installed or not. That's the same, for all we're concerned. But pybuilddir.txt does not only solve that problem. It also contains the path to extension modules generated by setup.py, so that sys.path can be setup appropriately at startup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 14:14:39 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Apr 2012 12:14:39 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335308517.69.0.701803893151.issue14666@psf.upfronthosting.co.za> Message-ID: <1335356079.07.0.0637512376335.issue14666@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > in the thread (is that right?). This looks like it. > It also uses a timeout when trying to join the thread. Perhaps some kind of warning can be printed if joining fails after the timeout? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 14:28:04 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 25 Apr 2012 12:28:04 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335355862.3413.5.camel@localhost.localdomain> Message-ID: <4F97EDCF.2000906@egenix.com> Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> The question pybuildir.txt apparently tries to solve is whether Python >> is running from the build dir or not. It's not whether Python was >> installed or not. > > That's the same, for all we're concerned. > But pybuilddir.txt does not only solve that problem. It also contains > the path to extension modules generated by setup.py, so that sys.path > can be setup appropriately at startup. Would be easier to tell distutils to install the extensions in a fixed name dir (instead of using a platform and version in the name) and then use that getpath.c. distutils is pretty flexible at that :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 14:32:17 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 25 Apr 2012 12:32:17 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335357137.03.0.367469540365.issue14657@psf.upfronthosting.co.za> Nick Coghlan added the comment: Still no patch from me, but I did create the rudiments of a shared script for poking around at the import internals (Tools/scripts/import_diagnostics.py) Looking at Antoine's patch, I'd be happier with it if it *didn't* mutate the attributes of _frozen_importlib, but instead just added importlib._bootstrap as an alias for accessing it. That would bring it in line with the way we handle os.path as being just an alias for the appropriate top level module: >>> import os.path >>> os.path.__name__ 'posixpath' Getting access to the source level _bootstrap implementation for testing purposes would then just require the usual techniques for bypassing C accelerators (specifically, using test.support.import_fresh_module with "_frozen_importlib" blocked). That would address the immediate problem of module duplication, without misrepresenting what is going on in potentially confusing ways. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 14:38:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Apr 2012 12:38:50 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <4F97EDCF.2000906@egenix.com> Message-ID: <1335357445.3413.6.camel@localhost.localdomain> Antoine Pitrou added the comment: > Would be easier to tell distutils to install the extensions > in a fixed name dir (instead of using a platform and version > in the name) and then use that getpath.c. distutils is pretty > flexible at that :-) Look, this is becoming very off-topic and you aren't proposing anything concrete (I see neither patches nor problems being solved). Could you open another issue, if you care so much? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 14:46:59 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Apr 2012 12:46:59 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335358019.26.0.979285470946.issue14657@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Looking at Antoine's patch, I'd be happier with it if it *didn't* > mutate the attributes of _frozen_importlib, but instead just added > importlib._bootstrap as an alias for accessing it. I thought it would be nicer for __file__, __name__ and __package__ to reflect the actual source code metadata (__file__ is always a py file while __cached__ may point to the compiled bytecode). But I don't have any strong feelings about that. Yes, __file__ can end up misleading if you modify the Python source without recompiling, but I think most people would only read the code without modifying it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 14:47:41 2012 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 25 Apr 2012 12:47:41 +0000 Subject: [issue14660] Implement PEP 420: Implicit Namespace Packages In-Reply-To: <1335265720.13.0.725647299701.issue14660@psf.upfronthosting.co.za> Message-ID: <1335358061.08.0.582800314719.issue14660@psf.upfronthosting.co.za> Eric V. Smith added the comment: I'd really prefer something like: return load_ns_module(fullname, namespace_path) The point being that load_module() as defined in PEP 302 will never be called on NamespaceLoader. The loader only needs to exist to set module.__loader__, and load_module() would never be called from there. So we could pass in a callable named load_ns_module to PathFinder. Then NamespaceLoader's load_module function could be named load_ns_module, made a class or static method. I think I'll experiment with this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 14:50:46 2012 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 25 Apr 2012 12:50:46 +0000 Subject: [issue14660] Implement PEP 420: Implicit Namespace Packages In-Reply-To: <1335265720.13.0.725647299701.issue14660@psf.upfronthosting.co.za> Message-ID: <1335358246.95.0.899153254094.issue14660@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +Yury.Selivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 15:00:37 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Apr 2012 13:00:37 +0000 Subject: [issue14664] Skipping a test mixin gives metaclass error In-Reply-To: <1335303274.85.0.323410405503.issue14664@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset ab3df6979bd0 by Antoine Pitrou in branch '3.2': Issue #14664: It is now possible to use @unittest.skip{If,Unless} on a test class that doesn't inherit from TestCase (i.e. a mixin). http://hg.python.org/cpython/rev/ab3df6979bd0 New changeset 188b96e0ea89 by Antoine Pitrou in branch 'default': Issue #14664: It is now possible to use @unittest.skip{If,Unless} on a test class that doesn't inherit from TestCase (i.e. a mixin). http://hg.python.org/cpython/rev/188b96e0ea89 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 15:01:58 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Apr 2012 13:01:58 +0000 Subject: [issue14664] Skipping a test mixin gives metaclass error In-Reply-To: <1335303274.85.0.323410405503.issue14664@psf.upfronthosting.co.za> Message-ID: <1335358918.32.0.895639358861.issue14664@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Fixed, thanks. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 15:03:02 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 25 Apr 2012 13:03:02 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335308517.69.0.701803893151.issue14666@psf.upfronthosting.co.za> Message-ID: <1335358982.9.0.619096309256.issue14666@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Warning added to patch. ---------- Added file: http://bugs.python.org/file25362/mp_resource_sharer_stop.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 15:13:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Apr 2012 13:13:18 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 4e9f1017355f by Brian Curtin in branch 'default': Fix #3561. Add an option to place the Python installation into the Windows Path environment variable. http://hg.python.org/cpython/rev/4e9f1017355f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 15:25:11 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 25 Apr 2012 13:25:11 +0000 Subject: [issue14668] Document the path option in the Windows installer Message-ID: <1335360311.11.0.51507359107.issue14668@psf.upfronthosting.co.za> New submission from Brian Curtin : Now that #3561 is in, it needs to be mentioned in at least the following places: Doc\whatsnew\3.3.rst Doc\faq\windows.rst http://python.org/download/windows/ could use an update, but that's on a separate SVN repository ---------- assignee: brian.curtin components: Documentation, Installation, Windows messages: 159281 nosy: brian.curtin priority: critical severity: normal stage: needs patch status: open title: Document the path option in the Windows installer type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 15:25:55 2012 From: report at bugs.python.org (Sye van der Veen) Date: Wed, 25 Apr 2012 13:25:55 +0000 Subject: [issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child In-Reply-To: <1309779809.62.0.10199189289.issue12488@psf.upfronthosting.co.za> Message-ID: <1335360355.78.0.244713171331.issue12488@psf.upfronthosting.co.za> Sye van der Veen added the comment: This issue _does_ exist on Windows, and is not limited to the case where the master process exits before its children. The following code, which is almost exactly that from the 2.7.3 documentation, deadlocks on Win7 (Py3.2 and 2.7) and WinXP (Py3.2 and 2.6): from multiprocessing import Process, Pipe import sys def f(conn): #conn.send([42, None, 'hello']) # uncomment second conn.close() if __name__ == "__main__": parent_conn, child_conn = Pipe() p = Process(target=f, args=(child_conn,)) p.start() #child_conn.close() # uncomment first sys.stdout.write( "about to receive\n" ) sys.stdout.write( "%s\n"%parent_conn.recv() ) sys.stdout.write( "received\n" ) p.join() If you "uncomment first", recv raises an EOFError; if you also "uncomment second", recv succeeds. If this behaviour is the same on other platforms, then it seems all that is required is to update the documentation. ---------- nosy: +syeberman versions: +Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 15:26:03 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 25 Apr 2012 13:26:03 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1335360363.44.0.674692711943.issue3561@psf.upfronthosting.co.za> Brian Curtin added the comment: Now that the feature is in, I'm going to track the few places we need to document it in #14668. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 15:39:23 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Apr 2012 13:39:23 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335308517.69.0.701803893151.issue14666@psf.upfronthosting.co.za> Message-ID: <1335361163.91.0.899625209155.issue14666@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hmm, I thought either multiprocessing's logging facilities, or the warnings module, could be used. That way, people have a control over verbosity of stderr messages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 15:40:59 2012 From: report at bugs.python.org (Michael Foord) Date: Wed, 25 Apr 2012 13:40:59 +0000 Subject: [issue14664] Skipping a test mixin gives metaclass error In-Reply-To: <1335303274.85.0.323410405503.issue14664@psf.upfronthosting.co.za> Message-ID: <1335361259.51.0.916787450455.issue14664@psf.upfronthosting.co.za> Michael Foord added the comment: This could go into 2.7 too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 15:57:16 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Apr 2012 13:57:16 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335361163.91.0.899625209155.issue14666@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: mp_resource_sharer_stop.patch: this patch changes two different things, the patch should be splitted. One patch to fix test_socket. One patch to call pthread_sigmask(). I don't think that you should call pthread_sigmask(). It looks like a workaround for this issue, whereas resource_sharer.stop() is the correct fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 16:33:38 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 25 Apr 2012 14:33:38 +0000 Subject: [issue14369] make __closure__ writable In-Reply-To: <1332179477.04.0.11685261564.issue14369@psf.upfronthosting.co.za> Message-ID: <1335364418.37.0.90173217028.issue14369@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Version of patch which checks invariants in the setter and adds tests. ---------- Added file: http://bugs.python.org/file25363/writable_closure_with_checking.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 16:35:54 2012 From: report at bugs.python.org (Chris Lambacher) Date: Wed, 25 Apr 2012 14:35:54 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1335364554.47.0.0972090921596.issue3561@psf.upfronthosting.co.za> Chris Lambacher added the comment: I am really happy to see this as an option in the Windows installer. This has a potential to really reduce the support burden on training new Windows users to use Python and will really help normalize the experience for new users between Windows and POSIX platforms. Unfortunately, from what I can tell, this is OFF by default. I think that is a mistake. The default for something like this is really important because without new users being explicitly told to set it, new users will not. Most new Python users are just going to take the default values and still be confused by not being able to open the console and run python as in the instructions for various new user tutorials (i.e. web frameworks, scientific computing, etc). I understand the issue with installing multiple Python versions, but generally speaking people are going to want to install the latest version and have that be on their path. My sense is that there is a relative minority of Windows users that care about multiple versions of Python would not want their path to be updated. Unfortunately the ones who don't want their path updated are the ones that have driven the installer development at this point and will be most vocal in the Python community. I suggest a compromise which makes adding to the PATH default to ON if another Python version is not installed and/or on the PATH and default to OFF otherwise. It looks like you can use a condition table plus the feature table to check for Python in the path buy I am not exactly an expert with MSI. My quick check found: http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx which says you can do a search for an installed component and then set a property. This should then allow setting of the default state of the feature based on a condition. I really recommend that while we still have a chance to make a change that we think about the goal of this feature and whether making it disabled by default achieves those goals. ---------- nosy: +lambacck _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 16:50:01 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 25 Apr 2012 14:50:01 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1335365401.92.0.573089389354.issue3561@psf.upfronthosting.co.za> Martin v. L?wis added the comment: lambacck: I'm -1, but I'm willing to yield to anybody who wants to be "in charge" of this feature (i.e. Brian, or the release manager). I'm not willing yield to "mere" user requests, as regular users won't have to deal with negative consequences that enabling this by default may have. I'm quite opposed to your proposed conditional approach; I think this will be highly confusing to users. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 16:51:55 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 25 Apr 2012 14:51:55 +0000 Subject: [issue14660] Implement PEP 420: Implicit Namespace Packages In-Reply-To: <1335265720.13.0.725647299701.issue14660@psf.upfronthosting.co.za> Message-ID: <1335365515.37.0.801688631954.issue14660@psf.upfronthosting.co.za> Brett Cannon added the comment: What do you mean the loader is only needed to set __loader__? You need the loader to create the module (or find it in sys.modules to reload), and set all the attributes properly. If you do this then reloading namespace modules will become a special case compared to other loaders as imp.reload() calls module.__loader__.load_module(). This also prevents the creation of an importlib.find_module() which would return the loader to replace imp.find_module() since you now split the API. I realize the finder/loader dichotomy seems superfluous (and most of the time it is), but it has already been heavily exposed and relied on and deviating from it for namespace modules runs the risk of hurting introspection. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 16:56:40 2012 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 25 Apr 2012 14:56:40 +0000 Subject: [issue14660] Implement PEP 420: Implicit Namespace Packages In-Reply-To: <1335265720.13.0.725647299701.issue14660@psf.upfronthosting.co.za> Message-ID: <1335365800.84.0.960851879521.issue14660@psf.upfronthosting.co.za> Eric V. Smith added the comment: Ah. I didn't realize that reload called load_module. I'll back out the change I just made, then. My point was that the original call to load_module isn't made through the normal "a finder returned me a loader, so I'll call it" code path. It's always made through the "I know I have a NamespaceLoader" path. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 16:58:44 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 25 Apr 2012 14:58:44 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335365924.18.0.372574238127.issue14657@psf.upfronthosting.co.za> Brett Cannon added the comment: To answer MAL's question about startup, I benchmarked on my machine using the normal_startup benchmark from hg.python.org/benchmarks and the bootstrap work only caused a 5-6% slowdown in a non-debug build. If you do it in a debug build it's much worse (I think it was 12% when I benchmarked). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:00:46 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 25 Apr 2012 15:00:46 +0000 Subject: [issue14660] Implement PEP 420: Implicit Namespace Packages In-Reply-To: <1335265720.13.0.725647299701.issue14660@psf.upfronthosting.co.za> Message-ID: <1335366046.16.0.941779783599.issue14660@psf.upfronthosting.co.za> Brett Cannon added the comment: The joys of trying to shoehorn into an existing API. I mean short of adding a new sys.namespace_loader instead of an explicit keyword argument to FileFinder I can't think of a better solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:03:54 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 25 Apr 2012 15:03:54 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: <1335366234.57.0.625967328493.issue14642@psf.upfronthosting.co.za> Brett Cannon added the comment: This is where a script could help with printing out a warning if the built Python interpreter is not available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:11:51 2012 From: report at bugs.python.org (Chris Lambacher) Date: Wed, 25 Apr 2012 15:11:51 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1335366711.98.0.355362437327.issue3561@psf.upfronthosting.co.za> Chris Lambacher added the comment: The reason for the conditional approach was to attempt to account for the "negative consequences" of adding enabling this by default. i.e. if you are already a Python developer and install a new version, it will be status quo, but if you are a new Python developer then you will be able to run instructions for packages that work perfectly fine on Windows but are maintained and documented by POSIX users and don't understand that the steps to make things work on Windows are different. I don't care one way or the other about the compromise position but I strongly believe that if someone is installing Python on Windows for the first time they should get a good experience without having to know of the existence of docs like: http://docs.python-guide.org/en/latest/starting/install/win/ This tweet https://twitter.com/#!/zedshaw/status/194853198006198272 is characteristic of the sentiment that non-Windows users have about training Windows users to develop with Python. At the PyCon web summit several people who have been doing training lately have said that their solution is to get windows users to run a Linux Virtual Machine because the Windows Python experience is so bad for new Windows developers. This is one relatively easy place where we can make that experience better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:14:59 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 25 Apr 2012 15:14:59 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335366899.52.0.47982029836.issue14657@psf.upfronthosting.co.za> Nick Coghlan added the comment: OK, I'm leaning back towards my original preference of getting _frozen_importlib out of the way as quickly as we can. Specifically, I'm thinking of separating out the entry point used by importlib.__init__ from that used by pythonrun.c, such that the latter calls a "_bootstrap_from_frozen" function that returns a reference to "importlib._bootstrap", which pythonrun then places in the interpreter state. There would be a few builtin modules that still end up with loaders from _frozen_importlib (specifically, those referenced from importlib._bootstrap._setup as well as importlib itself), but the vast majority of imported modules would only see the "real" versions from importlib._bootstrap. Attached patch is an initial attempt (the reference counting on the two modules is likely still a bit dodgy - this is my first version that didn't segfault as I got used to the mechanics of dealing with a frozen module, so it errs on the side of leaking references) ---------- Added file: http://bugs.python.org/file25364/issue14657_bootstrap_from_disk.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:16:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Apr 2012 15:16:54 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335308517.69.0.701803893151.issue14666@psf.upfronthosting.co.za> Message-ID: <1335367014.75.0.69258586538.issue14666@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I don't think that you should call pthread_sigmask(). It looks like a > workaround for this issue, whereas resource_sharer.stop() is the > correct fix. The problem is not only with test_multiprocessing and test_socket; any test which uses multiprocessing could have side effects on any subsequent tests which uses signals. Also, applicative code could be affected. So I think pthread_sigmask() *is* the solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:20:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Apr 2012 15:20:50 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1335364554.47.0.0972090921596.issue3561@psf.upfronthosting.co.za> Message-ID: <1335367165.3465.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > Unfortunately, from what I can tell, this is OFF by default. I think > that is a mistake. The default for something like this is really > important because without new users being explicitly told to set it, > new users will not. Most new Python users are just going to take the > default values and still be confused by not being able to open the > console and run python as in the instructions for various new user > tutorials (i.e. web frameworks, scientific computing, etc). To put things in perspective, the default under POSIX ("make install") is to make the installed version the default (by copying it into /usr/bin/python3). To change that behaviour, you have to use "make altinstall" explicitly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:25:49 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Apr 2012 15:25:49 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335366899.52.0.47982029836.issue14657@psf.upfronthosting.co.za> Message-ID: <1335367464.3465.2.camel@localhost.localdomain> Antoine Pitrou added the comment: > Attached patch is an initial attempt (the reference counting on the > two modules is likely still a bit dodgy - this is my first version > that didn't segfault as I got used to the mechanics of dealing with a > frozen module, so it errs on the side of leaking references) But does it make debugging any easier? The IO streams are not yet initialized at that point (neither are the codecs), so you are executing _bootstrap.py from a very bare interpreter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:32:41 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Apr 2012 15:32:41 +0000 Subject: [issue14664] Skipping a test mixin gives metaclass error In-Reply-To: <1335303274.85.0.323410405503.issue14664@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 8a8d2f05068a by Antoine Pitrou in branch '2.7': Issue #14664: It is now possible to use @unittest.skip{If,Unless} on a test class that doesn't inherit from TestCase (i.e. a mixin). http://hg.python.org/cpython/rev/8a8d2f05068a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:32:56 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Apr 2012 15:32:56 +0000 Subject: [issue14664] Skipping a test mixin gives metaclass error In-Reply-To: <1335303274.85.0.323410405503.issue14664@psf.upfronthosting.co.za> Message-ID: <1335367976.53.0.846153105225.issue14664@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > This could go into 2.7 too. Done! ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:38:46 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 25 Apr 2012 15:38:46 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335368326.26.0.354857964338.issue14657@psf.upfronthosting.co.za> Nick Coghlan added the comment: Yes, in that you'll be able to pick up changes in _bootstrap.py *without* having to rebuild Python. With this in place, we could then get rid of the automatic regeneration of importlib.h which is a complete nightmare if you ever break your built interpreter while hacking on the bootstrapping (as I now know from experience). With my approach, the experience is instead: - modify _bootstrap.py, hack until any new tests pass - run a new explicit "make freeze_importlib" command - run "make" - check everything still works - commit and push If you forget to run "make freeze_importlib", it doesn't really matter all that much, since the frozen one will only be used to find the real one, so it isn't a disaster if it's a little out of date. (That said, we should still have a test that at least checks the two modules have the same attributes) It does mean that importlib.__init__ also needs to be able to run in a partially initialised interpreter, hence the switch from "import imp" to "import _imp". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:39:50 2012 From: report at bugs.python.org (Kurt Seifried) Date: Wed, 25 Apr 2012 15:39:50 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1335368390.31.0.0932211312937.issue14579@psf.upfronthosting.co.za> Changes by Kurt Seifried : ---------- nosy: -kseifried at redhat.com _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:39:57 2012 From: report at bugs.python.org (Michael Foord) Date: Wed, 25 Apr 2012 15:39:57 +0000 Subject: [issue14664] Skipping a test mixin gives metaclass error In-Reply-To: <1335303274.85.0.323410405503.issue14664@psf.upfronthosting.co.za> Message-ID: <1335368397.89.0.909927858318.issue14664@psf.upfronthosting.co.za> Michael Foord added the comment: Thanks Antoine - much appreciated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:41:35 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 25 Apr 2012 15:41:35 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335368495.19.0.618051589178.issue14657@psf.upfronthosting.co.za> Nick Coghlan added the comment: Actually, rather than a test in test suite, we would just change the current automatic rebuild to a Modules/Setup style "'Lib/importlib._bootstrap.py' is newer than 'Python/importlib.h', you may need to run 'make freeze_importlib'" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:42:50 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 25 Apr 2012 15:42:50 +0000 Subject: [issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za> Message-ID: <1335368570.68.0.0357984928887.issue3561@psf.upfronthosting.co.za> ?ric Araujo added the comment: [Jeff Dean] > If a goal is to make it easy for new users to run python, consider installing a desktop shortcut. > This would make it very easy for new users (easier than starting up a shell). > This is independent of the Path changes discussed here. Hi Jeff; thanks for the suggestion. Could you open another bug report for it? It?s much more manageable to have one request per report. Thanks in advance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:43:41 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 25 Apr 2012 15:43:41 +0000 Subject: [issue14668] Document the path option in the Windows installer In-Reply-To: <1335360311.11.0.51507359107.issue14668@psf.upfronthosting.co.za> Message-ID: <1335368621.17.0.936270516527.issue14668@psf.upfronthosting.co.za> ?ric Araujo added the comment: Don?t forget Doc/using/windows.rst and maybe the various FAQs too (general FAQ, using FAQ, devguide FAQ). ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:52:22 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 25 Apr 2012 15:52:22 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335369142.9.0.0824018242356.issue14657@psf.upfronthosting.co.za> ?ric Araujo added the comment: > How do we currently tell that the interpreter is running in a checkout? sysconfig.is_python_build() Someone has to confirm that this works on Windows too, as I?ve been told that not installed vs. installed is less clear on that OS. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:53:48 2012 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 25 Apr 2012 15:53:48 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1335369228.98.0.182911561183.issue1521950@psf.upfronthosting.co.za> Changes by Vinay Sajip : Added file: http://bugs.python.org/file25365/9252961a03e7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:55:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Apr 2012 15:55:45 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335368495.19.0.618051589178.issue14657@psf.upfronthosting.co.za> Message-ID: <1335369259.3465.7.camel@localhost.localdomain> Antoine Pitrou added the comment: > Actually, rather than a test in test suite, we would just change the > current automatic rebuild to a Modules/Setup style > "'Lib/importlib._bootstrap.py' is newer than 'Python/importlib.h', you > may need to run 'make freeze_importlib'" -1 from me. Nobody pays attention to this kind of warning. (and the Modules/Setup thing is a nuisance) Really, we must unsure that the frozen version of importlib is up-to-date. Also, normally you would write your tests in test_import, so that the builtin import *is* tested. So you have to regenerate importlib before committing (or you break the buildbots). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:56:28 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 25 Apr 2012 15:56:28 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: <1335369388.45.0.793721825574.issue14642@psf.upfronthosting.co.za> ?ric Araujo added the comment: > The status quo seems to work, but people like Georg think it's partially luck that > it does and if hg changes its semantics that will cause us trouble. Could you expand on that? ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 17:58:29 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 25 Apr 2012 15:58:29 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335369509.36.0.600663111913.issue14657@psf.upfronthosting.co.za> Nick Coghlan added the comment: The other advantage of splitting the entry points is that we can tweak Brett's plan to make the import machinery explicit such that it happens in a separate function that's only called from __init__.py. That way the published hooks will always be from the on-disk implementation and never from the frozen one. If you're after the ability to emit debugging messages in a way that doesn't cause fatal errors during system startup, the only way I can see is to have a "do nothing" module level display function in _bootstrap.py that is later replaced with a reference to builtins.print: def _debug(*args, **kwds): pass ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 18:02:27 2012 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 25 Apr 2012 16:02:27 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335369747.82.0.825944228714.issue14657@psf.upfronthosting.co.za> Nick Coghlan added the comment: At the very least, failing to regenerate importlib.h shouldn't be a fatal build error. It should just run with what its got, and hopefully you will get a working interpreter out the other end, such that you can regenerate the frozen module on the next pass. If we change that, then I'm OK with keeping the automatic rebuild. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 18:03:20 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 25 Apr 2012 16:03:20 +0000 Subject: [issue14660] Implement PEP 420: Implicit Namespace Packages In-Reply-To: <1335265720.13.0.725647299701.issue14660@psf.upfronthosting.co.za> Message-ID: <1335369800.89.0.434979017516.issue14660@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 18:16:51 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Apr 2012 16:16:51 +0000 Subject: [issue14669] test_multiprocessing failure on OS X Tiger Message-ID: <1335370611.47.0.977907847024.issue14669@psf.upfronthosting.co.za> New submission from Antoine Pitrou : The OS X Tiger fails more or less intermittently on one of the new multiprocessing tests: ====================================================================== FAIL: test_pickling (test.test_multiprocessing.WithProcessesTestPicklingConnections) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_multiprocessing.py", line 2032, in test_pickling self.assertEqual(new_conn.recv(100), msg.upper()) AssertionError: b'' != b'THIS CONNECTION USES A NORMAL SOCKET' http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x/builds/4408/steps/test/logs/stdio ---------- components: Library (Lib), Tests messages: 159312 nosy: pitrou, sbt priority: normal severity: normal status: open title: test_multiprocessing failure on OS X Tiger type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 18:25:17 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 25 Apr 2012 16:25:17 +0000 Subject: [issue14443] Distutils test_bdist_rpm failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <1335371117.79.0.36043798591.issue14443@psf.upfronthosting.co.za> ?ric Araujo added the comment: > I'm wondering if there may be a deeper problem here: how certain are we that bdist_rpm isn't using the system Python > to handle the byte compilation step? It would explain why the files are still being generated in the old locations. I?ve had a quick look at bdist_rpm and found nothing suspect (like filename + 'c'). You may have the right idea: There are --python and --fix-python options for this command that decide what executable will be used to run setup.py, so maybe the system Python is used. The default is 'python' instead of 'python3' though, so if that?s the cause I don?t understand how it worked at all. > It occurs to me there's a way to check my theory: if we update the failing test to explicitly check the magic cookie in at > least one of the precompiled pyc files (rather than just expecting the files' existence), then it should also start failing > on the 2.7 RHEL 6 buildbot. I?ve been looking for a way to inspect byte-compiled files for some time; please share any ideas on #13473. To help debug this, I could apply #11599. The rpm vs. rpmbuild bug is #11122. #5875 and #13307 are bugs similar to this one. ---------- assignee: -> eric.araujo components: +Distutils title: Distutils test failure -> Distutils test_bdist_rpm failure _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 18:28:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Apr 2012 16:28:11 +0000 Subject: [issue11599] Useless error message when distutils fails compiling In-Reply-To: <1300473236.84.0.248517729635.issue11599@psf.upfronthosting.co.za> Message-ID: <1335371291.97.0.324815290191.issue11599@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 18:30:57 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 25 Apr 2012 16:30:57 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: <1335371457.37.0.799550715768.issue14642@psf.upfronthosting.co.za> Brett Cannon added the comment: When you do a fresh checkout, Python/importlib.h comes after Lib/importlib/_bootstrap.py and Python/freeze_importlib.py in a lexicographical sort which leads to it have a newer timestamp and thus not triggering a new build of the file. This is why Martin suggested at some point using hg status or something from a script to properly detect if something has changed that would warrant rebuilding. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 18:40:45 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 25 Apr 2012 16:40:45 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335372045.3.0.94370919356.issue14657@psf.upfronthosting.co.za> Brett Cannon added the comment: So how would you tweak the explicit work I'm doing? The code is going to rely on sys.path_hooks and sys.meta_path being populated. I guess the frozen code can set up initially, and then importlib simply substitutes out classes from the frozen module to the code from the source version (which should be easy based on __class__ and __class__.__name__ or something). Or if you do this before anyone else (e.g. zipimport) gets to sys.path_hooks and sys.meta_path then you could just blow them away without care and simply set them up again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 18:43:34 2012 From: report at bugs.python.org (Henri Salo) Date: Wed, 25 Apr 2012 16:43:34 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1335372214.32.0.818700897926.issue14579@psf.upfronthosting.co.za> Henri Salo added the comment: Debian bug-report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670389 Found in versions python3-defaults/3.2.3~rc1-2, python3-defaults/3.1.3-12+squeeze1 ---------- nosy: +Henri.Salo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 18:46:10 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 25 Apr 2012 16:46:10 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335369747.82.0.825944228714.issue14657@psf.upfronthosting.co.za> Message-ID: <4F982A4D.4020502@egenix.com> Marc-Andre Lemburg added the comment: Nick Coghlan wrote: > > Nick Coghlan added the comment: > > At the very least, failing to regenerate importlib.h shouldn't be a fatal build error. It should just run with what its got, and hopefully you will get a working interpreter out the other end, such that you can regenerate the frozen module on the next pass. > > If we change that, then I'm OK with keeping the automatic rebuild. I fixed that already today. You now get a warning message from make, but no build error across all buildbots like I had run into yesterday when working on the code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 18:58:03 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Apr 2012 16:58:03 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1335373083.16.0.227787887686.issue14579@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 18:59:01 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 25 Apr 2012 16:59:01 +0000 Subject: [issue11599] Useless error message when distutils fails compiling In-Reply-To: <1300473236.84.0.248517729635.issue11599@psf.upfronthosting.co.za> Message-ID: <1335373141.46.0.812470299322.issue11599@psf.upfronthosting.co.za> ?ric Araujo added the comment: I will apply this this week; I don?t think I need to ask the ML after all, the output is already different when you run with DISTUTILS_DEBUG ? and it?s debug mode anyway, not regular use, so I don?t foresee any compat issue. ---------- versions: -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 18:59:08 2012 From: report at bugs.python.org (Henri Salo) Date: Wed, 25 Apr 2012 16:59:08 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1335373148.47.0.985966842621.issue14579@psf.upfronthosting.co.za> Henri Salo added the comment: I tested versions 3.1.1, 3.1.2, 3.1.3, 3.1.4 and 3.1.5 and only 3.1.3 crashed with Segmentation fault: Program received signal SIGSEGV, Segmentation fault. 0x00000000004c483a in PyObject_Call (func=0x7ffff7e4d3b0, arg=0x7ffff70fd410, kw=0x0) at Objects/abstract.c:2156 2156 if ((call = func->ob_type->tp_call) != NULL) { (gdb) bt #0 0x00000000004c483a in PyObject_Call (func=0x7ffff7e4d3b0, arg=0x7ffff70fd410, kw=0x0) at Objects/abstract.c:2156 #1 0x000000000045c437 in do_call (f=0x8929b0, throwflag=) at Python/ceval.c:3982 #2 call_function (f=0x8929b0, throwflag=) at Python/ceval.c:3785 #3 PyEval_EvalFrameEx (f=0x8929b0, throwflag=) at Python/ceval.c:2548 #4 0x000000000045e675 in PyEval_EvalCodeEx (co=0x7ffff7159e30, globals=, locals=, args=0x0, argcount=1, kws=, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3198 #5 0x000000000045e77b in PyEval_EvalCode (co=0x7ffff7e4d3b0, globals=0x7ffff70fd410, locals=0x0) at Python/ceval.c:668 #6 0x00000000004800b2 in run_mod (fp=, filename=, flags=0x7fffffffe390) at Python/pythonrun.c:1711 #7 PyRun_InteractiveOneFlags (fp=, filename=, flags=0x7fffffffe390) at Python/pythonrun.c:1104 #8 0x00000000004803ce in PyRun_InteractiveLoopFlags (fp=0x7ffff75346a0, filename=0x5312a1 "", flags=0x7fffffffe390) at Python/pythonrun.c:1006 #9 0x0000000000480bab in PyRun_AnyFileExFlags (fp=0x7ffff75346a0, filename=0x5312a1 "", closeit=0, flags=0x7fffffffe390) at Python/pythonrun.c:975 #10 0x0000000000496422 in Py_Main (argc=, argv=) at Modules/main.c:607 #11 0x0000000000416e6e in main (argc=, argv=) at ./Modules/python.c:152 ---------- versions: +Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 19:02:00 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Apr 2012 17:02:00 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335308517.69.0.701803893151.issue14666@psf.upfronthosting.co.za> Message-ID: <1335373320.53.0.257986184198.issue14666@psf.upfronthosting.co.za> STINNER Victor added the comment: mp_resource_sharer_stop.patch: you should add a timeout argument to stop() instead of hardcoding a timeout of 5 seconds. It is maybe safer to block until the thread exits by default (so timeout=None by default). For the new method: it may be nice to document it. Having to import resource_sharer from multiprocessing.reduction is maybe not the best possible API :-/ + from multiprocessing.reduction import resource_sharer + resource_sharer.stop() > Also, applicative code could be affected. What is the effect of the patch? For example, on CTRL+c? I don't know the multiprocessing module nor this "resource sharer" thread. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 19:21:56 2012 From: report at bugs.python.org (Pedro Larroy) Date: Wed, 25 Apr 2012 17:21:56 +0000 Subject: [issue14670] subprocess.call with pipe character in argument Message-ID: <1335374516.95.0.470714396537.issue14670@psf.upfronthosting.co.za> New submission from Pedro Larroy : When running a command with pipe character as argument the result is not the same as in commandline For example: >>> subprocess.call([r"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Commo n7\IDE\devenv","/build",r"Debug|x64","gpc10.sln"], shell=False) Chockes on Debug|x64 and just exits with 1. Running python 2.7.1 r271:86832 ---------- components: Windows messages: 159322 nosy: Pedro.Larroy priority: normal severity: normal status: open title: subprocess.call with pipe character in argument type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 19:25:59 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 25 Apr 2012 17:25:59 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335373320.53.0.257986184198.issue14666@psf.upfronthosting.co.za> Message-ID: <1335374673.3465.14.camel@localhost.localdomain> Antoine Pitrou added the comment: > For the new method: it may be nice to document it. Having to import > resource_sharer from multiprocessing.reduction is maybe not the best > possible API :-/ resource_sharer is a private API, it's not meant to be used by anyone outside of the stdlib. > What is the effect of the patch? For example, on CTRL+c? Why should it have an effect on CTRL+c? Please explain yourself better. > I don't know the multiprocessing module nor this "resource sharer" > thread. Time to learn about them perhaps :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 19:31:05 2012 From: report at bugs.python.org (Steven Winfield) Date: Wed, 25 Apr 2012 17:31:05 +0000 Subject: [issue13789] _tkinter does not build on Windows 7 In-Reply-To: <1326603556.49.0.117233546142.issue13789@psf.upfronthosting.co.za> Message-ID: <1335375065.61.0.0568565464237.issue13789@psf.upfronthosting.co.za> Steven Winfield added the comment: The tk sources (at least the 8.5.11 version I'm looking at now) have some X11 headers that can be used by the windows build in the "xlib" directory. ---------- nosy: +steven.winfield _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 19:44:50 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 25 Apr 2012 17:44:50 +0000 Subject: [issue14579] Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1335349832.42.0.889360007116.issue14579@psf.upfronthosting.co.za> Message-ID: <1335376031.5394.13.camel@raxxla> Serhiy Storchaka added the comment: I thought it was one error, and not two. The updated patch adds tests and fixes minor mistake. 2.7 is not affected by main security issue, but it contains one of mentioned bugs (read 1 byte outside of the input array). A patch for 2.7 fixes this bug and also includes tests. ---------- Added file: http://bugs.python.org/file25366/utf16_error_handling-3.2_4.patch Added file: http://bugs.python.org/file25367/utf16_error_handling-2.7.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r b07488490001 Lib/test/test_codecs.py --- a/Lib/test/test_codecs.py Fri Apr 20 14:36:47 2012 +0200 +++ b/Lib/test/test_codecs.py Wed Apr 25 20:08:37 2012 +0300 @@ -540,8 +540,19 @@ ) def test_errors(self): - self.assertRaises(UnicodeDecodeError, codecs.utf_16_le_decode, - b"\xff", "strict", True) + tests = [ + (b'\xff', '\ufffd'), + (b'A\x00Z', 'A\ufffd'), + (b'A\x00B\x00C\x00D\x00Z', 'ABCD\ufffd'), + (b'\x00\xd8', '\ufffd'), + (b'\x00\xd8A', '\ufffd'), + (b'\x00\xd8A\x00', '\ufffdA'), + (b'\x00\xdcA\x00', '\ufffdA'), + ] + for raw, expected in tests: + self.assertRaises(UnicodeDecodeError, codecs.utf_16_le_decode, + raw, 'strict', True) + self.assertEqual(raw.decode('utf-16le', 'replace'), expected) def test_nonbmp(self): self.assertEqual("\U00010203".encode(self.encoding), @@ -568,8 +579,19 @@ ) def test_errors(self): - self.assertRaises(UnicodeDecodeError, codecs.utf_16_be_decode, - b"\xff", "strict", True) + tests = [ + (b'\xff', '\ufffd'), + (b'\x00A\xff', 'A\ufffd'), + (b'\x00A\x00B\x00C\x00DZ', 'ABCD\ufffd'), + (b'\xd8\x00', '\ufffd'), + (b'\xd8\x00\xdc', '\ufffd'), + (b'\xd8\x00\x00A', '\ufffdA'), + (b'\xdc\x00\x00A', '\ufffdA'), + ] + for raw, expected in tests: + self.assertRaises(UnicodeDecodeError, codecs.utf_16_be_decode, + raw, 'strict', True) + self.assertEqual(raw.decode('utf-16be', 'replace'), expected) def test_nonbmp(self): self.assertEqual("\U00010203".encode(self.encoding), diff -r b07488490001 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Apr 20 14:36:47 2012 +0200 +++ b/Objects/unicodeobject.c Wed Apr 25 20:08:37 2012 +0300 @@ -3425,7 +3425,7 @@ /* Unpack UTF-16 encoded data */ p = unicode->str; q = (unsigned char *)s; - e = q + size - 1; + e = q + size; if (byteorder) bo = *byteorder; @@ -3476,8 +3476,20 @@ #endif aligned_end = (const unsigned char *) ((size_t) e & ~LONG_PTR_MASK); - while (q < e) { + while (1) { Py_UNICODE ch; + if (e - q < 2) { + /* remaining byte at the end? (size should be even) */ + if (q == e || consumed) + break; + errmsg = "truncated data"; + startinpos = ((const char *)q) - starts; + endinpos = ((const char *)e) - starts; + outpos = p - PyUnicode_AS_UNICODE(unicode); + goto utf16Error; + /* The remaining input chars are ignored if the callback + chooses to skip the input */ + } /* First check for possible aligned read of a C 'long'. Unaligned reads are more expensive, better to defer to another iteration. */ if (!((size_t) q & LONG_PTR_MASK)) { @@ -3546,8 +3558,8 @@ } p = _p; q = _q; - if (q >= e) - break; + if (e - q < 2) + continue; } ch = (q[ihi] << 8) | q[ilo]; @@ -3559,10 +3571,10 @@ } /* UTF-16 code pair: */ - if (q > e) { + if (e - q < 2) { errmsg = "unexpected end of data"; startinpos = (((const char *)q) - 2) - starts; - endinpos = ((const char *)e) + 1 - starts; + endinpos = ((const char *)e) - starts; goto utf16Error; } if (0xD800 <= ch && ch <= 0xDBFF) { @@ -3606,31 +3618,9 @@ &outpos, &p)) goto onError; - } - /* remaining byte at the end? (size should be even) */ - if (e == q) { - if (!consumed) { - errmsg = "truncated data"; - startinpos = ((const char *)q) - starts; - endinpos = ((const char *)e) + 1 - starts; - outpos = p - PyUnicode_AS_UNICODE(unicode); - if (unicode_decode_call_errorhandler( - errors, - &errorHandler, - "utf16", errmsg, - &starts, - (const char **)&e, - &startinpos, - &endinpos, - &exc, - (const char **)&q, - &unicode, - &outpos, - &p)) - goto onError; - /* The remaining input chars are ignored if the callback - chooses to skip the input */ - } + /* Update data because unicode_decode_call_errorhandler might have + changed the input object. */ + aligned_end = (const unsigned char *) ((size_t) e & ~LONG_PTR_MASK); } if (byteorder) -------------- next part -------------- diff -r ab9d6c4907e7 Lib/test/test_codecs.py --- a/Lib/test/test_codecs.py Thu Apr 19 23:55:01 2012 +0200 +++ b/Lib/test/test_codecs.py Wed Apr 25 20:08:19 2012 +0300 @@ -495,7 +495,20 @@ ) def test_errors(self): - self.assertRaises(UnicodeDecodeError, codecs.utf_16_le_decode, "\xff", "strict", True) + tests = [ + (b'\xff', u'\ufffd'), + (b'A\x00Z', u'A\ufffd'), + (b'A\x00B\x00C\x00D\x00Z', u'ABCD\ufffd'), + (b'\x00\xd8', u'\ufffd'), + (b'\x00\xd8A', u'\ufffd'), + (b'\x00\xd8A\x00', u'\ufffdA'), + (b'\x00\xdcA\x00', u'\ufffdA'), + ] + for raw, expected in tests: + print('*****', raw, expected) + self.assertRaises(UnicodeDecodeError, codecs.utf_16_le_decode, + raw, 'strict', True) + self.assertEqual(raw.decode('utf-16le', 'replace'), expected) class UTF16BETest(ReadTest): encoding = "utf-16-be" @@ -516,7 +529,20 @@ ) def test_errors(self): - self.assertRaises(UnicodeDecodeError, codecs.utf_16_be_decode, "\xff", "strict", True) + tests = [ + (b'\xff', u'\ufffd'), + (b'\x00A\xff', u'A\ufffd'), + (b'\x00A\x00B\x00C\x00DZ', u'ABCD\ufffd'), + (b'\xd8\x00', u'\ufffd'), + (b'\xd8\x00\xdc', u'\ufffd'), + (b'\xd8\x00\x00A', u'\ufffdA'), + (b'\xdc\x00\x00A', u'\ufffdA'), + ] + for raw, expected in tests: + print('*****', raw, expected) + self.assertRaises(UnicodeDecodeError, codecs.utf_16_be_decode, + raw, 'strict', True) + self.assertEqual(raw.decode('utf-16be', 'replace'), expected) class UTF8Test(ReadTest): encoding = "utf-8" diff -r ab9d6c4907e7 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Thu Apr 19 23:55:01 2012 +0200 +++ b/Objects/unicodeobject.c Wed Apr 25 20:08:19 2012 +0300 @@ -2564,7 +2564,7 @@ } /* UTF-16 code pair: */ - if (q >= e) { + if (e - q < 2) { errmsg = "unexpected end of data"; startinpos = (((const char *)q)-2)-starts; endinpos = ((const char *)e)-starts; From report at bugs.python.org Wed Apr 25 19:45:30 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Apr 2012 17:45:30 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 5fea362b92fc by Marc-Andre Lemburg in branch 'default': Issue #14605 and #14642: Issue a warning in case Python\importlib.h needs to http://hg.python.org/cpython/rev/5fea362b92fc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 19:45:30 2012 From: report at bugs.python.org (Roundup Robot) Date: Wed, 25 Apr 2012 17:45:30 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 5fea362b92fc by Marc-Andre Lemburg in branch 'default': Issue #14605 and #14642: Issue a warning in case Python\importlib.h needs to http://hg.python.org/cpython/rev/5fea362b92fc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 19:46:58 2012 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 25 Apr 2012 17:46:58 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <4F982A4D.4020502@egenix.com> Message-ID: <4F98388E.2050700@egenix.com> Marc-Andre Lemburg added the comment: Marc-Andre Lemburg wrote: > > Marc-Andre Lemburg added the comment: > > Nick Coghlan wrote: >> >> Nick Coghlan added the comment: >> >> At the very least, failing to regenerate importlib.h shouldn't be a fatal build error. It should just run with what its got, and hopefully you will get a working interpreter out the other end, such that you can regenerate the frozen module on the next pass. >> >> If we change that, then I'm OK with keeping the automatic rebuild. > > I fixed that already today. See http://bugs.python.org/issue14605 and http://hg.python.org/lookup/acfdf46b8de1 + http://hg.python.org/cpython/rev/5fea362b92fc > You now get a warning message from make, but no build error across > all buildbots like I had run into yesterday when working on the code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 19:53:32 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 25 Apr 2012 17:53:32 +0000 Subject: [issue14670] subprocess.call with pipe character in argument In-Reply-To: <1335374516.95.0.470714396537.issue14670@psf.upfronthosting.co.za> Message-ID: <1335376412.98.0.349756663021.issue14670@psf.upfronthosting.co.za> R. David Murray added the comment: If shell is false, the pipe character is not special. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 19:55:46 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 25 Apr 2012 17:55:46 +0000 Subject: [issue14670] subprocess.call with pipe character in argument In-Reply-To: <1335374516.95.0.470714396537.issue14670@psf.upfronthosting.co.za> Message-ID: <1335376546.38.0.744263572043.issue14670@psf.upfronthosting.co.za> R. David Murray added the comment: Oops, I typed too fact, and didn't notice that you were talking about windows. My point may still be valid, but I shouldn't be the one to close the issue since I don't know for sure for windows. ---------- nosy: +brian.curtin status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 19:56:02 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 25 Apr 2012 17:56:02 +0000 Subject: [issue14670] subprocess.call with pipe character in argument In-Reply-To: <1335374516.95.0.470714396537.issue14670@psf.upfronthosting.co.za> Message-ID: <1335376562.05.0.389027179297.issue14670@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- Removed message: http://bugs.python.org/msg159330 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 19:56:33 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 25 Apr 2012 17:56:33 +0000 Subject: [issue14670] subprocess.call with pipe character in argument In-Reply-To: <1335374516.95.0.470714396537.issue14670@psf.upfronthosting.co.za> Message-ID: <1335376593.11.0.326042360482.issue14670@psf.upfronthosting.co.za> R. David Murray added the comment: Oops, I typed too fast, and didn't notice that you were talking about windows. My point may still be valid, but I shouldn't be the one to close the issue since I don't know for sure for windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 20:33:01 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 25 Apr 2012 18:33:01 +0000 Subject: [issue14579] CVE-2012-2135: Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1335378781.27.0.820183948359.issue14579@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- title: Vulnerability in the utf-16 decoder after error handling -> CVE-2012-2135: Vulnerability in the utf-16 decoder after error handling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 20:39:15 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 25 Apr 2012 18:39:15 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: <1335379155.8.0.0913718531286.issue14642@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm working on a "hg touch" extension which is able to bring the time stamps back in correct order after a checkout. One would either do "make touch" after an update, or register that extension as a post-update action in .hg/hgrc. It will be controlled by a versioned .hgtouch file, that uses make(1) dependency syntax. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 21:34:33 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 25 Apr 2012 19:34:33 +0000 Subject: [issue1522400] irda socket support Message-ID: <1335382473.36.0.198593864993.issue1522400@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Your updated patch looks fine to me. I don't see any reason not to commit it and mention it in the release notes. If it has bugs, they can be discovered and fixed later by people with actual relevant hardware an interest. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 22:06:29 2012 From: report at bugs.python.org (Eric Snow) Date: Wed, 25 Apr 2012 20:06:29 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335384389.01.0.360124059452.issue14605@psf.upfronthosting.co.za> Eric Snow added the comment: While not in the initial list, _find_module() would be really handy. Perhaps we could call it "get_loader" instead. "find_module" is a misleading name and I don't see any parallel with imp.find_module as something to aspire to. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 22:27:17 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 25 Apr 2012 20:27:17 +0000 Subject: [issue14059] Implement multiprocessing.Barrier In-Reply-To: <1329699138.74.0.937439869593.issue14059@psf.upfronthosting.co.za> Message-ID: <1335385637.17.0.622518358706.issue14059@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: The patch looks good. However, I've had two failures while testing it: - a BrokenBarrierError on test_default_timeout: I see you've already increased the timeout from the original threading code, but you can probably double it (we have some slow buildbots, and creating processes is expensive on Windows) - TestNumberOfObjects is failing too: """ test_number_of_objects (test.test_multiprocessing.WithManagerTestZZZNumberOfObjects) ... b6cb776c: refcount=1 b6d72dfc: refcount=2 b6cb776c: refcount=1 b6d72dfc: refcount=2 FAIL """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 22:34:17 2012 From: report at bugs.python.org (Daniel Urban) Date: Wed, 25 Apr 2012 20:34:17 +0000 Subject: [issue13266] Add inspect.unwrap(f) to easily unravel "__wrapped__" chains In-Reply-To: <1319611391.89.0.610441716125.issue13266@psf.upfronthosting.co.za> Message-ID: <1335386057.79.0.411727308134.issue13266@psf.upfronthosting.co.za> Daniel Urban added the comment: I've attached a patch implementing inspect.unwrap (+ some tests). ---------- keywords: +patch Added file: http://bugs.python.org/file25368/inspect_unwrap.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 22:52:40 2012 From: report at bugs.python.org (Brett Cannon) Date: Wed, 25 Apr 2012 20:52:40 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335387160.32.0.149880822131.issue14605@psf.upfronthosting.co.za> Brett Cannon added the comment: importlib.find_module() (or get_loader() as it would replace pkgutil.get_loader() as well) is definitely planned. So is importlib.util.resolve_name() (although maybe that is basic enough to want top-level?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 25 22:57:53 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 25 Apr 2012 20:57:53 +0000 Subject: [issue1522400] irda socket support Message-ID: <1335387473.17.0.408009831808.issue1522400@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Actually I think it suffers from the same problem as AF_UNIX: sockaddr_irda->sir_name, like sockaddr_un->sun_path, don't have to be NUL-terminated, and the kernel can return non NUL-terminated strings. Which means that such code: { /* regular NULL-terminated string */ return PyUnicode_DecodeFSDefault(a->sun_path); } or return Py_BuildValue("iO&", a->sir_addr, PyUnicode_DecodeFSDefault, a->sir_name); can overrung pas sun_path/sir_name, and potentially segfault. See http://bugs.python.org/issue8372. What's the simplest way to account for this? Is there a way to pass PyUnicode_DecodeFSDefault a max length (without having to make an intermediary copy or sir_name, appending a NUL at the end)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 00:48:28 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Apr 2012 22:48:28 +0000 Subject: [issue12632] Python 3 doesn't support cp65001 as the OEM code page In-Reply-To: <1311560689.64.0.570043905551.issue12632@psf.upfronthosting.co.za> Message-ID: <1335394108.8.0.944072275664.issue12632@psf.upfronthosting.co.za> STINNER Victor added the comment: > LookupError: unknown encoding: cp65001 The initial issue was solved by the issue #13216. For other issues with the Windows Console, see the issue #1602. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 00:50:49 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Apr 2012 22:50:49 +0000 Subject: [issue11574] TextIOWrapper: Unicode Fallback Encoding on Python 3.3 In-Reply-To: <1300296395.6.0.964785890032.issue11574@psf.upfronthosting.co.za> Message-ID: <1335394249.43.0.0534146454015.issue11574@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't think that using a fallback is a good idea. So I'm closing the issue. You can reopen the discussion on the python-dev mailing list if you don't agree with me or Martin. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 00:58:12 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Apr 2012 22:58:12 +0000 Subject: [issue8304] strftime and Unicode characters In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za> Message-ID: <1335394692.6.0.601489177081.issue8304@psf.upfronthosting.co.za> STINNER Victor added the comment: > Actually the bug seems related to Windows. See also the issue #10653: wcsftime() doesn't format correctly time zones, so Python 3 uses strftime() instead. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 00:59:44 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Apr 2012 22:59:44 +0000 Subject: [issue6815] UnicodeDecodeError in os.path.expandvars In-Reply-To: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za> Message-ID: <1335394784.4.0.45878761493.issue6815@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo versions: -Python 2.6, Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 01:00:30 2012 From: report at bugs.python.org (Brian Curtin) Date: Wed, 25 Apr 2012 23:00:30 +0000 Subject: [issue8304] strftime and Unicode characters In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za> Message-ID: <1335394830.82.0.828030975131.issue8304@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 01:01:47 2012 From: report at bugs.python.org (STINNER Victor) Date: Wed, 25 Apr 2012 23:01:47 +0000 Subject: [issue14670] subprocess.call with pipe character in argument In-Reply-To: <1335374516.95.0.470714396537.issue14670@psf.upfronthosting.co.za> Message-ID: <1335394907.69.0.786098601212.issue14670@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 01:34:30 2012 From: report at bugs.python.org (R. David Murray) Date: Wed, 25 Apr 2012 23:34:30 +0000 Subject: [issue14670] subprocess.call with pipe character in argument In-Reply-To: <1335374516.95.0.470714396537.issue14670@psf.upfronthosting.co.za> Message-ID: <1335396870.13.0.131581896862.issue14670@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, I thought I remembered seeing something about '|' in windows before, and I was right. It is only special to cmd.exe, which means it is only special when shell=True. See issue 1300 for a discussion. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 02:19:08 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 26 Apr 2012 00:19:08 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 8dab93ec19de by Brett Cannon in branch 'default': Issue #14605: Insert to the front of sys.path_hooks instead of appending. http://hg.python.org/cpython/rev/8dab93ec19de ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 02:20:29 2012 From: report at bugs.python.org (Roger Serwy) Date: Thu, 26 Apr 2012 00:20:29 +0000 Subject: [issue9150] IDLE should not save trailing whitespace after strip trailing whitespace has been used In-Reply-To: <1278179945.62.0.903425904075.issue9150@psf.upfronthosting.co.za> Message-ID: <1335399629.25.0.686450283597.issue9150@psf.upfronthosting.co.za> Roger Serwy added the comment: Closing this issue. Strip trailing whitespace works for me. ---------- resolution: -> works for me status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 02:26:31 2012 From: report at bugs.python.org (Roger Serwy) Date: Thu, 26 Apr 2012 00:26:31 +0000 Subject: [issue13078] IDLE: Python Crashes When Saving Or Opening In-Reply-To: <1317404515.12.0.258020695982.issue13078@psf.upfronthosting.co.za> Message-ID: <1335399991.86.0.529217010221.issue13078@psf.upfronthosting.co.za> Roger Serwy added the comment: Closing this issue due to lack of feedback. ---------- resolution: -> works for me status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 02:28:50 2012 From: report at bugs.python.org (Roger Serwy) Date: Thu, 26 Apr 2012 00:28:50 +0000 Subject: [issue6649] idlelib/rpc.py missing exit status on exithook In-Reply-To: <1249489269.49.0.307291234061.issue6649@psf.upfronthosting.co.za> Message-ID: <1335400130.72.0.427375528761.issue6649@psf.upfronthosting.co.za> Changes by Roger Serwy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 02:55:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 26 Apr 2012 00:55:26 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 57d558f1904d by Brett Cannon in branch 'default': Issue #14605: Make explicit the entries on sys.path_hooks that used to http://hg.python.org/cpython/rev/57d558f1904d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 02:58:39 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 26 Apr 2012 00:58:39 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335401919.89.0.417778143834.issue14605@psf.upfronthosting.co.za> Brett Cannon added the comment: Just to document why my explicit sys.path_hooks patch didn't quite change the meaning of None in sys.path_importer_cache, I found a bunch of places in the stdlib and in Modules/main.c where NullImporter is explicitly expected to be returned, so I wanted to get this initial patch in before I saw what would happen if None didn't change its meaning. I think I will try a patch to have None mean "no finder" instead of the current "retry sys.path_hooks" and see how that goes. The real trick is whether stopping the use of NullImporter will be easy or not. That will be what really decides if it stops being on sys.path_hooks by default. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 03:21:56 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 26 Apr 2012 01:21:56 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335403316.42.0.787945782986.issue14657@psf.upfronthosting.co.za> Nick Coghlan added the comment: My plan would be for the frozen version to be entirely implicit, and have only the subsequent import of the version from disk actually modify the public hooks. However, I realised today that my current patch would break "stdlib-from-zipfile" approaches, so any bootstrapping of importlib from disk would have to take place after zipimport was put in place. That suggests a few possible changes: - reordering import_init so zipimport is initialised before the bootstrapping step - possibly downgrading failure of the bootstrapping step to a warning rather than a fatal error (i.e. continuing with the frozen version if the source version can't be found) This may still all prove to be too complicated and fragile, but I'm not prepared to give up on it yet - having the interpreter pick up on _bootstrap.py changes for the main import system *without* needing to be rebuilt first seems worth a bit of additional complexity in the bootstrapping mechanism. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 03:38:16 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 26 Apr 2012 01:38:16 +0000 Subject: [issue13473] Add tests for files byte-compiled by distutils[2] In-Reply-To: <1322145911.61.0.528651769931.issue13473@psf.upfronthosting.co.za> Message-ID: <1335404296.96.0.734120398339.issue13473@psf.upfronthosting.co.za> Nick Coghlan added the comment: Your basic approach looks sensible to me. One trick I use in test_cmd_line_script to prevent recreation is to simply delete the source file. If the source is gone, implicit recreation is impossible. Unfortunately, that doesn't work for __pycache__, since the cached version will be ignored if the original goes missing. One useful explicit check (as per #14443) would be to ensure the magic number and other attributes are as expected: http://hg.python.org/cpython/file/57d558f1904d/Lib/importlib/_bootstrap.py#l444 You can also pass the "-B" flag to your testing subprocesses, which will switch off the implicit bytecode generation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 03:47:57 2012 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 26 Apr 2012 01:47:57 +0000 Subject: [issue14443] Distutils test_bdist_rpm failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <1335404877.93.0.39067750145.issue14443@psf.upfronthosting.co.za> Nick Coghlan added the comment: Antoine (added to nosy list) indicated he wasn't seeing the failure on a Mageia system, so that's another point in favour of a Fedora/RHEL specific problem. Also added Dave Malcolm as the Fedora Python package maintainer. Applying #11599 to get the full failing command line sounds worthwhile, but #11122 shouldn't be related, since the RHEL buildbot definitely has rpmbuild available. ---------- nosy: +dmalcolm, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 04:53:36 2012 From: report at bugs.python.org (Q) Date: Thu, 26 Apr 2012 02:53:36 +0000 Subject: [issue14671] isinstance(obj, object) returns True for _old style_ classes Message-ID: <1335408816.14.0.0332999907924.issue14671@psf.upfronthosting.co.za> New submission from Q : $python Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) [GCC 4.4.3] on linux2 >>> class Old: pass >>> class New(object): pass >>> o = Old() >>> n = New() >>> isinstance(o, object) True This is it, basically. Is it a bug or a feature? More tests : >>> isinstance(o, Old) True >>> isinstance(o, New) False >>> isinstance(n, Old) False >>> isinstance(o, int) False Please note that some unimportant output was deleted from above. PS. If this is a feature, how do I detect an old-style class then ? ---------- components: Interpreter Core messages: 159351 nosy: thread13 priority: normal severity: normal status: open title: isinstance(obj, object) returns True for _old style_ classes type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 04:55:10 2012 From: report at bugs.python.org (Q) Date: Thu, 26 Apr 2012 02:55:10 +0000 Subject: [issue14671] isinstance(obj, object) returns True for _old style_ class instances In-Reply-To: <1335408816.14.0.0332999907924.issue14671@psf.upfronthosting.co.za> Message-ID: <1335408910.14.0.153945315419.issue14671@psf.upfronthosting.co.za> Changes by Q : ---------- title: isinstance(obj, object) returns True for _old style_ classes -> isinstance(obj, object) returns True for _old style_ class instances _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 04:56:18 2012 From: report at bugs.python.org (Q) Date: Thu, 26 Apr 2012 02:56:18 +0000 Subject: [issue14671] isinstance(obj, object) returns True for _old style_ class instances In-Reply-To: <1335408816.14.0.0332999907924.issue14671@psf.upfronthosting.co.za> Message-ID: <1335408978.33.0.78767431408.issue14671@psf.upfronthosting.co.za> Q added the comment: In addition: >>> issubclass(Old, object) False ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 04:57:45 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 26 Apr 2012 02:57:45 +0000 Subject: [issue14671] isinstance(obj, object) returns True for _old style_ class instances In-Reply-To: <1335408816.14.0.0332999907924.issue14671@psf.upfronthosting.co.za> Message-ID: <1335409065.71.0.322359100278.issue14671@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Yes, everything is a object. issubclass, though, works differently for old-style and new-style classes. ---------- nosy: +benjamin.peterson resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 06:05:22 2012 From: report at bugs.python.org (Q) Date: Thu, 26 Apr 2012 04:05:22 +0000 Subject: [issue14671] isinstance(obj, object) returns True for _old style_ class instances In-Reply-To: <1335408816.14.0.0332999907924.issue14671@psf.upfronthosting.co.za> Message-ID: <1335413122.48.0.892727928586.issue14671@psf.upfronthosting.co.za> Q added the comment: >>> help(isinstance) isinstance(...) isinstance(object, class-or-type-or-tuple) -> bool Return whether an object is an instance of a class or of a subclass thereof. (...) So are the old-style class instances descendants of the object? I feel like I am missing something (except for the fact that you have closed the bug). ---------- resolution: invalid -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 06:20:12 2012 From: report at bugs.python.org (Jeff Dean) Date: Thu, 26 Apr 2012 04:20:12 +0000 Subject: [issue14672] Windows installer: add desktop shortcut(s) Message-ID: <1335414011.97.0.984037154974.issue14672@psf.upfronthosting.co.za> New submission from Jeff Dean : Spun off from Issue3561: I recently saw Brian Curtin's Pycon 2012 presentation. If a goal is to make it easy for new Windows users to run python, consider (optionally) installing a desktop shortcut. This would make it easy for new users to run python (easier than starting up a shell). This does not require the path to be modified. The installer could also (optionally) add a shortcut for starting up a command interpreter with the path modified (for just that shortcut), in case command line access is needed. This would not be necessary if the python being installed is added to the path. The first shortcut would be enabled by default, to help truly novice users. Other users could turn it off, or just delete the shortcut. ---------- components: Installation messages: 159355 nosy: jdigital priority: normal severity: normal status: open title: Windows installer: add desktop shortcut(s) type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 07:02:35 2012 From: report at bugs.python.org (Brian Curtin) Date: Thu, 26 Apr 2012 05:02:35 +0000 Subject: [issue14667] No IDLE In-Reply-To: <1335313762.17.0.753940415621.issue14667@psf.upfronthosting.co.za> Message-ID: <1335416555.9.0.950503401355.issue14667@psf.upfronthosting.co.za> Brian Curtin added the comment: James, since you attached a Windows executable I'll assume that's the platform you're on. Try the following: 1. Open the Start menu 2. Choose "All Programs" (or "Programs" on XP, I think) 3. Scroll to where you see "Python x.y", where you'll see one or more entries depending on how many versions you have installed. 4. Choose the version you want to open, e.g., Python 2.7 5. You should see "IDLE (Python GUI)" in the menu. Run it, that's IDLE. Is there an issue with any of those steps? ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 07:16:11 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 26 Apr 2012 05:16:11 +0000 Subject: [issue14673] add sys.implementation Message-ID: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> New submission from Eric Snow : (see thread at http://mail.python.org/pipermail/python-ideas/2012-April/014878.html) This is a patch to add sys.implementation to Python (with doc addition). The main motivation is to have an explicit place to look for the name and version of the implementation for generating the import cache tag (a la PEP 3147). ---------- components: Interpreter Core files: sys_implementation.diff keywords: patch messages: 159357 nosy: eric.snow priority: normal severity: normal status: open title: add sys.implementation type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file25369/sys_implementation.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 08:00:10 2012 From: report at bugs.python.org (Georg Brandl) Date: Thu, 26 Apr 2012 06:00:10 +0000 Subject: [issue14671] isinstance(obj, object) returns True for _old style_ class instances In-Reply-To: <1335408816.14.0.0332999907924.issue14671@psf.upfronthosting.co.za> Message-ID: <1335420010.9.0.418298693688.issue14671@psf.upfronthosting.co.za> Georg Brandl added the comment: This is a result of how old-style classes are implemented. If you look at type(Old()), you can see that it isn't Old, but "instance". (And "instance" is a subclass of object again.) "issubclass" for old-style classes doesn't check type(o) but o.__class__, which are different: the former is "instance" and the latter your class. That is one reason we removed old-style classes in Python 3... ---------- nosy: +georg.brandl resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 10:20:57 2012 From: report at bugs.python.org (Balthazar Rouberol) Date: Thu, 26 Apr 2012 08:20:57 +0000 Subject: [issue10976] json.loads() throws TypeError on bytes object In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za> Message-ID: <1335428457.49.0.702959754745.issue10976@psf.upfronthosting.co.za> Balthazar Rouberol added the comment: I know this does not fix anything at the core, but it would allow you to use json.loads() with python 3.2 (maybe 3.1?): Replace json.loads(raw_data) by raw_data = raw_data.decode('utf-8') # Or any other ISO format json.loads(raw_data) ---------- nosy: +Balthazar.Rouberol _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 10:34:32 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Apr 2012 08:34:32 +0000 Subject: [issue10976] json.loads() throws TypeError on bytes object In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za> Message-ID: <1335429272.37.0.0631322450766.issue10976@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > What if the returned JSON uses a charset other than utf-8 ? According to RFC 4627: "JSON text SHALL be encoded in Unicode. The default encoding is UTF-8." RFC 4627 also offers a way to autodetect other Unicode encodings. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 11:48:31 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 26 Apr 2012 09:48:31 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1335433711.14.0.14388377525.issue14127@psf.upfronthosting.co.za> Larry Hastings added the comment: Anybody else? I guess I'm gonna juuuust miss Alpha 3, but if nobody has any other objections I'll check this in today (Thursday). If you want me to hold off just let me know. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 13:36:26 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 26 Apr 2012 11:36:26 +0000 Subject: [issue14579] CVE-2012-2135: Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1335440186.13.0.485206103926.issue14579@psf.upfronthosting.co.za> STINNER Victor added the comment: I ran tests of utf16_error_handling-3.2_4.patch on Python 3.1. Two tests are failing: - b'\x00\xd8'.decode('utf-16le', 'replace')='\ufffd\ufffd' != '\ufffd' - b'\xd8\x00'.decode('utf-16be', 'replace')='\ufffd\ufffd' != '\ufffd' I don't think that the test is correct: UTF-16 should resynchronize as early as possible (ignore the first invalid byte and restart at the following byte), so '\ufffd\ufffd' is the correct answer. Another examples: - b'\xd8\x00\x41'.decode('utf-16be', 'replace') should return '?A' (\ufffdA') - with UTF-8 decoder: (b'\xC3' + '\xe9'.encode('utf-8')).decode('utf-8', 'replace') returns '\ufffd\xe9' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 13:49:25 2012 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 26 Apr 2012 11:49:25 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335440965.01.0.1800523441.issue13210@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 13:54:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 26 Apr 2012 11:54:13 +0000 Subject: [issue14579] CVE-2012-2135: Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1335440186.13.0.485206103926.issue14579@psf.upfronthosting.co.za> Message-ID: <1335441165.3421.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > I ran tests of utf16_error_handling-3.2_4.patch on Python 3.1. Two tests are failing: > - b'\x00\xd8'.decode('utf-16le', 'replace')='\ufffd\ufffd' != '\ufffd' > - b'\xd8\x00'.decode('utf-16be', 'replace')='\ufffd\ufffd' != '\ufffd' > > I don't think that the test is correct: UTF-16 should resynchronize as > early as possible (ignore the first invalid byte and restart at the > following byte), so '\ufffd\ufffd' is the correct answer. UTF-16 units are 16-bit words, not bytes, so '\uffffd' sounds correct to me. You resynchronize on the word boundary: the invalid word is skipped. > - with UTF-8 decoder: (b'\xC3' + > '\xe9'.encode('utf-8')).decode('utf-8', 'replace') returns '\ufffd > \xe9' That's because UTF-8 operates on bytes: the invalid byte is skipped. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 15:03:55 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 26 Apr 2012 13:03:55 +0000 Subject: [issue10976] json.loads() throws TypeError on bytes object In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za> Message-ID: <1335445435.92.0.984730977708.issue10976@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, adding support for bytes objects using the spec from RFC 4627 (or at least with utf-8 as a default) may be an enhancement for 3.3. ---------- assignee: docs at python -> components: +Library (Lib) -Documentation stage: -> needs patch type: behavior -> enhancement versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 15:06:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 26 Apr 2012 13:06:33 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1335445593.21.0.438019010785.issue14673@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If it can contain a variable number of fields, I think it should be a dict rather than a tuple. ---------- nosy: +ncoghlan, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 16:07:46 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Apr 2012 14:07:46 +0000 Subject: [issue10976] json.loads() throws TypeError on bytes object In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za> Message-ID: <1335449266.36.0.187593044345.issue10976@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Things are a little more complicated. '123' is not a valid JSON according to RFC 4627 (the top-level element can only be an object or an array). This means that the autodetection algorithm will not always work for such non-standard data. If we can parse binary data, then there must be a way to generate binary data in at least one of the Unicode encodings. By the way, the documentation should give a link to RFC 4627 and explain the current implementation is different from it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 16:15:12 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Apr 2012 14:15:12 +0000 Subject: [issue14674] Add link to RFC 4627 from json documentation Message-ID: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : The json module documentation should give a link to RFC 4627 and explain the current implementation is different from it. For example, according to RFC 4627 only an object or an array can be top-level JSON element. ---------- assignee: docs at python components: Documentation messages: 159367 nosy: docs at python, storchaka priority: normal severity: normal status: open title: Add link to RFC 4627 from json documentation type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 16:21:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 26 Apr 2012 14:21:40 +0000 Subject: [issue10976] json.loads() throws TypeError on bytes object In-Reply-To: <1335449266.36.0.187593044345.issue10976@psf.upfronthosting.co.za> Message-ID: <1335450012.3421.4.camel@localhost.localdomain> Antoine Pitrou added the comment: > Things are a little more complicated. '123' is not a valid JSON > according to RFC 4627 (the top-level element can only be an object or > an array). This means that the autodetection algorithm will not always > work for such non-standard data. The autodetection algorithm needn't examine all 4 first bytes. If the 2 first bytes are non-zero, you have UTF-8 data. Otherwise, the JSON text will be at least 4 bytes long (since it's either UTF-16 or UTF-32). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 16:37:45 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Thu, 26 Apr 2012 14:37:45 +0000 Subject: [issue14675] make distutils.ccompiler.CCompiler an abstract class Message-ID: <1335451065.7.0.113076491662.issue14675@psf.upfronthosting.co.za> New submission from Ramchandra Apte : Make distutils.ccompiler.CCompiler an abstract class by making it inherit from abc.ABCMeta. Thanks ---------- messages: 159369 nosy: ramchandra.apte priority: normal severity: normal status: open title: make distutils.ccompiler.CCompiler an abstract class _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 16:38:08 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Thu, 26 Apr 2012 14:38:08 +0000 Subject: [issue14675] make distutils.ccompiler.CCompiler an abstract class In-Reply-To: <1335451065.7.0.113076491662.issue14675@psf.upfronthosting.co.za> Message-ID: <1335451088.31.0.196027163701.issue14675@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- assignee: -> eric.araujo components: +Distutils nosy: +eric.araujo, tarek versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 16:39:48 2012 From: report at bugs.python.org (Roundup Robot) Date: Thu, 26 Apr 2012 14:39:48 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 86dc014cdd74 by Jesus Cea in branch 'default': Close #10142: Support for SEEK_HOLE/SEEK_DATA http://hg.python.org/cpython/rev/86dc014cdd74 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 16:48:51 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Thu, 26 Apr 2012 14:48:51 +0000 Subject: [issue14675] make distutils.ccompiler.CCompiler an abstract class In-Reply-To: <1335451065.7.0.113076491662.issue14675@psf.upfronthosting.co.za> Message-ID: <1335451731.7.0.150616142742.issue14675@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Sorry, distutils.ccompiler.CCompiler should have abc.ABCMeta as the metaclass. (for example like this) class CCompiler(metaclass = abc.ABCMeta): ... Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 16:48:52 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 26 Apr 2012 14:48:52 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1335451732.14.0.0648365141745.issue14673@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:04:12 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 26 Apr 2012 15:04:12 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1335452652.02.0.908022646633.issue10142@psf.upfronthosting.co.za> Benjamin Peterson added the comment: You broke test_io www.python.org/dev/buildbot/all/builders/x86 Gentoo Non-Debug 3.x/builds/2143/steps/test/logs/stdio ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:05:00 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 26 Apr 2012 15:05:00 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335452700.28.0.945936919182.issue13210@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > the errno codes (EAGAIN etc) are provided only as a compatibility for > posix apps that test "errno". On windows, we use the WSA return values > from the api functions and WsaGetLastError(). > ... > So, the proposed patch is not a change, it is merely reinforcing the > previous practice of prefering the native error codes over the 'errno' > emulation. Except that Microsoft's C library also uses some of the non-WSA versions. For instance read() (or _read()) is documented to set errno to EBADF or EINVAL on error. So EBADF and EINVAL are just as "native" as WSAEBADF and WSAEINVAL. It is also quite common for python's C code to do stuff like errno = EINVAL; PyErr_SetFromErrno(PyExc_OSError); errnomap in Objects/exceptions.c is used to convert some OSError exceptions to subclasses like PermissionError. It shouldn't be hard to use it to also convert WSAEINVAL to EINVAL etc. ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:08:50 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 26 Apr 2012 15:08:50 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1335452930.05.0.559818189282.issue10142@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Yes, backing out changeset. Never suppose anything... ---------- resolution: fixed -> stage: committed/rejected -> patch review status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:09:07 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 26 Apr 2012 15:09:07 +0000 Subject: [issue10976] json.loads() raises TypeError on bytes object In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za> Message-ID: <1335452947.16.0.804978493644.issue10976@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- title: json.loads() throws TypeError on bytes object -> json.loads() raises TypeError on bytes object _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:09:25 2012 From: report at bugs.python.org (Stefano Taschini) Date: Thu, 26 Apr 2012 15:09:25 +0000 Subject: [issue8767] Configure: Cannot disable unicode In-Reply-To: <1274286115.56.0.588868311562.issue8767@psf.upfronthosting.co.za> Message-ID: <1335452965.93.0.360119253721.issue8767@psf.upfronthosting.co.za> Changes by Stefano Taschini : ---------- nosy: +taschini _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:09:54 2012 From: report at bugs.python.org (Brian Curtin) Date: Thu, 26 Apr 2012 15:09:54 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335452994.54.0.0468053917833.issue13210@psf.upfronthosting.co.za> Brian Curtin added the comment: I recently added what you just mentioned in the vs2010port branch for WSA and non-WSA to work together. I still need to figure out some distutils/packaging failures, but the port is nearly ready*. * I've only focused on 32-bit debug builds, but updating the project files and whatnot for other configurations is easy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:10:39 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 26 Apr 2012 15:10:39 +0000 Subject: [issue14675] make distutils.ccompiler.CCompiler an abstract class In-Reply-To: <1335451065.7.0.113076491662.issue14675@psf.upfronthosting.co.za> Message-ID: <1335453039.15.0.349015746033.issue14675@psf.upfronthosting.co.za> ?ric Araujo added the comment: distutils is closed to improvements, it only gets bugfixes. distutils2/packaging can get new features. Can you tell more about the use case or motivation for this request? ---------- components: +Distutils2 -Distutils nosy: +alexis versions: +3rd party, Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:12:13 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 26 Apr 2012 15:12:13 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1335453133.42.0.432815670939.issue14673@psf.upfronthosting.co.za> ?ric Araujo added the comment: *version* is a version tuple, in the format of :data:`sys.version_info`, which represents the version of the Python implementation, **not** the version of the Python specification it implements. If that version number is specific to each VM, then I?m not sure we should mandate a specific format. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:19:48 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 26 Apr 2012 15:19:48 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335453588.69.0.993263820903.issue13210@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: > Except that Microsoft's C library also uses some of the non-WSA > versions. For instance read() (or _read()) is documented to set > errno to EBADF or EINVAL on error. So EBADF and EINVAL are just as > "native" as WSAEBADF and WSAEINVAL. read() is a posix function, so of course they set errno for it. You'll probably find that GetLastError() will some native error codes. > It is also quite common for python's C code to do stuff like > errno = EINVAL; > PyErr_SetFromErrno(PyExc_OSError); This doesn't change that, and as far as I know, this has worked and continues to work. "errno" is supported. > errnomap in Objects/exceptions.c is used to convert some OSError > exceptions to subclasses like PermissionError. It shouldn't be hard > to use it to also convert WSAEINVAL to EINVAL etc. Why would we get different errors codes for e.g. connection reset events because we build with a different compiler? Python has always used the native error codes for socket io on windows, why change that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:20:53 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 26 Apr 2012 15:20:53 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335453653.15.0.653656935392.issue13210@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Brian, I posted a suggested port five weeks ago. What kind of problems are you having? It's really a very straightforward thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:22:49 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 26 Apr 2012 15:22:49 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335453769.52.0.202993942175.issue13210@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Also, I'm not sure distutils and all that is really necessary. As I understood it, the goal is to make it so that the casual hacker can compile and run python using visual studio 2010. 3.3 continues to be "officially" distributed with 2008. Surely it is possible to do this in smaller steps, rather than one fell swoop? For instance, the sxs patch and the errnomodule patch could go in now without disturbing anything whatsoever. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:25:17 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 26 Apr 2012 15:25:17 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1335453917.71.0.650613541306.issue10142@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Added file: http://bugs.python.org/file25370/6447a9323b11.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:25:54 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 26 Apr 2012 15:25:54 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1335453954.29.0.51327760111.issue10142@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: New patch proposed, with testsuite fixed. Please, review. Last chance :-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:27:53 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 26 Apr 2012 15:27:53 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335308517.69.0.701803893151.issue14666@psf.upfronthosting.co.za> Message-ID: <1335454073.7.0.364247035505.issue14666@psf.upfronthosting.co.za> Richard Oudkerk added the comment: New patch which adds timeout to ResourceSharer.stop() which defaults to 0. When stop() fails it now uses the logger. pthread_sigmask() only stops this background thread from receiving signals. Signals will still be delivered to other threads, so it should not have any effect on the handling of Ctrl-C. ---------- Added file: http://bugs.python.org/file25371/mp_resource_sharer_stop.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:31:45 2012 From: report at bugs.python.org (Brian Curtin) Date: Thu, 26 Apr 2012 15:31:45 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335454305.26.0.0253117759675.issue13210@psf.upfronthosting.co.za> Brian Curtin added the comment: No, this is the real thing. Python 3.3 distributed on VS2010. In order to ship a fully built Python 3.3 MSI for users, I've found it's not just as easy as updating errno. I'll strip out all of the project file changes and whatnot and post a patch of the actual C and Python code changes to see that this is in line with what people think is usable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:32:35 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 26 Apr 2012 15:32:35 +0000 Subject: [issue14443] Distutils test_bdist_rpm failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <1335454355.31.0.467731270168.issue14443@psf.upfronthosting.co.za> Dave Malcolm added the comment: As a post-processing step, rpmbuild will attempt to byte-compile any .py files it encounters, and the results must be listed in the %files manifest. [1] This is done by the script brp-python-bytecompile, which uses the compileall module. However, my guess is that it's not using the correct version of python when invoking "compileall", which would explain why it's using the pre-PEP3147 location for the .pyc/.pyo files. Can you run "file" on the .pyc files and confirm which version of Python they're bytecode for? My guess is that it's bytecompiled them with /usr/bin/python, rather than your local build of python. Some notes: In older versions of RPM, brp-python-bytecompile took a single optional argument: the python interpreter to use, defaulting to /usr/bin/python. I generalized this to support multiple defaults when adding Python 3 support to Fedora: see https://bugzilla.redhat.com/show_bug.cgi?id=531117 That patch could be generalized to support /usr/local/lib. [1] In Fedora we do this using "__os_install_post", which is defined in /usr/lib/rpm/redhat/macros (from the redhat-rpm-config package), which has the invocation of /usr/lib/rpm/brp-python-bytecompile So it could be possible to override the python interpreter to use by redefining __os_install_post ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:32:57 2012 From: report at bugs.python.org (Brian Curtin) Date: Thu, 26 Apr 2012 15:32:57 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335454377.04.0.174278583596.issue13210@psf.upfronthosting.co.za> Brian Curtin added the comment: Also, I personally don't care about distutils, but I need all of the tests to pass before I can consider merging this. Distutils and packaging need a few changes to be able to compile extensions and create setups and whatever with VS2010. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:40:45 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 26 Apr 2012 15:40:45 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335454845.11.0.425343178265.issue13210@psf.upfronthosting.co.za> ?ric Araujo added the comment: Could you attach a file with the distutils/packaging test output? I don?t really know the packaging.compiler module, but I may be able to make sense of the error messages and work with you to fix them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:47:52 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 26 Apr 2012 15:47:52 +0000 Subject: [issue14632] Race condition in WatchedFileHandler leads to unhandled exception In-Reply-To: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za> Message-ID: <1335455272.92.0.986258379037.issue14632@psf.upfronthosting.co.za> Vinay Sajip added the comment: Buildbots seem not to be complaining, so closing. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 17:48:23 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Apr 2012 15:48:23 +0000 Subject: [issue10976] json.loads() raises TypeError on bytes object In-Reply-To: <1335450012.3421.4.camel@localhost.localdomain> Message-ID: <1335455452.2576.10.camel@raxxla> Serhiy Storchaka added the comment: I mean a string that starts with '\u0000'. b'"\x00...'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 18:03:22 2012 From: report at bugs.python.org (R. David Murray) Date: Thu, 26 Apr 2012 16:03:22 +0000 Subject: [issue8767] Configure: Cannot disable unicode In-Reply-To: <1274286115.56.0.588868311562.issue8767@psf.upfronthosting.co.za> Message-ID: <1335456202.29.0.938732339796.issue8767@psf.upfronthosting.co.za> R. David Murray added the comment: Reopening per this python-dev thread where MvL said that not being able to build 2.7 without unicode is a bug (but someone would need to care enough to contribute a patch to fix it). ---------- nosy: +r.david.murray priority: normal -> low stage: -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 18:07:52 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 26 Apr 2012 16:07:52 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1335456472.16.0.318855565733.issue14673@psf.upfronthosting.co.za> Eric Snow added the comment: @antoine - I wondered about that. In the end I got something up to start with. The list of fields in sys.implementation may change over time, unlike sys.version_info, et al. However, during interpreter execution, I would expect that neither that list nor the contents would change. The variability would only be between implementations and between versions of those implementations. A dict would imply to me that it might vary during interpreter execution. An immutable type makes it clear to me that it won't be changing. I'm fine with a dict, though, if you think that's better. Perhaps a dictproxy? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 18:12:45 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 26 Apr 2012 16:12:45 +0000 Subject: [issue10976] json.loads() raises TypeError on bytes object In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za> Message-ID: <1335456765.14.0.898384239606.issue10976@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Le jeudi 26 avril 2012 ? 15:48 +0000, Serhiy Storchaka a ?crit : > > I mean a string that starts with '\u0000'. b'"\x00...'. According to the RFC, that should be escaped: All Unicode characters may be placed within the quotation marks except for the characters that must be escaped: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F). And indeed: >>> json.loads('"\u0000"') Traceback (most recent call last): File "", line 1, in File "/home/antoine/opt/lib/python3.2/json/__init__.py", line 307, in loads return _default_decoder.decode(s) File "/home/antoine/opt/lib/python3.2/json/decoder.py", line 351, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/home/antoine/opt/lib/python3.2/json/decoder.py", line 367, in raw_decode obj, end = self.scan_once(s, idx) ValueError: Invalid control character at: line 1 column 1 (char 1) >>> json.loads('"\\u0000"') '\x00' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 18:14:47 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 26 Apr 2012 16:14:47 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335456887.03.0.767212733901.issue13210@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > This doesn't change that, and as far as I know, this has worked and > continues to work. "errno" is supported. Using your patch, does the following throw an AssertionError? >>> import os, errno >>> try: ... os.read(-1, 10) ... except OSError as e: ... assert e.errno == errno.EBADF ... >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 18:17:19 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 26 Apr 2012 16:17:19 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1335457039.98.0.559074629412.issue14673@psf.upfronthosting.co.za> Eric Snow added the comment: @?ric - that's a good point. I considered it for a little bit, but went with the quick and easy think to get it rolling. There is a real benefit to mandating an API sys.implementation.version. importlib would use that version to calculate the tag to use for cached modules. Without a specified/uniform data structure, that job is trickier. Having an explicit sys.implementation.cache_tag field would solve that, and the importlib code would check for that field first. However, I didn't want to start off with that as a "required" field, considering that only CPython would take advantage of module caches (as far as I know). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 18:19:06 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 26 Apr 2012 16:19:06 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1335457146.76.0.119518674393.issue14673@psf.upfronthosting.co.za> Eric Snow added the comment: I'm going to write a PEP for this, after all. I want to make sure that it's easy to access, in one place, these points that are coming up and their resolutions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 18:21:35 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 26 Apr 2012 16:21:35 +0000 Subject: [issue10976] json.loads() raises TypeError on bytes object In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za> Message-ID: <1335457295.36.0.339868654992.issue10976@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: According to current implementation this is acceptable. >>> json.loads('"\u0000"', strict=False) '\x00' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 18:26:09 2012 From: report at bugs.python.org (Dave Malcolm) Date: Thu, 26 Apr 2012 16:26:09 +0000 Subject: [issue14443] Distutils test_bdist_rpm failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <1335457569.36.0.416134845905.issue14443@psf.upfronthosting.co.za> Dave Malcolm added the comment: __os_install_post is defined within /usr/lib/rpm/redhat/macros and contains this fragment: /usr/lib/rpm/brp-python-bytecompile %{__python} %{?_python_bytecompile_errors_terminate_build} \ Hence it will use %{__python} as the default when byte-compiling. %__python has the default definition of /usr/bin/python, but this can be overridden, either in the spec file using: %global __python some_path_to_the_python_to_use or in the command-line invocation of rpmbuild: rpmbuild --define="__python some_path_to_the_python_to_use" You can use the --showrc option to rpmbuild to see all of the macro expansions it's using (lots of output). So if it is indeed using the wrong python executable to do the bytecompiling, the above ought to fix it. The simplest fix would probably be for bdist_rpm to add: --define="__python %s" % sys.executable to the rpmbuild invocation, I think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 18:45:52 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 26 Apr 2012 16:45:52 +0000 Subject: [issue14669] test_multiprocessing failure on OS X Tiger In-Reply-To: <1335370611.47.0.977907847024.issue14669@psf.upfronthosting.co.za> Message-ID: <1335458752.05.0.876421617301.issue14669@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I can't work out what is wrong here. The code does not to account for a partial read of the message from the socket. The attached patch fixes that, but it does not address the cause of this failure. ---------- keywords: +patch Added file: http://bugs.python.org/file25372/partial_message.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 18:49:12 2012 From: report at bugs.python.org (Peter Eisentraut) Date: Thu, 26 Apr 2012 16:49:12 +0000 Subject: [issue14676] DeprecationWarning missing in default warning filters documentation Message-ID: <1335458952.26.0.88746757742.issue14676@psf.upfronthosting.co.za> New submission from Peter Eisentraut : DeprecationWarning was disabled by default in Python 2.7, but the documentation section "Default Warning Filters" does not list it as ignored. In the 3.x branches, this was already fixed. Trivial patch attached. ---------- assignee: docs at python components: Documentation files: py27-default-warning-filters-doc.patch keywords: patch messages: 159398 nosy: docs at python, petere priority: normal severity: normal status: open title: DeprecationWarning missing in default warning filters documentation versions: Python 2.7 Added file: http://bugs.python.org/file25373/py27-default-warning-filters-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 18:54:23 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 26 Apr 2012 16:54:23 +0000 Subject: [issue1065986] Fix pydoc crashing on unicode strings Message-ID: <1335459263.67.0.617318906925.issue1065986@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 18:58:17 2012 From: report at bugs.python.org (Daniel Swanson) Date: Thu, 26 Apr 2012 16:58:17 +0000 Subject: [issue14672] Windows installer: add desktop shortcut(s) In-Reply-To: <1335414011.97.0.984037154974.issue14672@psf.upfronthosting.co.za> Message-ID: <1335459497.47.0.509565836666.issue14672@psf.upfronthosting.co.za> Daniel Swanson added the comment: I am using windows and as I recall, it installed a desktop shortcut for me. but I could be wrong. ---------- nosy: +weirdink13 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 19:28:54 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 26 Apr 2012 17:28:54 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335461334.7.0.774513312202.issue13210@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: > Using your patch, does the following throw an AssertionError? Yes, it looks as though it will. It seems I was too agressive, since errnomodule has different entries for EBADF and WSAEBADF. This is the kind of feedback I'd like to have had earlier. It means that there are some cases were we want to keep the winsock error codes there separately from the others. Annoying as that may be. Brian, do I understand you correctly that 2010 is to the official compiler for 3.3? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 19:30:14 2012 From: report at bugs.python.org (Brian Curtin) Date: Thu, 26 Apr 2012 17:30:14 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335461414.23.0.961825147236.issue13210@psf.upfronthosting.co.za> Brian Curtin added the comment: Yes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 19:34:36 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 26 Apr 2012 17:34:36 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335461676.83.0.962830042068.issue13210@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Super, I must have missed that memo. At PyCon there wasn't much enthusiasm for it, and this was considered a toy project :) You may be interested in my patch to see what I did with the project files, then. Otherwise, I'll be happy to review yours. In particular, I removed a bunch of redundant settings, and fixed the .props files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 19:37:43 2012 From: report at bugs.python.org (mesheb82) Date: Thu, 26 Apr 2012 17:37:43 +0000 Subject: [issue14677] Python 2.6 Printing Error Message-ID: <1335461863.83.0.292616015938.issue14677@psf.upfronthosting.co.za> New submission from mesheb82 : I?m running: Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on win32 I was testing out some print functionality and I made an error in typing (I meant to use %8.8f), but is this behavior intentional or is it an error? >> print '%8.8s' %(10000000001.) >> '10000000' I would expect this to return a TypeError. I also tested this on Python 2.4 and Python 2.5 on linux and had the same behavior. Steve ---------- components: IO messages: 159403 nosy: mesheb82 priority: normal severity: normal status: open title: Python 2.6 Printing Error versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 19:41:50 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 26 Apr 2012 17:41:50 +0000 Subject: [issue14678] Update zipimport to support importlib.invalidate_caches() Message-ID: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za> New submission from Brett Cannon : zipimport's finders that get cached in sys.path_importer_cache should probably be updated to support importlib.invalidate_caches() (else the module should get re-implemented in pure Python in importlib and then be tossed). ---------- components: Library (Lib) messages: 159404 nosy: brett.cannon priority: normal severity: normal status: open title: Update zipimport to support importlib.invalidate_caches() type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 19:42:20 2012 From: report at bugs.python.org (Fabian Groffen) Date: Thu, 26 Apr 2012 17:42:20 +0000 Subject: [issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails) In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335462140.55.0.00046856192817.issue14662@psf.upfronthosting.co.za> Fabian Groffen added the comment: % echo "test" > /var/tmp/testfile % python Python 2.7.3 (default, Apr 26 2012, 19:06:37) [GCC 4.2.1 (Gentoo 4.2.1_p5666, Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import shutil >>> shutil.move("/var/tmp/testfile", "./testfile"); Traceback (most recent call last): File "", line 1, in File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 299, in move copy2(src, real_dst) File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 129, in copy2 copystat(src, dst) File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 103, in copystat os.chflags(dst, st.st_flags) OSError: [Errno 45] Operation not supported: './testfile' >>> % vi /Library/Gentoo/usr/lib/python2.7/shutil.py % python Python 2.7.3 (default, Apr 26 2012, 19:06:37) [GCC 4.2.1 (Gentoo 4.2.1_p5666, Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import shutil >>> shutil.move("/var/tmp/testfile", "./testfile"); 45 Traceback (most recent call last): File "", line 1, in File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 300, in move copy2(src, real_dst) File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 130, in copy2 copystat(src, dst) File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 103, in copystat os.chflags(dst, st.st_flags) OSError: [Errno 45] Operation not supported: './testfile' >>> % grep 45 /usr/include/sys/errno.h #define ENOTSUP 45 /* Operation not supported */ I tried with a FAT16 formatted USB-disk, but there it doesn't fail, so I did some further digging. MS-DOS FS (under OSX) just seems to support setting flags (I tried with stat.UF_HIDDEN, Finder no longer displays the file). NFS, however, does NOT support any chflags call. % python Python 2.7.3 (default, Apr 26 2012, 19:06:37) [GCC 4.2.1 (Gentoo 4.2.1_p5666, Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import errno >>> print hasattr(errno, 'EOPNOTSUPP') True >>> print errno.EOPNOTSUPP 102 >>> 102 obviously != 45 % grep 102 /usr/include/sys/errno.h #define EOPNOTSUPP 102 /* Operation not supported on socket */ I believe Python got it mixed up here, we're looking for ENOTSUP, but that one doesn't exist, at least not here. >>> print hasattr(errno, 'ENOTSUP') False ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 19:48:47 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 26 Apr 2012 17:48:47 +0000 Subject: [issue14678] Update zipimport to support importlib.invalidate_caches() In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za> Message-ID: <1335462527.65.0.509552797457.issue14678@psf.upfronthosting.co.za> ?ric Araujo added the comment: zipimport in Python sounds good to me. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 19:51:17 2012 From: report at bugs.python.org (Fabian Groffen) Date: Thu, 26 Apr 2012 17:51:17 +0000 Subject: [issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails) In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335462677.04.0.18949419429.issue14662@psf.upfronthosting.co.za> Fabian Groffen added the comment: it seems errnomodule.c has no idea of ENOTSUP, and that's not the only missing one. OSX 10.7: $ grep "^#define\sE" /usr/include/sys/errno.h | awk '{print $2}' | while read line ; do grep -q ${line} Modules/errnomodule.c || echo "missing: $line" ; done missing: ENOTSUP missing: EBADRPC missing: ERPCMISMATCH missing: EPROGUNAVAIL missing: EPROGMISMATCH missing: EPROCUNAVAIL missing: EFTYPE missing: EAUTH missing: ENEEDAUTH missing: EPWROFF missing: EDEVERR missing: EBADEXEC missing: EBADARCH missing: ESHLIBVERS missing: EBADMACHO missing: ECANCELED missing: ENOATTR missing: ENOPOLICY missing: ENOTRECOVERABLE missing: EOWNERDEAD missing: ELAST Solaris 10: $ grep "^#define\sE" /usr/include/sys/errno.h | awk '{print $2}' | while read line ; do grep -q ${line} Modules/errnomodule.c || echo "missing: $line" ; done missing: ECANCELED missing: ENOTSUP missing: EOWNERDEAD missing: ENOTRECOVERABLE missing: ELOCKUNMAPPED missing: ENOTACTIVE ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 19:56:43 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 26 Apr 2012 17:56:43 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1335463003.24.0.394669881893.issue10142@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : Added file: http://bugs.python.org/file25374/c7abfb4d4260.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 19:57:16 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Thu, 26 Apr 2012 17:57:16 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1335463036.0.0.5069955203.issue10142@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: New patch, after neologix at free.fr review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 20:01:40 2012 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 26 Apr 2012 18:01:40 +0000 Subject: [issue14677] Python 2.6 Printing Error In-Reply-To: <1335461863.83.0.292616015938.issue14677@psf.upfronthosting.co.za> Message-ID: <1335463300.25.0.610264117086.issue14677@psf.upfronthosting.co.za> Eric V. Smith added the comment: The "s" causes the argument to be converted to a string, then the formatting is applied. So it's working as designed. This is the logical equivalent of: '%8.8s' % str(10000000001.) ---------- nosy: +eric.smith resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 20:02:33 2012 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 26 Apr 2012 18:02:33 +0000 Subject: [issue14678] Update zipimport to support importlib.invalidate_caches() In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za> Message-ID: <1335463353.37.0.339829700976.issue14678@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 20:40:14 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 26 Apr 2012 18:40:14 +0000 Subject: [issue14127] add st_*time_ns fileds to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1331834002.25.0.356049500332.issue14127@psf.upfronthosting.co.za> Message-ID: <4F99968C.5050503@v.loewis.de> Martin v. L?wis added the comment: > Somehow patch #2 doesn't show up in Rietveld. :-( It's because it's a git-style diff, so it includes no base revision, and it didn't apply cleanly to the default head (which is tried as a fall-back in case of a missing base revision). ---------- title: add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds -> add st_*time_ns fileds to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 20:46:14 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 26 Apr 2012 18:46:14 +0000 Subject: [issue14579] CVE-2012-2135: Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1335441165.3421.1.camel@localhost.localdomain> Message-ID: <4F9997F4.2090409@v.loewis.de> Martin v. L?wis added the comment: > UTF-16 units are 16-bit words, not bytes, so '\uffffd' sounds correct to > me. You resynchronize on the word boundary: the invalid word is skipped. I agree. The only odd case is when the number of bytes is not even (pun intended). In that case, anybody can guess which of the bytes is extra. The most natural (IMO) assumption is that the data is truncated, so it would be the last byte which is extra. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 20:56:28 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 26 Apr 2012 18:56:28 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1335453769.52.0.202993942175.issue13210@psf.upfronthosting.co.za> Message-ID: <4F999A5A.1060000@v.loewis.de> Martin v. L?wis added the comment: > For instance, the sxs patch and the errnomodule patch could go in now > without disturbing anything whatsoever. I'm not convinced that the errno change is actually correct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 20:58:05 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 26 Apr 2012 18:58:05 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1335461334.7.0.774513312202.issue13210@psf.upfronthosting.co.za> Message-ID: <4F999ABC.1010506@v.loewis.de> Martin v. L?wis added the comment: > Brian, do I understand you correctly that 2010 is to the official compiler for 3.3? Unless we switch to VS 2012, yes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 20:59:02 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 26 Apr 2012 18:59:02 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1335466742.78.0.327873281671.issue14127@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- title: add st_*time_ns fileds to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds -> add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 21:00:19 2012 From: report at bugs.python.org (Brian Curtin) Date: Thu, 26 Apr 2012 19:00:19 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335466819.53.0.239118886137.issue13210@psf.upfronthosting.co.za> Brian Curtin added the comment: I don't have a link handy, but from what I've read we could go from VS2010 to VS2012 with relative ease since it's supposed to be able to work with 2010 solutions/project files. I haven't tried this with the beta, but I'll take a look. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 21:11:38 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 26 Apr 2012 19:11:38 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1335467498.06.0.15037041853.issue14673@psf.upfronthosting.co.za> Martin v. L?wis added the comment: If the main motivation for this is that importlib can use it, I fail to see the point to make it cross-implementation. Other implementations of Python may not use byte code files at all, or use different byte code syntaxes, or not use the marshal module to load byte code. So the part of importlib that deals with cached .pyc files will be specific to CPython, anyway - why make it a cross-implementation attribute? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 21:30:10 2012 From: report at bugs.python.org (Larry Hastings) Date: Thu, 26 Apr 2012 19:30:10 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1335468610.22.0.275871784753.issue14127@psf.upfronthosting.co.za> Larry Hastings added the comment: FYI, Martin was replying to Guido's comment from more than a month ago, when I posted revision #2 of my first patch series. By sheer coincidence I posted revision #2 of a new patch series yesterday. But Reitveld worked fine for that! Anyway--no comments? Normally I find the patch review process akin to getting pecked to death by ducks. It's hard to believe this one might go in after only one revision. Somebody pinch me! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 21:34:54 2012 From: report at bugs.python.org (Ned Deily) Date: Thu, 26 Apr 2012 19:34:54 +0000 Subject: [issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails) In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335468894.8.0.656486123381.issue14662@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the analysis. Yes, it looks like there's a difference between OS X and current FreeBSDs, for example. chflags(2) on the latter is documented as returning EOPNOTSUPP and on the former ENOTSUP. shutil should check for both. A quick search of the source tree did not find any other users of chflags in the standard library. As far as adding other missing errnos, that could be handled as a separate issue as it more of an enhancement. Anyone interested in contributing a patch for either or both? https://developer.apple.com/library/mac/#documentation/darwin/reference/manpages/man2/chflags.2.html http://www.freebsd.org/cgi/man.cgi?query=chflags&apropos=0&sektion=2&manpath=FreeBSD+9.0-RELEASE&arch=default&format=html ---------- nosy: +ned.deily stage: -> needs patch versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 21:44:56 2012 From: report at bugs.python.org (Yuval Greenfield) Date: Thu, 26 Apr 2012 19:44:56 +0000 Subject: [issue6818] remove/delete method for zipfile/tarfile objects In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za> Message-ID: <1335469496.57.0.897251716243.issue6818@psf.upfronthosting.co.za> Yuval Greenfield added the comment: I'm not sure I understand how http://bugs.python.org/review/6818/show works. I've looked all over and only found remarks for "zipfile.remove.patch" and not for "zipfile.remove.2.patch" which addressed all the aforementioned issues. Also, I don't understand how to add myself to the CC of this issue's review page. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 21:46:44 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 26 Apr 2012 19:46:44 +0000 Subject: [issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails) In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335469604.53.0.885659252315.issue14662@psf.upfronthosting.co.za> Hynek Schlawack added the comment: I had this text ready before ned chimed in, I?ll post it anyway because it was a lot of work ;): You're right, 2.7?s errnos are incomplete compared to 3.2. Antoine added ENOTSUP in c370866f30a7 and it runs as ?Solaris-specific?. So it?s currently in 3.2 and later. Shouldn?t hurt to back port it? EOPNOTSUP is obviously wrong in your case and it doesn?t really sound right at all by the description. However, maybe on some other architecture (FreeBSD?) it?s the way to go? The commit (2e0d58adadbe) states it?s because of ZFS on OS X. As the code is unchanged in 3.2+, this bug also applies to them. Suggestion: For 3.2+3.3: I?d extend the catch to also catch ENOTSUP For 2.7: I?d also backport the err code. NB I?m fine if Fabian wants to do it himself, it?s his issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 21:51:13 2012 From: report at bugs.python.org (Brian Curtin) Date: Thu, 26 Apr 2012 19:51:13 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335469873.0.0.478541998345.issue13210@psf.upfronthosting.co.za> Brian Curtin added the comment: VS11 opened the VS2010 project fine without doing conversion. Note that this just uses VS11 to work with the project in VS2010 mode with the 2010 compiler. Doing the conversion to VS11's compiler is another thing to consider, although probably not until it goes RTM. I just ran the conversion from VS2010 to VS11 and it just sets "PlatformToolset" to "v110" in all vcxproj files. It didn't compile cleanly, having 25 projects succeed and 4 fail, but it was more than enough to get python_d.exe to run. A few tests failed, but they're the same as the failures on VS2010, so we're not far off from VS11 easily working. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 22:06:13 2012 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 26 Apr 2012 20:06:13 +0000 Subject: [issue14679] Changes to html.parser break third-party code Message-ID: <1335470773.41.0.349037543033.issue14679@psf.upfronthosting.co.za> New submission from Vinay Sajip : The change to html.parser.tagfind in ba4baaddac8d is causing third-party code (Django) to fail. See http://mail.python.org/pipermail/python-dev/2012-April/119074.html for more information. Other patterns which changed (e.g. attrfind_tolerant) might also lead to problems. As suggested in the python-dev thread, private versions of these patterns should be used and the existing public ones deprecated, where appropriate. ---------- keywords: 3.2regression messages: 159421 nosy: ezio.melotti, vinay.sajip priority: normal severity: normal status: open title: Changes to html.parser break third-party code type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 22:11:42 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 26 Apr 2012 20:11:42 +0000 Subject: [issue14679] Changes to html.parser break third-party code In-Reply-To: <1335470773.41.0.349037543033.issue14679@psf.upfronthosting.co.za> Message-ID: <1335471102.78.0.347036157398.issue14679@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 22:22:14 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 26 Apr 2012 20:22:14 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335471734.15.0.171517566246.issue13210@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: -haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 22:25:14 2012 From: report at bugs.python.org (Fabian Groffen) Date: Thu, 26 Apr 2012 20:25:14 +0000 Subject: [issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails) In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335471914.17.0.97505041649.issue14662@psf.upfronthosting.co.za> Fabian Groffen added the comment: I don't want to go through the paperwork nonsense just for a trivial patch, hence I didn't supply one, but instead provided all the information for you guys to make the correct fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 22:32:16 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 26 Apr 2012 20:32:16 +0000 Subject: [issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails) In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335472336.99.0.517398078716.issue14662@psf.upfronthosting.co.za> ?ric Araujo added the comment: Trivial patches don?t require paperwork; non-trivial patches require a simple contributor agreement (print, sign, scan, email). We don?t like that either but it is required. If you have any suggestion to make the process simpler, please share them on python-dev. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 23:07:04 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 26 Apr 2012 21:07:04 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335474424.29.0.485157327611.issue13210@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: MVL wrote: > I'm not convinced that the errno change is actually correct. You are right, as SBT pointed out. There are cases where we have had errno.EFOO and errno.WSAEFOO point to different values, because one was used by sockets and other by regular stuff. My patch was too heavy handed and nerfed at least EBADF. Perhaps others. (Getting a concrete example from SBT was helpful, btw) For socket-specific errors, it is an easy choice, however, but for socket error codes that also have to do with file IO it is less clear and probably full of special cases. This is nothing new, however. For writing portable socket code that needs to deal with the EBADF code, you would have to check for WSAEBADF on windows and EBADF on linux. Probably both to be portable. Since my patch was aimed at making 3.3. merely compilable for VS2010 I wanted to maintain the same value semantics as were it compiled for 2008. If we are changing the compiler version however, we might just as well take the plunge and translate the windows codes where they have corresponding posix codes. I'm eager to see Brian's patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 23:08:11 2012 From: report at bugs.python.org (Eric Snow) Date: Thu, 26 Apr 2012 21:08:11 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1335474491.17.0.434640684755.issue14673@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks for bringing this up, Martin. sys.implementation is about having an implementation-specific location (hence sys) to consolidate explicit values concerning the implementation. It's partly about clarifying the run-time distinction between Python-the-language and Python-the-implementation. 'name' and 'version' are the initial fields in sys.implementation because they are the most obvious choices, and a good starting point. If sys.implementation were available now we'd use it in importlib. That's what has motivated me to pursue this. You are correct that we can hard-code "cpython" in the bootstrap code to generate the cache tag. And perhaps that would be a better use of time. We can't just use platform.python_implementation(), however, since the frozen importlib can only use builtin modules. I expect you're right that some of the importlib code (particularly w.r.t. cached modules) is CPython-specific. However, I'm sure Brett has tried to minimize that subset of the module. Maybe he knows if the other implementations have plans for using importlib or how it affects them. If not, I'll ask around. Regardless, importlib is not the only motivator here. Right now platform.python_implementation() has to guess the implementation name. Having the different implementations specify the name explicitly in the sys module would be an improvement without a lot of work. Nick Coghlan has indicated that it would be useful for the test suite. Ultimately, sys.implementation would become the source for information about a specific Python implementation. Others could expound the point better, but as time goes by this will be more important. This current effort would get the ball rolling. Consequent to the concerns so far, I'll try to get a PEP out in the next couple days. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 23:09:40 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 26 Apr 2012 21:09:40 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335474580.98.0.938960102082.issue13210@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: [the Soney PS3 sdk also has weird error codes for its otherwise posix compatible api. I did write a translation layer to convert those codes into posix codes where appropriate. I could show you what I did, but I'd proably set me up to be lynched by Soney's lawyers.] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 26 23:11:21 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 26 Apr 2012 21:11:21 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1335474681.69.0.281324765959.issue11618@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: So, what do you think, should this go in? Any qualms about the thread_nt_cv.h header? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 00:11:12 2012 From: report at bugs.python.org (Gregor) Date: Thu, 26 Apr 2012 22:11:12 +0000 Subject: [issue14680] pydoc with -w option does not work for a lot of help topics Message-ID: <1335478272.08.0.215124599111.issue14680@psf.upfronthosting.co.za> New submission from Gregor : pydoc with pydoc with -w option (to write html files) does not work for a lot of help topics (e.g. EXPRESSIONS, FORMATTING, TUPLELITERALS, def, if, else...) If you look at the source you can see that when using the switch '-w' (http://hg.python.org/cpython/file/2.7/Lib/pydoc.py#l2311) pydoc uses the function writedoc, otherwise to the class Helper (http://hg.python.org/cpython/file/2.7/Lib/pydoc.py#l2325). In the Helper-class EXPRESSIONS is defined under line 1666 (http://hg.python.org/cpython/file/2.7/Lib/pydoc.py#l1666). The function writedoc does not utilize this nor does it use the Helper class. For dicussion see: http://stackoverflow.com/a/10333615/1318686 Example: pydoc EXPRESSIONS works perfectly fine but pydoc -w EXPRESSIONS does not. ---------- assignee: docs at python components: Documentation messages: 159428 nosy: docs at python, gregor.hoch priority: normal severity: normal status: open title: pydoc with -w option does not work for a lot of help topics versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 00:11:16 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 26 Apr 2012 22:11:16 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1335474681.69.0.281324765959.issue11618@psf.upfronthosting.co.za> Message-ID: <1335478187.3757.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > So, what do you think, should this go in? Any qualms about the thread_nt_cv.h header? On the principle it's ok, but I'd like to do a review before it goes in :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 00:47:55 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 26 Apr 2012 22:47:55 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1335480475.52.0.31791912635.issue14621@psf.upfronthosting.co.za> STINNER Victor added the comment: > One possible fix: ... > Main loop looks like this: .. Well, it was decided to not impact performances to workaround one specific class of attack, whereas there are many other ways to DoS Python. So we chose to keep the main loop unchanged. Randomizing the hash is not a fix for the hash DoS, it only makes the attacker harder. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 00:58:24 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 26 Apr 2012 22:58:24 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1335481104.38.0.777114539824.issue14621@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25282/hash.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 00:58:43 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 26 Apr 2012 22:58:43 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1335481123.33.0.898673340989.issue14621@psf.upfronthosting.co.za> STINNER Victor added the comment: Oops, I attached the wrong "hash.py" file. ---------- Added file: http://bugs.python.org/file25375/hash.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 00:59:24 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 26 Apr 2012 22:59:24 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1335481164.14.0.189505567833.issue11618@psf.upfronthosting.co.za> Martin v. L?wis added the comment: -1. Choice of operating system must be a run-time decision, not a compile-time decision. We will have to support XP for quite some time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 01:08:56 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 26 Apr 2012 23:08:56 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1335481736.2.0.8560263088.issue14621@psf.upfronthosting.co.za> Benjamin Peterson added the comment: We should see if more security can be gained without sacrificing speed. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 01:10:43 2012 From: report at bugs.python.org (STINNER Victor) Date: Thu, 26 Apr 2012 23:10:43 +0000 Subject: [issue14621] Hash function is not randomized properly In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za> Message-ID: <1335481843.82.0.00366765367596.issue14621@psf.upfronthosting.co.za> STINNER Victor added the comment: > Problem with current randomization of hash function > is following: Suffix does not influence whether two keys > have some hash or not (it is xor-ed after everything). Yes, the suffix is used to "protect" the secret. Without the suffix, it would be too simple to compute the prefix: getting a single hash value of a known string would leak the prefix. > Suffix does not influence whether two keys have some hash > or not (...). Everything except last 8 bits in prefix does > not influence it also. I don't know if we can do better and/or if it is a critical issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 01:52:01 2012 From: report at bugs.python.org (Brett Cannon) Date: Thu, 26 Apr 2012 23:52:01 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1335484321.9.0.895610443199.issue14673@psf.upfronthosting.co.za> Brett Cannon added the comment: So I'm w/ Antoine that a dict would be better so that the other VMs can add whatever they want into that object (e.g. Jython could specify what JVM they are running against) without causing confusion as to what some index means to each VM. The mutability of it is not important IMO. As for the other implementations using importlib, they all plan to with (hopefully) no direct modification, but whether they support bytecode I don't know (I think Jython has talked about it, but who knows). And pertaining to whether this is useful outside of importlib, I suspect it is. We already have 'jython' as an "OS" type to work around some differences. Adding this attribute would more clearly delineate when another VM is being used that might require working around some difference without overloading os.name (e.g. PyPy implementing something differently in their 1.7 release of Python 2.7 but is subsequently fixed in their 1.8 release). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 02:50:35 2012 From: report at bugs.python.org (Raphael Cruzeiro) Date: Fri, 27 Apr 2012 00:50:35 +0000 Subject: [issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu In-Reply-To: <1334734810.54.0.87567518387.issue14610@psf.upfronthosting.co.za> Message-ID: <1335487835.45.0.404451944915.issue14610@psf.upfronthosting.co.za> Raphael Cruzeiro added the comment: Yes, this code is hanging in my system. I'm posting the strace output. If there's any other information that may be helpful I'll happily provide it. ---------- Added file: http://bugs.python.org/file25376/pthread_strace.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 03:13:59 2012 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 27 Apr 2012 01:13:59 +0000 Subject: [issue14443] Distutils test_bdist_rpm failure In-Reply-To: <1333038958.38.0.586954097171.issue14443@psf.upfronthosting.co.za> Message-ID: <1335489239.28.0.529244633033.issue14443@psf.upfronthosting.co.za> Nick Coghlan added the comment: I tried the simple fix a couple of different ways on the RHEL6 buildbot. First by changing line 315 of Lib/distutils/command/bdist_rpm.py" to be: rpm_cmd = ['rpmbuild', '--define', '__python %s' % sys.executable] And then a second time by adding the new "--define" after the "-ba" option. (changing the spawn command to show the full command on error indicating the new arguments *were* being passed in, though) Neither worked - I still got the same error. Since I'm seeing the same fault on my Fedora system, I'll start poking around there instead (not sure when I'll get to it though). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 04:58:46 2012 From: report at bugs.python.org (Q) Date: Fri, 27 Apr 2012 02:58:46 +0000 Subject: [issue14671] isinstance(obj, object) returns True for _old style_ class instances In-Reply-To: <1335408816.14.0.0332999907924.issue14671@psf.upfronthosting.co.za> Message-ID: <1335495526.15.0.298160882509.issue14671@psf.upfronthosting.co.za> Q added the comment: I do not mean to reopen the bug (there are supposedly much more important things to work on in Python). But just for the record, let me state that I feel like there is some misleading inconsistency here: - by definition, a new style class is "Any class which inherits from object" ( see http://docs.python.org/glossary.html#term-new-style-class ) ; - to support this statement, new classes are indeed explicitly defined in the form "NewClass(object)" ; - now isinstance(), that is supposed to "return whether an object is an instance of a class or of a subclass thereof" (see help(isinstance)), returns True for old-style objects. It also seems reasonable if the descendants of a class will inherit its powers, which -- in the case of the old-style classes -- they obviously don't. Furthermore, I personally see no /point/ in returning True for isinstance(Old(), object): as it is quite misleading, one could easily have made it returning e.g. None as well. As I completely accept the fact it's a feature -- ( may be slightly confusing, and probably also useless -- but ... hey, nobody's perfect ) -- should I take then calling issubclass(obj.__class__, object) to be the official way to distinguish between the new-style and the old-style classes? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 06:13:08 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 27 Apr 2012 04:13:08 +0000 Subject: [issue14671] isinstance(obj, object) returns True for _old style_ class instances In-Reply-To: <1335495526.15.0.298160882509.issue14671@psf.upfronthosting.co.za> Message-ID: Benjamin Peterson added the comment: 2012/4/26 Q : > issubclass(obj.__class__, object) > > to be the official way to distinguish between the new-style and the old-style classes? Just do type(cls) is types.ClassType. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 08:25:20 2012 From: report at bugs.python.org (Georg Brandl) Date: Fri, 27 Apr 2012 06:25:20 +0000 Subject: [issue14579] CVE-2012-2135: Vulnerability in the utf-16 decoder after error handling In-Reply-To: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za> Message-ID: <1335507920.97.0.513241525993.issue14579@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 08:33:05 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 27 Apr 2012 06:33:05 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1331932171.45.0.56771909125.issue14339@psf.upfronthosting.co.za> Message-ID: <1335508385.42.0.0959662274396.issue14339@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Serhiy: what's the status of your contributor form? Note that you can also fax it, or scan it and send it by email. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 09:03:25 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 27 Apr 2012 07:03:25 +0000 Subject: [issue14676] DeprecationWarning missing in default warning filters documentation In-Reply-To: <1335458952.26.0.88746757742.issue14676@psf.upfronthosting.co.za> Message-ID: <1335510205.02.0.653042624895.issue14676@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 09:03:39 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 27 Apr 2012 07:03:39 +0000 Subject: [issue1521950] shlex.split() does not tokenize like the shell Message-ID: <1335510219.1.0.283041652275.issue1521950@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 09:05:44 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 27 Apr 2012 07:05:44 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <1335217931.89.0.157136074708.issue14656@psf.upfronthosting.co.za> Message-ID: <1335510344.06.0.00473909153935.issue14656@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 09:06:02 2012 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 27 Apr 2012 07:06:02 +0000 Subject: [issue13934] sqlite3 test typo In-Reply-To: <1328294661.43.0.135509150445.issue13934@psf.upfronthosting.co.za> Message-ID: <1335510362.94.0.918118990295.issue13934@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 09:13:40 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 27 Apr 2012 07:13:40 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1335510820.61.0.302309727411.issue14673@psf.upfronthosting.co.za> Martin v. L?wis added the comment: When I added sys.subversion, people requested that it shall contain the CPython string. When sys._mercurial was introduced, it copied that. So there are plenty of ways already to figure out that it is CPython which you are using. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 09:23:18 2012 From: report at bugs.python.org (Stefano Taschini) Date: Fri, 27 Apr 2012 07:23:18 +0000 Subject: [issue8767] Configure: Cannot disable unicode In-Reply-To: <1274286115.56.0.588868311562.issue8767@psf.upfronthosting.co.za> Message-ID: <1335511398.16.0.878132040172.issue8767@psf.upfronthosting.co.za> Stefano Taschini added the comment: Here's the patch. It has four goals: 1. Allow ./configure --disable-unicode to work; 2. Have the naked interpreter running with no unicode support; 3. Be able to compile most of the stdlib; 4. Be able to run the test suite. The one-line modification to configure.ac (and consequentley autoreconf'ed configure) achieve goal 1. The changes to the three C files (which are nothing more than a few #ifdef Py_USING_UNICODE) achieve goal 2: you can run "./python -S". The fix for site.py takes care of posixpath, glob, (and a few other modules) and makes it possible to compile most of the C extensions of the stdlib, goal 3 -- The compilation process under posix requires posixpath and glob to work. The most notable extension that won't be built is, unsurprisingly enough, io. Fortunately it does not play in Python 2.7 the central role it plays in Python 3. Still, a few other modules depend on it and won't be usable. The changes in Lib/test/script_helper.py and Lib/test/test_support.py make it possible to run the test suite. Roughly one third of the tests will fail, though, but I think that's acceptable. In relation to my purpose for submitting this patch ( #1065986 ) , I note that test_pydoc runs and succeeds. ---------- keywords: +patch Added file: http://bugs.python.org/file25377/issue8767.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 09:28:24 2012 From: report at bugs.python.org (Florent Xicluna) Date: Fri, 27 Apr 2012 07:28:24 +0000 Subject: [issue2387] cStringIO and unicode In-Reply-To: <1205846879.92.0.0083654313835.issue2387@psf.upfronthosting.co.za> Message-ID: <1335511704.08.0.138278077219.issue2387@psf.upfronthosting.co.za> Florent Xicluna added the comment: It seems the documentation is not enough accurate. "Unlike the StringIO module, this module is not able to accept Unicode strings that cannot be encoded as plain ASCII strings." I understand that u'foo' can be encoded as plan ASCII, however it does not behave correctly with cStringIO. Python 2.7.3 (default, Apr 14 2012, 01:49:35) >>> from cStringIO import StringIO >>> StringIO(u'foo').read() 'f\x00o\x00o\x00' >>> ---------- nosy: +flox resolution: rejected -> status: closed -> open versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 09:31:23 2012 From: report at bugs.python.org (Eric Snow) Date: Fri, 27 Apr 2012 07:31:23 +0000 Subject: [issue14673] add sys.implementation In-Reply-To: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za> Message-ID: <1335511883.57.0.841071180383.issue14673@psf.upfronthosting.co.za> Eric Snow added the comment: An updated patch using a dict. (FYI, I have the PEP up on python-ideas.) ---------- Added file: http://bugs.python.org/file25378/sys_implementation_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 09:38:21 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 27 Apr 2012 07:38:21 +0000 Subject: [issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu In-Reply-To: <1335487835.45.0.404451944915.issue14610@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Yes, this code is hanging in my system. I'm posting the strace output. > > If there's any other information that may be helpful I'll happily provide it. Well, in that case it's a bug in your pthread implementation: returning from main() with detached threads should terminate the process. You should report this to your distribution bug tracker. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 11:31:38 2012 From: report at bugs.python.org (rampythonnewbie) Date: Fri, 27 Apr 2012 09:31:38 +0000 Subject: [issue14681] Problem in installation of version 2.3.5 on mac OS X 10.5.8 Message-ID: <1335519098.21.0.990539777894.issue14681@psf.upfronthosting.co.za> New submission from rampythonnewbie : Hello, I am working on an application that runs only on Python version 2.3.5. Presently i am using mac os x 10.5.8. It came with pre-installed python 2.5.1. Now, when i am running that application with existing version, it is showing the following error.. "RuntimeWarning: Python C API version mismatch for module _AE: This Python has API version 1013, module _AE has version 1012." So, I want to install version 2.3.5 on my machine along with existing python 2.5.1 unchanged. I tried the following procedure to install: 1. Downloaded "Python-2.3.5.tgz" from www.python.org 2. Unpacked it with "tar -zxvf Python-2.3.5.tgz" command. 3. ./configure --prefix=/users/myhomedir/python23 4. make altinstall But, I am getting following error: "gcc -u __dummy -u _PyMac_Error -framework System -framework CoreServices -framework Foundation -o python.exe \ Modules/python.o \ libpython2.3.a -ldl Undefined symbols: "__dummy", referenced from: ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [python.exe] Error 1" Please help me to know how to install multiple versions of python on mac OS X 10.5 without using macports and virtualenv... Thanks in advance ---------- messages: 159446 nosy: rampythonnewbie priority: normal severity: normal status: open title: Problem in installation of version 2.3.5 on mac OS X 10.5.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 12:10:30 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 27 Apr 2012 10:10:30 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1335521430.83.0.717772248657.issue11618@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Antoine: of course, sorry for rushing you. Martin, This is an XP patch. The "vista" option is put in there as a compile time option, and disabled by hand. I'm not adding any apis that weren't already in use since the new gil (windows Semaphores). Incidentally, we should make sure that python defines NTDDI_VERSION to NTDDI_WINXP (0x05010000), either in the sources before including "windows" (tricky) or in the solution (probably in the .prefs files) This will ensure that we don't attempt to use non-existent features, unless we dynamically check for them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 13:12:10 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 27 Apr 2012 11:12:10 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335525130.48.0.564402315496.issue13210@psf.upfronthosting.co.za> Richard Oudkerk added the comment: The problems with error numbers seem to be caused by the addition of a new section in errno.h: /* POSIX SUPPLEMENT */ #define EADDRINUSE 100 #define EADDRNOTAVAIL 101 ... #define ETXTBSY 139 #define EWOULDBLOCK 140 Of these the only ones which clash with WSA equivalents are EADDRINUSE EADDRNOTAVAIL EAFNOSUPPORT EALREADY ECONNABORTED ECONNREFUSED ECONNRESET EDESTADDRREQ EHOSTUNREACH EINPROGRESS EISCONN ELOOP EMSGSIZE ENETDOWN ENETRESET ENETUNREACH ENOBUFS ENOPROTOOPT ENOTCONN ENOTSOCK EOPNOTSUPP EPROTONOSUPPORT EPROTOTYPE ETIMEDOUT EWOULDBLOCK I think the simplest solution is just to undefine these new "clashing" constants near the top of Modules/errnomodule.c and Objects/exceptions.c so that we fall back to the preferred WSA equivalents later. I have tried this by cloning sandbox/vs2010port, reverting Objects/exceptions.c Modules/posixmodule.c Modules/errnomodule.c Modules/_io/fileio.c to "ancestor(vs2010,default)" and then applying the attached patch. I get four failures: test_distutils test_email test_import test_packaging This is an improvement over the tip of vs2010 (2fc5398b3115) where I get two additional failures test_importlib test_subprocess ---------- Added file: http://bugs.python.org/file25379/wsa_undef.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 13:19:55 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Apr 2012 11:19:55 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1331932171.45.0.56771909125.issue14339@psf.upfronthosting.co.za> Message-ID: <1335525595.28.0.654998925129.issue14339@psf.upfronthosting.co.za> STINNER Victor added the comment: > You may call assert(_PyUnicode_CheckConsistency(v, 1)) to ensure > that the newly created string is "consistent" (see the function > for the details). Done in the following changeset: changeset: 76560:3bdcf0cab164 parent: 76558:5fea362b92fc user: Victor Stinner date: Thu Apr 26 00:37:21 2012 +0200 files: Objects/longobject.c description: long_to_decimal_string() and _PyLong_Format() check the consistency of newly created strings using _PyUnicode_CheckConsistency() in debug mode ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 13:47:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 27 Apr 2012 11:47:09 +0000 Subject: [issue2387] cStringIO and unicode In-Reply-To: <1205846879.92.0.0083654313835.issue2387@psf.upfronthosting.co.za> Message-ID: <1335527229.2.0.941259414381.issue2387@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This was fixed in 2.7.3 actually (27ae7d4e1983): Python 2.7.3+ (2.7:8b8b580e3fd3, Apr 25 2012, 17:24:51) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from cStringIO import StringIO >>> StringIO(u'foo').read() 'foo' ---------- nosy: +pitrou resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> shlex (or perhaps cStringIO) and unicode strings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 13:48:30 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 27 Apr 2012 11:48:30 +0000 Subject: [issue8767] Configure: Cannot disable unicode In-Reply-To: <1274286115.56.0.588868311562.issue8767@psf.upfronthosting.co.za> Message-ID: <1335527310.07.0.735591816004.issue8767@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 14:07:16 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Apr 2012 12:07:16 +0000 Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2 In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za> Message-ID: <1335528436.58.0.946945637988.issue13621@psf.upfronthosting.co.za> STINNER Victor added the comment: > "Andrew"+"Dalke" (*1000): -23.076923% /python -m timeit '"Andrew"+"Dalke"' gives me very close results with Python 3.2 (wide mode) and 3.3. Somethings like 0.15 vs 0.151 microseconds. But using longer (ASCII) strings, Python 3.3 is 2.6x faster: $ python3.2 -m timeit -s 'a="A"*1000; b="B"*1000' 'a+b' 1000000 loops, best of 3: 0.39 usec per loop $ python3.3 -m timeit -s 'a="A"*1000; b="B"*1000' 'a+b' 10000000 loops, best of 3: 0.151 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 14:21:59 2012 From: report at bugs.python.org (Stefano Taschini) Date: Fri, 27 Apr 2012 12:21:59 +0000 Subject: [issue1065986] Fix pydoc crashing on unicode strings Message-ID: <1335529319.58.0.751505375377.issue1065986@psf.upfronthosting.co.za> Stefano Taschini added the comment: Here's my patch, along the lines of the work-around I posted earlier. A few remarks: 1. The modifications in pydoc only touch the four console pagers and the html pager (html.page). 2. A module-wide default encoding is initialized from locale.getpreferredencoding. Pagers that write to a file use the encoding of that file if defined, else they use the module-wide default. The html pager uses ascii. All of them use xml character entity replacement as fall-back. 3. An additional set of tests has been added to test.test_pydoc to verify the behaviour of the modifications. 4. No functionality is broken if Python is built without unicode support. ---------- Added file: http://bugs.python.org/file25380/issue1065986.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 14:58:55 2012 From: report at bugs.python.org (rampythonnewbie) Date: Fri, 27 Apr 2012 12:58:55 +0000 Subject: [issue14681] Problem in installation of version 2.3.5 on mac OS X 10.5.8 In-Reply-To: <1335519098.21.0.990539777894.issue14681@psf.upfronthosting.co.za> Message-ID: <1335531535.33.0.865385464046.issue14681@psf.upfronthosting.co.za> rampythonnewbie added the comment: Hello, I am working on an application that runs only on Python version 2.3.5. Presently i am using mac os x 10.5.8. It came with pre-installed python 2.5.1. Now, when i am running that application with existing version, it is showing the following error.. "RuntimeWarning: Python C API version mismatch for module _AE: This Python has API version 1013, module _AE has version 1012." So, I want to install version 2.3.5 on my machine along with existing python 2.5.1 unchanged. I tried the following procedure to install: 1. Downloaded "Python-2.3.5.tgz" from www.python.org 2. Unpacked it with "tar -zxvf Python-2.3.5.tgz" command. 3. ./configure --prefix=/users/myhomedir/python23 4. make altinstall But, I am getting following error: "gcc -u __dummy -u _PyMac_Error -framework System -framework CoreServices -framework Foundation -o python.exe \ Modules/python.o \ libpython2.3.a -ldl Undefined symbols: "__dummy", referenced from: ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [python.exe] Error 1" Please help me to know how to install multiple versions of python on mac OS X 10.5 without using macports and virtualenv... Thanks in advance ---------- components: +Installation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 16:06:13 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 27 Apr 2012 14:06:13 +0000 Subject: [issue10976] json.loads() raises TypeError on bytes object In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za> Message-ID: <1335535573.29.0.108122670462.issue10976@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > According to current implementation this is acceptable. Then perhaps auto-detection can be restricted to strict mode? Non-strict mode would always use utf-8. Or we can just skip auto-detection altogether (I don't think many people produce utf-16 or utf-32 JSON; that would be a waste of bandwidth for no obvious benefit). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 16:09:39 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 27 Apr 2012 14:09:39 +0000 Subject: [issue14059] Implement multiprocessing.Barrier In-Reply-To: <1329699138.74.0.937439869593.issue14059@psf.upfronthosting.co.za> Message-ID: <1335535779.74.0.353323625736.issue14059@psf.upfronthosting.co.za> Antoine Pitrou added the comment: RawValue uses ctypes, right? That's problematic for platforms which don't support ctypes. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 16:10:19 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 27 Apr 2012 14:10:19 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b3d3f3238c13 by Martin v. Loewis in branch 'default': Issue #14642: Add "hg touch" extension, and "make touch" target. http://hg.python.org/cpython/rev/b3d3f3238c13 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 16:12:47 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 27 Apr 2012 14:12:47 +0000 Subject: [issue14681] Problem in installation of version 2.3.5 on mac OS X 10.5.8 In-Reply-To: <1335519098.21.0.990539777894.issue14681@psf.upfronthosting.co.za> Message-ID: <1335535967.73.0.112707980822.issue14681@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Both 2.3.5 and 2.5.1 are very old versions, and are unsupported. We would only take bug reports for Python 2.7 and 3.2. Furthermore, it is not obvious that you are actually reporting a bug; it sounds like you're looking for help instead, which can be asked for on http://mail.python.org/pipermail/python-list/ ---------- nosy: +ned.deily, pitrou resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 16:13:02 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 27 Apr 2012 14:13:02 +0000 Subject: [issue14682] Backport missing errnos to 2.7 Message-ID: <1335535982.47.0.591124202563.issue14682@psf.upfronthosting.co.za> New submission from Hynek Schlawack : In order to fix issue14662, we need to back port at least ENOTSUP to 2.7 (presuming we don?t want to check for magic numbers). The question is, whether we should back port all/most of them when we?re at it? There doesn?t seem to be much harm to it. ---------- assignee: ronaldoussoren components: IO, Library (Lib), Macintosh messages: 159458 nosy: benjamin.peterson, eric.araujo, hynek, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Backport missing errnos to 2.7 type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 16:14:55 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 27 Apr 2012 14:14:55 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1335536095.05.0.297223797874.issue11618@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > This is an XP patch. The "vista" option is put in there as a compile > time option, and disabled by hand. I'm not adding any apis that > weren't already in use since the new gil (windows Semaphores). Martin means that you shouldn't use #ifdef's but runtime detection, so that we can provide a single installer for all Windows versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 16:33:05 2012 From: report at bugs.python.org (Luke McCarthy) Date: Fri, 27 Apr 2012 14:33:05 +0000 Subject: [issue14683] os.path.isdir.__name__ is "_isdir" on Windows (2.7.3) Message-ID: <1335537185.91.0.610172634713.issue14683@psf.upfronthosting.co.za> New submission from Luke McCarthy : This caused something to break in our code. I know, maybe it shouldn't rely on that. ---------- messages: 159460 nosy: shaurz priority: normal severity: normal status: open title: os.path.isdir.__name__ is "_isdir" on Windows (2.7.3) versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 16:34:52 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Apr 2012 14:34:52 +0000 Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2 In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za> Message-ID: <1335537292.29.0.0908816120369.issue13621@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: But try ASCII+UCS2 or ASCII+UCS4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 16:43:08 2012 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 27 Apr 2012 14:43:08 +0000 Subject: [issue13210] Support Visual Studio 2010 In-Reply-To: <1318942521.44.0.961979099616.issue13210@psf.upfronthosting.co.za> Message-ID: <1335537788.02.0.702160950261.issue13210@psf.upfronthosting.co.za> Richard Oudkerk added the comment: According to http://msdn.microsoft.com/en-us/library/5814770t.aspx the "supported" errno values in VS2010 are E2BIG EACCES EAGAIN EBADF ECHILD EDEADLOCK EDOM EEXIST EILSEQ EINVAL EMFILE ENOENT ENOEXEC ENOMEM ENOSPC ERANGE EXDEV STRUNCATE of which the ones with WSA equivalents are EACCES EBADF EINVAL EMFILE The other constants listed in errno.h are for "compatibility with POSIX". I take this to mean that the only errno values which will be set by libc are on the supported list. We should not change any of these, but I think we can redefine the others to WSA equivalents without a problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 16:52:33 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Apr 2012 14:52:33 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1334954469.29.0.182446723784.issue14339@psf.upfronthosting.co.za> Message-ID: <1335537149.2572.6.camel@raxxla> Serhiy Storchaka added the comment: I sent the signed form. Martin, sorry for the delay. Mark, sorry, that involuntarily let you down. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 17:08:20 2012 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 27 Apr 2012 15:08:20 +0000 Subject: [issue14682] Backport missing errnos to 2.7 In-Reply-To: <1335535982.47.0.591124202563.issue14682@psf.upfronthosting.co.za> Message-ID: <1335539300.69.0.221779009491.issue14682@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Benjamin should talk about this, but I am +1 to backport the missing DEFINEs. In fact, hardwired values are actually a bug, as reported in the linked issue. ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 17:10:30 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 27 Apr 2012 15:10:30 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1335539430.34.0.532425340809.issue11618@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: I understand what he meant, but that wasn't the intent of the patch. The patch is to use simulated critical sections using a semaphore, same as the new GIL implementation already does. If you want dynamic runtime detection, then this is a feature request :) I'm not sure we do it elsewhere in Python, and the benefit is doubtful... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 17:13:04 2012 From: report at bugs.python.org (Brian Curtin) Date: Fri, 27 Apr 2012 15:13:04 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1335539584.97.0.366784621008.issue11618@psf.upfronthosting.co.za> Brian Curtin added the comment: We do the runtime checks for a few things in winreg as well as the os.symlink implementation and i think a few other supplemental functions for symlinking. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 17:20:42 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 27 Apr 2012 15:20:42 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1335540042.16.0.461025934486.issue4489@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Anybody working on this one? I?d give it a shot otherwise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 17:23:10 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 27 Apr 2012 15:23:10 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1335540190.2.0.0473705330002.issue11618@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Ok, but the patch as provided would become more compliated. For general consumption, the primitives would need to become dynamically allocated structures, and so on. I'm not sure that its worth the effort, but I can have a look. (I thought the patch was radical enough, tbh.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 17:28:07 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Apr 2012 15:28:07 +0000 Subject: [issue10976] json.loads() raises TypeError on bytes object In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za> Message-ID: <1335540487.2.0.657570914574.issue10976@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Related to this question is a question about errors. How to inform the user, if an error occurred in the decoding with detected encoding? Leave UnicodeDecodeError or convert it to ValueError? If there is a syntax error in JSON -- exception will refer to the position in the decoded string, we should to translate it to the position in the original binary string? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 17:31:39 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 27 Apr 2012 15:31:39 +0000 Subject: [issue13621] Unicode performance regression in python3.3 vs python3.2 In-Reply-To: <1324143288.9.0.0386408512626.issue13621@psf.upfronthosting.co.za> Message-ID: <1335540699.89.0.550929644697.issue13621@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm closing this as "won't fix". The only way to get back the exact performance of 3.2 is to restore to the 3.2 implementation, which clearly is no option. I don't consider performance regressions in micro benchmarks inherently as a bug. If there is a specific regression which people think constitutes a real problem, a separate bug report should be submitted. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 17:37:59 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 27 Apr 2012 15:37:59 +0000 Subject: [issue14683] os.path.isdir.__name__ is "_isdir" on Windows (2.7.3) In-Reply-To: <1335537185.91.0.610172634713.issue14683@psf.upfronthosting.co.za> Message-ID: <1335541079.78.0.733124297006.issue14683@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is not a bug. Due to function name aliasing, this can easily happen, and the function's name should be considered as an implementation detail. ---------- nosy: +loewis resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 17:43:50 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 27 Apr 2012 15:43:50 +0000 Subject: [issue14682] Backport missing errnos to 2.7 In-Reply-To: <1335535982.47.0.591124202563.issue14682@psf.upfronthosting.co.za> Message-ID: <1335541430.5.0.6236822761.issue14682@psf.upfronthosting.co.za> Antoine Pitrou added the comment: That's like introducing a new API, and therefore it should be limited to feature releases. ---------- nosy: +loewis, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 17:44:19 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 27 Apr 2012 15:44:19 +0000 Subject: [issue8767] Configure: Cannot disable unicode In-Reply-To: <1274286115.56.0.588868311562.issue8767@psf.upfronthosting.co.za> Message-ID: <1335541459.31.0.232362790942.issue8767@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I find the injection of a fake unicode class too hacky. Instead, I suggest that each module does try: _unicode = unicode except NameError: # no unicode support in this build class _unicode: pass and then have the isinstance checks look for _unicode ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 17:46:05 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 27 Apr 2012 15:46:05 +0000 Subject: [issue14682] Backport missing errnos to 2.7 In-Reply-To: <1335535982.47.0.591124202563.issue14682@psf.upfronthosting.co.za> Message-ID: <1335541565.23.0.375714253304.issue14682@psf.upfronthosting.co.za> Hynek Schlawack added the comment: So what does that mean for issue14662? Backport only ENOTSUP, check against ?45? or ?won't fix?? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 17:46:11 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 27 Apr 2012 15:46:11 +0000 Subject: [issue14672] Windows installer: add desktop shortcut(s) In-Reply-To: <1335414011.97.0.984037154974.issue14672@psf.upfronthosting.co.za> Message-ID: <1335541571.83.0.599755619988.issue14672@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Is it really the case that novice users fail to understand the Start menu? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 17:51:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 27 Apr 2012 15:51:46 +0000 Subject: [issue14682] Backport missing errnos to 2.7 In-Reply-To: <1335535982.47.0.591124202563.issue14682@psf.upfronthosting.co.za> Message-ID: <1335541906.09.0.229063929384.issue14682@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > So what does that mean for issue14662? Backport only ENOTSUP, check > against ?45? or ?won't fix?? Then, backporting only ENOTSUP would be a reasonable solution. Or perhaps backport it as a private attribute (_ENOTSUP). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 17:54:09 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 27 Apr 2012 15:54:09 +0000 Subject: [issue14672] Windows installer: add desktop shortcut(s) In-Reply-To: <1335414011.97.0.984037154974.issue14672@psf.upfronthosting.co.za> Message-ID: <1335542049.34.0.572468662688.issue14672@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 17:57:28 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 27 Apr 2012 15:57:28 +0000 Subject: [issue14682] Backport missing errnos to 2.7 In-Reply-To: <1335535982.47.0.591124202563.issue14682@psf.upfronthosting.co.za> Message-ID: <1335542248.8.0.357320936246.issue14682@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think it's okay to just backport ENOTSUP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 19:01:37 2012 From: report at bugs.python.org (Mark Shannon) Date: Fri, 27 Apr 2012 17:01:37 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1335546097.72.0.467713342137.issue13903@psf.upfronthosting.co.za> Mark Shannon added the comment: Decref cached-keys when type is deallocated. Patch attached. ---------- Added file: http://bugs.python.org/file25381/cached_keys.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 19:30:07 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 27 Apr 2012 17:30:07 +0000 Subject: [issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails) In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335547807.08.0.416425844718.issue14662@psf.upfronthosting.co.za> Hynek Schlawack added the comment: This is a fix for 2.7. As Benjamin said in http://bugs.python.org/issue14682#msg159477 it?s okay to back port ENOTSUP, I did it as part of the patch here. I wasn?t sure whether we should document it? I?m porting the patch to tip right now, reviews/opinions welcome. ---------- keywords: +patch nosy: +pitrou Added file: http://bugs.python.org/file25382/expand-chflags-catch-2.7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 19:55:52 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 27 Apr 2012 17:55:52 +0000 Subject: [issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails) In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335549352.71.0.417135404666.issue14662@psf.upfronthosting.co.za> Hynek Schlawack added the comment: This one is against tip. ---------- Added file: http://bugs.python.org/file25383/expand-chflags-catch-tip.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 19:56:20 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 27 Apr 2012 17:56:20 +0000 Subject: [issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails) In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335549380.36.0.263540727463.issue14662@psf.upfronthosting.co.za> Hynek Schlawack added the comment: And finally against 3.2 ---------- Added file: http://bugs.python.org/file25384/expand-chflags-catch-3.2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 20:02:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 27 Apr 2012 18:02:45 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset c18256de00bb by Brett Cannon in branch 'default': Issue #14605: Insert to the front of sys.meta_path, don't append. http://hg.python.org/cpython/rev/c18256de00bb New changeset 3bd60cc27664 by Brett Cannon in branch 'default': Issue #14605: Stop having implicit entries for sys.meta_path. http://hg.python.org/cpython/rev/3bd60cc27664 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 21:00:46 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Apr 2012 19:00:46 +0000 Subject: [issue7185] csv reader utf-8 BOM error In-Reply-To: <1256208366.7.0.205796618954.issue7185@psf.upfronthosting.co.za> Message-ID: <1335553246.35.0.177836456992.issue7185@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I checked out. Files opened in "utf-8-sig" are seekable. >>> open('test', 'w', encoding='utf-8-sig').write('qwerty\n??????\n') >>> open('test', 'r', encoding="utf-8").read() '\ufeffqwerty\n??????\n' >>> open('test', 'r', encoding="utf-8-sig").read() 'qwerty\n??????\n' >>> with open('test', 'r', encoding="utf-8-sig") as f: ... print(ascii(f.readline())) ... f.seek(0) ... print(ascii(f.readline())) ... 'qwerty\n' 0 'qwerty\n' Should this issue be closed? ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 21:07:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 27 Apr 2012 19:07:43 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset a3beae842f13 by Benjamin Peterson in branch 'default': decref cached keys on type deallocation (#13903) http://hg.python.org/cpython/rev/a3beae842f13 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 21:08:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 27 Apr 2012 19:08:33 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: Message-ID: <1335553622.3340.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > New changeset a3beae842f13 by Benjamin Peterson in branch 'default': > decref cached keys on type deallocation (#13903) > http://hg.python.org/cpython/rev/a3beae842f13 Is there any way to detect / avoid leaks on this separate refcounting scheme? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 21:31:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 27 Apr 2012 19:31:52 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 7025ee00dbf6 by Brett Cannon in branch 'default': Issue #14605: Use None in sys.path_importer_cache to represent no http://hg.python.org/cpython/rev/7025ee00dbf6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 21:35:50 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 27 Apr 2012 19:35:50 +0000 Subject: [issue14674] Add link to RFC 4627 from json documentation In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za> Message-ID: <1335555350.81.0.334433766204.issue14674@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- keywords: +easy nosy: +eric.araujo stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 21:45:29 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 27 Apr 2012 19:45:29 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 141ed4b426e1 by Brett Cannon in branch 'default': Issue #14605: Don't error out if get_importer() returns None. http://hg.python.org/cpython/rev/141ed4b426e1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 21:49:03 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 27 Apr 2012 19:49:03 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335556143.32.0.207516027273.issue14605@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, so the todo of this issue is now finished. I am just waiting for the buildbots to come back green before I close this issue fully. ---------- stage: commit review -> committed/rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 22:00:26 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 27 Apr 2012 20:00:26 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1335556826.15.0.588253954834.issue13903@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This patch integrates the dictkeys' refcounting into the refcount checking framework. Seems to work ok, but it would be better if someone more acquainted with the code could confirm it. ---------- Added file: http://bugs.python.org/file25385/dkdebug.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 22:03:12 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 27 Apr 2012 20:03:12 +0000 Subject: [issue14605] Make import machinery explicit In-Reply-To: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za> Message-ID: <1335556992.27.0.800643231364.issue14605@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 22:12:26 2012 From: report at bugs.python.org (R. David Murray) Date: Fri, 27 Apr 2012 20:12:26 +0000 Subject: [issue7185] csv reader utf-8 BOM error In-Reply-To: <1256208366.7.0.205796618954.issue7185@psf.upfronthosting.co.za> Message-ID: <1335557546.33.0.0882469341644.issue7185@psf.upfronthosting.co.za> R. David Murray added the comment: Serhiy, the bug is about csv in particular. Can you confirm that using utf-8-sig allows one to process a file with a bom using the csv module? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 22:46:31 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Apr 2012 20:46:31 +0000 Subject: [issue1767933] Badly formed XML using etree and utf-16 Message-ID: <1335559591.81.0.532315556251.issue1767933@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which solves the problem of writing ElementTree with utf-16 or utf-32 encoding. ---------- keywords: +patch nosy: +storchaka versions: +Python 3.3 Added file: http://bugs.python.org/file25386/etree_write_utf16.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 22:49:10 2012 From: report at bugs.python.org (Sam Rushing) Date: Fri, 27 Apr 2012 20:49:10 +0000 Subject: [issue14684] zlib set dictionary support inflateSetDictionary Message-ID: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za> New submission from Sam Rushing : Google's SPDY protocol requires the use of a pre-defined compression dictionary. The current zlib module doesn't expose the two functions for setting the dictionary. This patch is minimal in the sense that it only exposes the two functions, but unfortunately the sequence of zlib calls required is clumsy: a call to inflate() must fail first (with an error of Z_NEED_DICT): import zlib zdict = b"thequickbrownfoxjumped\x00" c = zlib.compressobj() c.set_dictionary (zdict) cd = c.compress (b"the quick brown fox jumped over the candlestick") cd += c.flush() d = zlib.decompressobj() try: print (d.decompress (cd)) except zlib.error as what: if what.args[0].startswith ('Error 2 '): d.set_dictionary (zdict) print (d.flush()) Obviously a better way to catch/match Z_NEED_DICT would be nice. A much nicer solution would allow you to associate the dictionary at creation time, rather than having to wait for an error condition. I can only guess that the zlib authors designed it that way for a reason? ---------- components: Extension Modules files: zlib_set_dictionary.patch keywords: patch messages: 159492 nosy: Sam.Rushing priority: normal severity: normal status: open title: zlib set dictionary support inflateSetDictionary type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file25387/zlib_set_dictionary.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 22:50:00 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 27 Apr 2012 20:50:00 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: <1335559800.92.0.539129362665.issue14642@psf.upfronthosting.co.za> Brett Cannon added the comment: Can this issue be closed, Martin, thanks to your extension? ---------- assignee: -> loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 23:26:06 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Apr 2012 21:26:06 +0000 Subject: [issue7185] csv reader utf-8 BOM error In-Reply-To: <1256208366.7.0.205796618954.issue7185@psf.upfronthosting.co.za> Message-ID: <1335561966.61.0.185742681595.issue7185@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I ran the script above (only replaced 'utf-8' on 'utf-8-sig') and did not see anything strange. I looked at the source (cvs.py and _cvs.c) and also did not see anything that could lead to this effect. If the bug exists, it in utf-8-sig codec and should be expressed in other cases. There is nothing special for csv. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 23:33:08 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 27 Apr 2012 21:33:08 +0000 Subject: [issue14646] Require loaders set __loader__ and __package__ In-Reply-To: <1335123473.69.0.487132909443.issue14646@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 496c68f90a03 by Brett Cannon in branch 'default': Issue #14646: __import__() now sets __loader__ if need be. http://hg.python.org/cpython/rev/496c68f90a03 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 23:42:35 2012 From: report at bugs.python.org (Brett Cannon) Date: Fri, 27 Apr 2012 21:42:35 +0000 Subject: [issue14646] Require loaders set __loader__ and __package__ In-Reply-To: <1335123473.69.0.487132909443.issue14646@psf.upfronthosting.co.za> Message-ID: <1335562955.46.0.6881444821.issue14646@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 23:43:47 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 27 Apr 2012 21:43:47 +0000 Subject: [issue14685] segfault in --without-threads build Message-ID: <1335563027.12.0.967075753088.issue14685@psf.upfronthosting.co.za> New submission from Stefan Krah : The build --without-threads segfaults in run_tests.py: http://www.python.org/dev/buildbot/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/2123/steps/test/logs/stdio ---------- components: Tests messages: 159496 nosy: skrah priority: release blocker severity: normal stage: needs patch status: open title: segfault in --without-threads build type: crash versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 23:48:09 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Apr 2012 21:48:09 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1335563289.41.0.914558443066.issue14304@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Andrew, the patch solves your issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 23:48:59 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 27 Apr 2012 21:48:59 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1335563339.25.0.40870727591.issue13916@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 23:51:24 2012 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 27 Apr 2012 21:51:24 +0000 Subject: [issue14339] Optimizing bin, oct and hex In-Reply-To: <1331932171.45.0.56771909125.issue14339@psf.upfronthosting.co.za> Message-ID: <1335563484.26.0.984725189529.issue14339@psf.upfronthosting.co.za> Mark Dickinson added the comment: Serhiy: thanks for submitting the form! No need to apologise: it was my bad for making the commit prematurely. And now that I see that all-important asterisk next to your name, I'll reclose the issue. :-) ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 23:52:42 2012 From: report at bugs.python.org (Roundup Robot) Date: Fri, 27 Apr 2012 21:52:42 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335308517.69.0.701803893151.issue14666@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f163c4731c58 by Antoine Pitrou in branch 'default': Issue #14666: stop multiprocessing's resource-sharing thread after the tests are done. http://hg.python.org/cpython/rev/f163c4731c58 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 23:56:21 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 27 Apr 2012 21:56:21 +0000 Subject: [issue14583] try/except import fails --without-threads In-Reply-To: <1334436331.01.0.461185960127.issue14583@psf.upfronthosting.co.za> Message-ID: <1335563781.21.0.132900468818.issue14583@psf.upfronthosting.co.za> Stefan Krah added the comment: This issue is now apparently causing a segfault: (gdb) r ./Tools/scripts/run_tests.py -j 1 -u all -W --timeout=3600 Starting program: /home/stefan/pydev/cpython/python ./Tools/scripts/run_tests.py -j 1 -u all -W --timeout=3600 [...] Program received signal SIGSEGV, Segmentation fault. 0x000000000041b038 in PyObject_Repr (v=) at Objects/object.c:377 377 if (Py_TYPE(v)->tp_repr == NULL) (gdb) l [...] #0 0x000000000041b038 in PyObject_Repr (v=) at Objects/object.c:377 #1 0x0000000000460db0 in PyUnicode_FromFormatV (format=0x63e3e8 "%R not in sys.modules as expected", vargs= 0x7fffffff1ae0) at Objects/unicodeobject.c:2609 #2 0x00000000004e1be2 in PyErr_Format (exception=, format= 0x63e3e8 "%R not in sys.modules as expected") at Python/errors.c:697 #3 0x00000000004ed53f in PyImport_ImportModuleLevelObject (name='multiprocessing.process ---------- priority: high -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 23:57:46 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 27 Apr 2012 21:57:46 +0000 Subject: [issue14685] segfault in --without-threads build In-Reply-To: <1335563027.12.0.967075753088.issue14685@psf.upfronthosting.co.za> Message-ID: <1335563866.15.0.947994202823.issue14685@psf.upfronthosting.co.za> Stefan Krah added the comment: Appears to be related to #14583. ---------- keywords: +buildbot resolution: -> duplicate stage: needs patch -> committed/rejected status: open -> closed superseder: -> try/except import fails --without-threads _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 27 23:59:38 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 27 Apr 2012 21:59:38 +0000 Subject: [issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's doctype() method missing In-Reply-To: <1329193190.72.0.667201124226.issue14007@psf.upfronthosting.co.za> Message-ID: <1335563978.98.0.368984468208.issue14007@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 00:16:33 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 27 Apr 2012 22:16:33 +0000 Subject: [issue14686] SystemError in unicodeobject.c Message-ID: <1335564993.44.0.144159847253.issue14686@psf.upfronthosting.co.za> New submission from Stefan Krah : Seen on the Gentoo buildbot: http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/2154/steps/test/logs/stdio====================================================================== ERROR: test_format (test.test_bool.BoolTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_bool.py", line 167, in test_format self.assertEqual("%d" % False, "0") SystemError: Objects/unicodeobject.c:13507: bad argument to internal function ---------------------------------------------------------------------- ---------- components: Tests messages: 159502 nosy: haypo, skrah priority: normal severity: normal stage: needs patch status: open title: SystemError in unicodeobject.c type: crash versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 00:17:05 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 27 Apr 2012 22:17:05 +0000 Subject: [issue14686] SystemError in unicodeobject.c In-Reply-To: <1335564993.44.0.144159847253.issue14686@psf.upfronthosting.co.za> Message-ID: <1335565025.34.0.297964603262.issue14686@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 00:21:08 2012 From: report at bugs.python.org (Stefan Krah) Date: Fri, 27 Apr 2012 22:21:08 +0000 Subject: [issue14686] SystemError in unicodeobject.c In-Reply-To: <1335564993.44.0.144159847253.issue14686@psf.upfronthosting.co.za> Message-ID: <1335565268.52.0.27177294841.issue14686@psf.upfronthosting.co.za> Stefan Krah added the comment: On another bot: http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/2205/steps/test/logs/stdio [250/364] test_bool python: Objects/unicodeobject.c:13501: formatlong: Assertion `unicode_modifiable(result)' failed. Fatal Python error: Aborted Current thread 0xb75e16c0: File "", line 611 in get_code File "", line 510 in _load_module File "", line 294 in module_for_loader_wrapper File "", line 634 in load_module File "", line 1015 in _find_and_load File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/regrtest.py", line 1229 in runtest_inner File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/regrtest.py", line 907 in runtest File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/regrtest.py", line 710 in main File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/__main__.py", line 13 in File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/runpy.py", line 75 in _run_code File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/runpy.py", line 162 in _run_module_as_main make: *** [buildbottest] Aborted ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 00:29:29 2012 From: report at bugs.python.org (STINNER Victor) Date: Fri, 27 Apr 2012 22:29:29 +0000 Subject: [issue14686] SystemError in unicodeobject.c In-Reply-To: <1335564993.44.0.144159847253.issue14686@psf.upfronthosting.co.za> Message-ID: <1335565769.06.0.877907265124.issue14686@psf.upfronthosting.co.za> STINNER Victor added the comment: It's my fault. It should be fixed by: changeset: 76590:7bacccd889c2 tag: tip user: Victor Stinner date: Sat Apr 28 00:25:34 2012 +0200 files: Objects/unicodeobject.c description: Fix my previous commit: bool is a long, restore the specical case for bool ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 00:54:08 2012 From: report at bugs.python.org (Miki Tebeka) Date: Fri, 27 Apr 2012 22:54:08 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za> Message-ID: <1335567248.98.0.270388916445.issue3177@psf.upfronthosting.co.za> Miki Tebeka added the comment: Just to note there's http://pypi.python.org/pypi/desktop/0.4 out there. ---------- nosy: +tebeka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 02:04:08 2012 From: report at bugs.python.org (R. David Murray) Date: Sat, 28 Apr 2012 00:04:08 +0000 Subject: [issue7185] csv reader utf-8 BOM error In-Reply-To: <1256208366.7.0.205796618954.issue7185@psf.upfronthosting.co.za> Message-ID: <1335571448.87.0.788313303212.issue7185@psf.upfronthosting.co.za> R. David Murray added the comment: I wasn't sure which script you were referring to, so I checked it myself and got the same results as you: after the seek(0) on the file object opened with utf-8-sig, csv read all the lines in the file, including reading the header line correctly. So, let's close this. ---------- resolution: -> invalid stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 02:15:32 2012 From: report at bugs.python.org (Hobs) Date: Sat, 28 Apr 2012 00:15:32 +0000 Subject: [issue3177] Add shutil.open In-Reply-To: <1335567248.98.0.270388916445.issue3177@psf.upfronthosting.co.za> Message-ID: Hobs added the comment: Had no idea. Sounds like a good place for it. On Apr 28, 2012 6:54 AM, "Miki Tebeka" wrote: > > Miki Tebeka added the comment: > > Just to note there's http://pypi.python.org/pypi/desktop/0.4 out there. > > ---------- > nosy: +tebeka > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 02:47:59 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 28 Apr 2012 00:47:59 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 Message-ID: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> New submission from STINNER Victor : PyUnicode_Format() creates short temporary substrings. Attached patch tries to avoid substrings. For example, it avoids write of 1 character and repetition of 1 character like a space. PyUnicode_Format() now works in two steps: - computes the maximum character and the length of the output string - write characters into the output string I'm not sure that my patch is correct, nor that the change does really speed-up Python. Benchmark: ./python -m timeit \ -s 's="x=%s, y=%u, z=%x"; args=(123, 456, 789)' \ 's%args' ./python -m timeit \ -s 's="The %(k1)s is %(k2)s the %(k3)s."; args={"k1":"x","k2":"y","k3":"z",}' \ 's%args' Python 3.2: 1000000 loops, best of 3: 0.482 usec per loop 1000000 loops, best of 3: 0.295 usec per loop Python 3.3: 1000000 loops, best of 3: 0.653 usec per loop 1000000 loops, best of 3: 0.666 usec per loop Python 3.3 + patch: 1000000 loops, best of 3: 0.596 usec per loop 1000000 loops, best of 3: 0.566 usec per loop ---------- files: pyunicode_format.patch keywords: patch messages: 159508 nosy: haypo, loewis, pitrou priority: normal severity: normal status: open title: Optimize str%tuple for the PEP 393 type: performance versions: Python 3.3 Added file: http://bugs.python.org/file25388/pyunicode_format.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 02:53:10 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 28 Apr 2012 00:53:10 +0000 Subject: [issue14686] SystemError in unicodeobject.c In-Reply-To: <1335564993.44.0.144159847253.issue14686@psf.upfronthosting.co.za> Message-ID: <1335574390.16.0.434345514035.issue14686@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 07:43:57 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Apr 2012 05:43:57 +0000 Subject: [issue7185] csv reader utf-8 BOM error In-Reply-To: <1256208366.7.0.205796618954.issue7185@psf.upfronthosting.co.za> Message-ID: <1335591837.69.0.104750333751.issue7185@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I was referring to the script inlined in the message http://bugs.python.org/issue7185#msg94340 . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 10:14:23 2012 From: report at bugs.python.org (Stefan Krah) Date: Sat, 28 Apr 2012 08:14:23 +0000 Subject: [issue14387] Include\accu.h incompatible with Windows.h In-Reply-To: <1332417184.03.0.15615521555.issue14387@psf.upfronthosting.co.za> Message-ID: <1335600863.08.0.916688807177.issue14387@psf.upfronthosting.co.za> Stefan Krah added the comment: I think the issue is fixed in all affected branches. Georg, can we close it? ---------- resolution: -> fixed stage: -> committed/rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 10:22:58 2012 From: report at bugs.python.org (Georg Brandl) Date: Sat, 28 Apr 2012 08:22:58 +0000 Subject: [issue14387] Include\accu.h incompatible with Windows.h In-Reply-To: <1332417184.03.0.15615521555.issue14387@psf.upfronthosting.co.za> Message-ID: <1335601378.65.0.641278906751.issue14387@psf.upfronthosting.co.za> Georg Brandl added the comment: I think so, yes. ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 11:21:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 28 Apr 2012 09:21:58 +0000 Subject: [issue14448] Mention pytz in datetime's docs In-Reply-To: <1333056065.25.0.804124513061.issue14448@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 1e5a483248ce by Sandro Tosi in branch '2.7': Issue #14448: add reference to IANA timezone database; thanks to Georg/Nick suggestions http://hg.python.org/cpython/rev/1e5a483248ce New changeset a5a0d47e6e78 by Sandro Tosi in branch '3.2': Issue #14448: add reference to IANA timezone database; thanks to Georg/Nick suggestions http://hg.python.org/cpython/rev/a5a0d47e6e78 New changeset c91ed8dacf38 by Sandro Tosi in branch 'default': Issue #14448: merge with 3.2 http://hg.python.org/cpython/rev/c91ed8dacf38 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 11:28:32 2012 From: report at bugs.python.org (Dionysios Kalofonos) Date: Sat, 28 Apr 2012 09:28:32 +0000 Subject: [issue14688] Typos in sorting.rst Message-ID: <1335605311.94.0.280572266619.issue14688@psf.upfronthosting.co.za> New submission from Dionysios Kalofonos : Please see the file attached. ---------- assignee: docs at python components: Documentation files: sorting.diff keywords: patch messages: 159513 nosy: dk, docs at python priority: normal severity: normal status: open title: Typos in sorting.rst versions: Python 3.3 Added file: http://bugs.python.org/file25389/sorting.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 11:56:05 2012 From: report at bugs.python.org (Peter Eisentraut) Date: Sat, 28 Apr 2012 09:56:05 +0000 Subject: [issue14689] make PYTHONWARNINGS variable work in libpython Message-ID: <1335606965.58.0.412104204254.issue14689@psf.upfronthosting.co.za> New submission from Peter Eisentraut : The environment variable PYTHONWARNINGS only works with the python interpreter binary, but not with programs embedding libpython. This could be changed by moving the code from Modules/main.c to Python/pythonrun.c. See attached patch (compiles cleanly, tests pass, not tested on Windows). (I have checked all the other environment variables listed on the python man page for whether those that could be usable in the library are actually processed in the library, and all but PYTHONWARNINGS appear to behave reasonably.) ---------- components: Interpreter Core files: py-pythonwarnings-envvar.patch keywords: patch messages: 159514 nosy: petere priority: normal severity: normal status: open title: make PYTHONWARNINGS variable work in libpython type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25390/py-pythonwarnings-envvar.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 11:57:09 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 28 Apr 2012 09:57:09 +0000 Subject: [issue14642] Fix importlib.h build rule to not depend on hg In-Reply-To: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za> Message-ID: <1335607029.08.0.704173241464.issue14642@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As I don't fully understand what the original issue was, I can't know for sure whether it's fixed now. But yes, there is now a mechanism to bring the time stamps in the right order. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 12:23:54 2012 From: report at bugs.python.org (Roundup Robot) Date: Sat, 28 Apr 2012 10:23:54 +0000 Subject: [issue14676] DeprecationWarning missing in default warning filters documentation In-Reply-To: <1335458952.26.0.88746757742.issue14676@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 0ad724738f6a by Sandro Tosi in branch '2.7': Issue #14676: DeprecationWarning is ignored too; patch by Peter Eisentraut http://hg.python.org/cpython/rev/0ad724738f6a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 12:24:38 2012 From: report at bugs.python.org (Sandro Tosi) Date: Sat, 28 Apr 2012 10:24:38 +0000 Subject: [issue14676] DeprecationWarning missing in default warning filters documentation In-Reply-To: <1335458952.26.0.88746757742.issue14676@psf.upfronthosting.co.za> Message-ID: <1335608678.82.0.482799466498.issue14676@psf.upfronthosting.co.za> Sandro Tosi added the comment: Peter: thanks for the patch! ---------- nosy: +sandro.tosi resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 12:38:41 2012 From: report at bugs.python.org (Larry Hastings) Date: Sat, 28 Apr 2012 10:38:41 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1335609521.18.0.838505540884.issue14626@psf.upfronthosting.co.za> Larry Hastings added the comment: Here my first stab at a comprehensive proposal. Each section represents a specific new function argument, and a list of functions that the argument be added to. All new arguments are keyword-only and optional. All functions mentioned are in the os module. _______________________________________ This annotation: foo [X bar] means "if we add this argument to function foo, we can remove function bar". This is because bar is a new function only in trunk and has no installed base. This annotation: foo [- bar] means "if we add this argument to function foo, we could theoretically start deprecating function bar". bar shipped in a previous version of Python and we can't simply remove it. However! I am *not* proposing doing *any* of these deprecations--I suspect the right thing to do is to leave all the existing functions in. _______________________________________ follow_symlinks=bool (default True) Allow functions to either follow symlinks (the default) or examine symlinks. access [X faccessat] chflags [- lchflags] chmod [- lchmod] chown [- lchown] getxattr [X lgetxattr] link [X linkat] listxattr [X llistxattr] removexattr [X lremovexattr] setxattr [X lsetxattr] stat [- lstat] utime [X lutimes] _______________________________________ effective_ids=bool (default False) For functions that take the AT_EACCESS flag or otherwise operate on effective uid/gid. access [X faccessat] (this also lets us skip ever adding euidaccess!) _______________________________________ dir_fd=int (default None) For functions that take a "dir_fd" parameter instead of / in addition to a "path" parameter. access [X faccessat] chmod [X fchmodat] chown [X fchownat] getxattr [X fgetxattr] link [X linkat] (note! need two parameters here.) mkdir [X mkdirat] mkfifo [X mkfifoat] mknod [X mknodat] open [X openat] readlink [X readlinkat] rename [X renameat] stat [X fstatat] symlink [X symlinkat] unlink [X unlinkat] utime [X futimesat utimensat] _______________________________________ fd=int (default None) For functions that take a "path" parameter and have an "f"-equivalent that take an "fd" instead. The "path" parameter and "fd" parameters would be exclusive; you must specify exactly one, never both. Both parameters would accept "None" as equivalent to being unspecified. For the functions that only take one parameter (chdir, listdir, stat, statvfs) I propose we give that parameter a default of None. chdir [- fchmod] chown [- fchown] execve [X fexecve] getxattr [X fgetxattr] listdir [X flistdir] listxattr [X flistxattr] removexattr [X fremovexattr] setxattr [X fsetxattr] stat [- fstat] statvfs [- fstatvfs] utime [X futimes futimens] _______________________________________ remove_dir=bool (default False) Allows unlink to behave like rmdir. unlink [X unlinkat] [- rmdir] _______________________________________ One question: If we do as I propose, and dir_fd is always a parameter to a pre-existing function, can we drop support for AT_FDCWD? It seems to me that funlink("../foo", dir_fd=AT_FDCWD) is equivalent to unlink("../foo") but I fear I'm missing something important. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 12:56:51 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 28 Apr 2012 10:56:51 +0000 Subject: [issue14369] make __closure__ writable In-Reply-To: <1332179477.04.0.11685261564.issue14369@psf.upfronthosting.co.za> Message-ID: <1335610611.07.0.631058783474.issue14369@psf.upfronthosting.co.za> Andrew Svetlov added the comment: sbt, looks good for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 14:19:03 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 28 Apr 2012 12:19:03 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1335615543.36.0.187743331933.issue13916@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I fail to see the problem. If the error handler does not produce meaningful results in some context, then just don't use it. The whole point of error handlers is that they handle errors; using them shouldn't ever cause errors/exceptions. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 14:27:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 28 Apr 2012 12:27:08 +0000 Subject: [issue14689] make PYTHONWARNINGS variable work in libpython In-Reply-To: <1335606965.58.0.412104204254.issue14689@psf.upfronthosting.co.za> Message-ID: <1335616028.47.0.483892285906.issue14689@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brett.cannon stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 16:00:50 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sat, 28 Apr 2012 14:00:50 +0000 Subject: [issue14675] make distutils.ccompiler.CCompiler an abstract class In-Reply-To: <1335451065.7.0.113076491662.issue14675@psf.upfronthosting.co.za> Message-ID: <1335621650.87.0.8544202415.issue14675@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Well, there is no practical advantage at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 16:01:46 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sat, 28 Apr 2012 14:01:46 +0000 Subject: [issue14675] make distutils.ccompiler.CCompiler an abstract class In-Reply-To: <1335451065.7.0.113076491662.issue14675@psf.upfronthosting.co.za> Message-ID: <1335621706.06.0.560622414041.issue14675@psf.upfronthosting.co.za> Ramchandra Apte added the comment: Please change the priorty of this bug to low. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 16:20:37 2012 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 28 Apr 2012 14:20:37 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1332785811.84.0.616508221107.issue14417@psf.upfronthosting.co.za> Message-ID: <1335622837.08.0.655659966475.issue14417@psf.upfronthosting.co.za> Guido van Rossum added the comment: Still no progress on this bug. Should I just check in my simple patch? But there's much more to do -- docs, and unittests. Volunteers? It's not hard, just work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 16:32:16 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 28 Apr 2012 14:32:16 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1335622837.08.0.655659966475.issue14417@psf.upfronthosting.co.za> Message-ID: <1335623442.3336.1.camel@localhost.localdomain> Antoine Pitrou added the comment: > Still no progress on this bug. Should I just check in my simple patch? > But there's much more to do -- docs, and unittests. Volunteers? It's > not hard, just work. Well, in general the person writing the patch should also write the tests ;-) I have this bug in my bookmarks somewhere, so I might come to it and write a patch if nobody does it before, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 16:36:54 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Apr 2012 14:36:54 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1335623814.43.0.997794771221.issue13916@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The problem is that "surrogatepass" specific to utf-8 and there is no standard way to decode alone surrogates in utf-16. >>> "\udc80\udc80".encode("utf-16", "surrogatepass").decode("utf-16", "surrogatepass") Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'utf16' codec can't decode bytes in position 2-3: illegal encoding With utf-32 this "works" only thanks to the bug -- utf-32 allows alone surrogates (issue #12892). If the "surrogatepass" worked with utf-16 and utf-32, it would be natural to throw ValueError for other encodings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 16:36:58 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 28 Apr 2012 14:36:58 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1335623818.77.0.154695484961.issue14626@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 16:38:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 28 Apr 2012 14:38:48 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335308517.69.0.701803893151.issue14666@psf.upfronthosting.co.za> Message-ID: <1335623928.75.0.156220231957.issue14666@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This should have fixed it. If now, someone reopen the issue :) ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 16:40:25 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 28 Apr 2012 14:40:25 +0000 Subject: [issue14689] make PYTHONWARNINGS variable work in libpython In-Reply-To: <1335606965.58.0.412104204254.issue14689@psf.upfronthosting.co.za> Message-ID: <1335624025.73.0.0284004941323.issue14689@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 18:36:56 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 28 Apr 2012 16:36:56 +0000 Subject: [issue14675] make distutils.ccompiler.CCompiler an abstract class In-Reply-To: <1335451065.7.0.113076491662.issue14675@psf.upfronthosting.co.za> Message-ID: <1335631016.52.0.480636154162.issue14675@psf.upfronthosting.co.za> ?ric Araujo added the comment: Well, if there is no reason for this change, it should be closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 19:09:38 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 28 Apr 2012 17:09:38 +0000 Subject: [issue13916] disallow the "surrogatepass" handler for non utf-* encodings In-Reply-To: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za> Message-ID: <1335632978.32.0.315657330558.issue13916@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I see. The proper reaction for a codec that can't handle a certain error then is to raise the original exception. I'm -1 on raising LookupError when trying to find the error handler - this would suggest that the error handler does not exist, which is not true. As for simplifying the implementation: it might be reasonable to special-case surrogatepass inside the individual codecs, rather than looking up the error handler. Then the error handler could just be identical to "strict", except that UTF-8, UTF-16, and UTF-32 individually special-case this error handler in their encoders and decoders. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 19:19:26 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Apr 2012 17:19:26 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: <1335633566.48.0.585547717191.issue14687@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I see sped up +10% on Intel Atom (but 3.2 still 2x fast). With non-ascii arguments speed up can be a little bit larger. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 19:43:26 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 28 Apr 2012 17:43:26 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1335635006.16.0.515061626541.issue14304@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The patch is incorrect, i.e. it deviates from what the command line interface does. When you try to write to sys.stdout, and the characters are not supported you get UnicodeError. Only when it is interactive mode, and tries to represent some result, ascii escaping happens. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 20:32:33 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Apr 2012 18:32:33 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1335637953.25.0.162969191105.issue14304@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't see what the patch worse than the current behavior. Unpatched: >>> ''.join(map(chr, [76, 246, 119, 105, 115])) 'L?wis' >>> ''.join(map(chr, [76, 246, 119, 105, 115, 65536])) 'L\xf6wis\U00010000' Patched: >>> ''.join(map(chr, [76, 246, 119, 105, 115])) 'L?wis' >>> ''.join(map(chr, [76, 246, 119, 105, 115, 65536])) 'L?wis\U00010000' In the case of the Cyrillic alphabet all text becomes unreadable, if there are some non-bmp characters in it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 21:29:43 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Apr 2012 19:29:43 +0000 Subject: [issue9239] zipfile: truncating comment can corrupt the zipfile In-Reply-To: <1278979006.42.0.00730549521889.issue9239@psf.upfronthosting.co.za> Message-ID: <1335641383.11.0.0861511129337.issue9239@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The bug is no longer there. Probably it is fixed in issue14399. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 21:44:57 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Apr 2012 19:44:57 +0000 Subject: [issue1760357] ZipFile.write fails with bad modification time Message-ID: <1335642297.43.0.200429085635.issue1760357@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: An alternative is to use the current time, as for stdin. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 21:56:06 2012 From: report at bugs.python.org (Michal Nowikowski) Date: Sat, 28 Apr 2012 19:56:06 +0000 Subject: [issue14427] urllib.request.Request get_header and header_items not documented In-Reply-To: <1332875424.01.0.0659150950753.issue14427@psf.upfronthosting.co.za> Message-ID: <1335642966.19.0.468213686044.issue14427@psf.upfronthosting.co.za> Michal Nowikowski added the comment: Attached a patch that adds description of get_header and header_items methods in Doc/library/urllib.request.rst. ---------- keywords: +patch nosy: +godfryd Added file: http://bugs.python.org/file25391/doc-urlib-request.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 22:10:55 2012 From: report at bugs.python.org (Michal Nowikowski) Date: Sat, 28 Apr 2012 20:10:55 +0000 Subject: [issue13050] RLock support the context manager protocol but this is not documented In-Reply-To: <1318172715.77.0.360303466185.issue13050@psf.upfronthosting.co.za> Message-ID: <1335643855.7.0.342443907342.issue13050@psf.upfronthosting.co.za> Michal Nowikowski added the comment: It looks that it is already documented by 76228:2040842626ba changeset. The bug can be closed. ---------- nosy: +godfryd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 22:16:20 2012 From: report at bugs.python.org (Michal Nowikowski) Date: Sat, 28 Apr 2012 20:16:20 +0000 Subject: [issue14688] Typos in sorting.rst In-Reply-To: <1335605311.94.0.280572266619.issue14688@psf.upfronthosting.co.za> Message-ID: <1335644180.74.0.450345017109.issue14688@psf.upfronthosting.co.za> Michal Nowikowski added the comment: The changes looks ok. ---------- nosy: +godfryd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 22:33:54 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 28 Apr 2012 20:33:54 +0000 Subject: [issue14666] test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread In-Reply-To: <1335623928.75.0.156220231957.issue14666@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > This should have fixed it. If now, someone reopen the issue :) Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 22:34:28 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 28 Apr 2012 20:34:28 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1335637953.25.0.162969191105.issue14304@psf.upfronthosting.co.za> Message-ID: <20120428223427.Horde.1l5Fd9jz9kRPnFRTszUk4hA@webmail.df.eu> Martin v. L?wis added the comment: > In the case of the Cyrillic alphabet all text becomes unreadable, if > there are some non-bmp characters in it. And indeed, that's the correct, desired behavior, as it models what the interactive shell does. If you want to change this, you need to also change the interactive console, which is an issue independent of this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 22:38:46 2012 From: report at bugs.python.org (Michal Nowikowski) Date: Sat, 28 Apr 2012 20:38:46 +0000 Subject: [issue14570] Document json "sort_keys" parameter properly In-Reply-To: <1334284947.71.0.88941407788.issue14570@psf.upfronthosting.co.za> Message-ID: <1335645526.65.0.0444021981683.issue14570@psf.upfronthosting.co.za> Michal Nowikowski added the comment: In json module there are dump/dumps methods which internally instantiate encoder class JSONEncoder (or some other user-defined encoder clas). They look as follows: json.dump(obj, fp, skipkeys=False, ensure_ascii=True, check_circular=True, allow_nan=True, cls=None, indent=None, separators=None, default=None, **kw) json.JSONEncoder(skipkeys=False, ensure_ascii=True, check_circular=True, allow_nan=True, sort_keys=False, indent=None, separators=None, default=None) Some of dump/dumps arguments are passed to encoder class: - skipkeys - ensure_ascii - check_circular - allow_nan - indent - separators - default And it looks that sort_keys is just missing in keyword args in dump/dumps method. But it still can be passed implicitly using **kw arg. I would propose to do: - add explicitly sort_keys keyword arg to dump/dumps methods - add passing it to encoder class - and adjust documentation accordingly. ---------- nosy: +godfryd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 22:57:40 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 28 Apr 2012 20:57:40 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1335646660.06.0.263106902138.issue9260@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, here is a draft patch for the new importlib. Several issues with this patch: - introduces a pure Python function (_lock_unlock_module) on the fast import path - synchronization issues due to interruptibility of pure Python code (see _ModuleLock.acquire) - afterfork fix-up necessary - relies on _thread.RLock for bootstrapping reasons - module locks are immortal ---------- Added file: http://bugs.python.org/file25392/module_locks.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 22:58:21 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 28 Apr 2012 20:58:21 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1335646701.71.0.353294241736.issue14304@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I take that back; the interactive shell uses the backslashescape error handler. Still, I don't think IDLE should setup a displayhook in the first place. What if an application replaces the displayhook? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 23:06:50 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 28 Apr 2012 21:06:50 +0000 Subject: [issue14688] Typos in sorting.rst In-Reply-To: <1335605311.94.0.280572266619.issue14688@psf.upfronthosting.co.za> Message-ID: <1335647210.78.0.454212361896.issue14688@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The first and last change looks fine. ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 23:39:22 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Apr 2012 21:39:22 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1335646701.71.0.353294241736.issue14304@psf.upfronthosting.co.za> Message-ID: <1335649312.1557.13.camel@raxxla> Serhiy Storchaka added the comment: > Still, I don't think IDLE should setup a displayhook in the first place. What if an application replaces the displayhook? IDLE *is* the application. If another application that uses the idlelib, replace displayhook, it must itself to worry about the correct encoding and escaping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 28 23:57:54 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Apr 2012 21:57:54 +0000 Subject: [issue1739648] zipfile.testzip() using progressive file reads Message-ID: <1335650274.87.0.834609481714.issue1739648@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 00:07:05 2012 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 28 Apr 2012 22:07:05 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1335650825.24.0.968398225772.issue14304@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Serhiy, I like to fix tkinter itself, not only IDLE. There are other problems like idle is crashing if non-bmp char will be pasted from clipboard. Moreover, non-bmp behavior is different from one Tk widget to other. I still want to make codec for it and then try to solve tk problems. Maybe solution will force to extend tkinter interface for process codec errors with reasonable well specified default behavior. Sorry for my silence. I hope to make some progress next weeks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 00:30:47 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 28 Apr 2012 22:30:47 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1335649312.1557.13.camel@raxxla> Message-ID: <20120429003046.Horde.PQtjbruWis5PnG_WblZhAlA@webmail.df.eu> Martin v. L?wis added the comment: > IDLE *is* the application. No, IDLE is the development environment. The application is whatever is being developed with IDLE. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 00:51:13 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Apr 2012 22:51:13 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1335653473.07.0.951490052574.issue14304@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't understand how the utf-8-bmp codec will help to fix the tkinter. To fix the tkinter, you need to fix the Tcl/Tk, but it is outside of Python. While Tcl does not support non-bmp characters, correct and non-ambiguous working with non-bmp characters is not possible. You should choose the method of encoding of non-bmp characters and these methods will be different for different applications. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 01:04:53 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 28 Apr 2012 23:04:53 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <20120429003046.Horde.PQtjbruWis5PnG_WblZhAlA@webmail.df.eu> Message-ID: <1335654445.1557.17.camel@raxxla> Serhiy Storchaka added the comment: > No, IDLE is the development environment. The application is > whatever is being developed with IDLE. If the application replaces the displayhook, than it is the development environment too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 01:04:58 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 28 Apr 2012 23:04:58 +0000 Subject: [issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) In-Reply-To: <1319226560.18.0.474501275115.issue13241@psf.upfronthosting.co.za> Message-ID: <1335654298.97.0.469247077935.issue13241@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 01:05:00 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 28 Apr 2012 23:05:00 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1335654300.65.0.0172333809273.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file25393/4ba64ca9abcf.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 01:17:01 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 28 Apr 2012 23:17:01 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1335655021.75.0.363297712684.issue9260@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New patch gets rid of the reliance on _thread.RLock (uses non-recursive locks instead), and should solve the synchronization issue. Other issues remain. ---------- Added file: http://bugs.python.org/file25394/module_locks2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 01:23:45 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sat, 28 Apr 2012 23:23:45 +0000 Subject: [issue7707] multiprocess.Queue operations during import can lead to deadlocks In-Reply-To: <1263573315.16.0.465636049394.issue7707@psf.upfronthosting.co.za> Message-ID: <1335655425.09.0.55447767964.issue7707@psf.upfronthosting.co.za> Hynek Schlawack added the comment: The proposed patch has been committed as c4dcbe51c2e3 ? any reasons why this issues is still open? ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 01:29:12 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 28 Apr 2012 23:29:12 +0000 Subject: [issue7707] multiprocess.Queue operations during import can lead to deadlocks In-Reply-To: <1263573315.16.0.465636049394.issue7707@psf.upfronthosting.co.za> Message-ID: <1335655752.98.0.641971928182.issue7707@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- components: +Documentation -Library (Lib) resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 01:35:13 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 28 Apr 2012 23:35:13 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1335656113.92.0.0133047128195.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25393/4ba64ca9abcf.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 01:35:35 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 28 Apr 2012 23:35:35 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1335656135.46.0.779148543892.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file25395/9a93348e98e7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 01:36:26 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 28 Apr 2012 23:36:26 +0000 Subject: [issue14427] urllib.request.Request get_header and header_items not documented In-Reply-To: <1332875424.01.0.0659150950753.issue14427@psf.upfronthosting.co.za> Message-ID: <1335656186.36.0.380968256283.issue14427@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- assignee: docs at python -> orsenthil nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 01:50:43 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 28 Apr 2012 23:50:43 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1335657043.58.0.906769192075.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25395/9a93348e98e7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 01:50:49 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 28 Apr 2012 23:50:49 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1335657049.14.0.413107495984.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file25254/384190bb0bd5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 01:51:07 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 28 Apr 2012 23:51:07 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1335657067.27.0.846529814333.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file25396/667541bb315c.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 01:51:56 2012 From: report at bugs.python.org (STINNER Victor) Date: Sat, 28 Apr 2012 23:51:56 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1335657116.98.0.854361541598.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: 667541bb315c.diff: Updated patch, last change: is_adjusted key of time.get_clock_info() is now mandatory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 02:14:34 2012 From: report at bugs.python.org (Alan McIntyre) Date: Sun, 29 Apr 2012 00:14:34 +0000 Subject: [issue1739648] zipfile.testzip() using progressive file reads Message-ID: <1335658474.43.0.87062348793.issue1739648@psf.upfronthosting.co.za> Alan McIntyre added the comment: I'd be glad to do some code reviews or something in exchange for the time of somebody with commit rights. :-) If anybody is interested in getting this change committed, please let me know and I'll check that the patch is still valid. Thanks! ---------- status: open -> languishing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 02:28:30 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 29 Apr 2012 00:28:30 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1335659310.27.0.656638014935.issue14428@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file25397/4255e3c4daf2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 02:44:14 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 00:44:14 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 76d2e0761d18 by Victor Stinner in branch 'default': Issue #14428, #14397: Implement the PEP 418 http://hg.python.org/cpython/rev/76d2e0761d18 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 02:44:14 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 00:44:14 +0000 Subject: [issue14397] Use GetTickCount/GetTickCount64 instead of QueryPerformanceCounter for monotonic clock In-Reply-To: <1332585881.7.0.0863389959921.issue14397@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 76d2e0761d18 by Victor Stinner in branch 'default': Issue #14428, #14397: Implement the PEP 418 http://hg.python.org/cpython/rev/76d2e0761d18 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 02:45:21 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 29 Apr 2012 00:45:21 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1335660321.83.0.478824737617.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: Guido van Rossum accepted the PEP, let's commit the implementation. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 02:53:43 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 00:53:43 +0000 Subject: [issue14309] Deprecate time.clock() In-Reply-To: <1331772722.48.0.0484604711161.issue14309@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 314c3faea2fb by Victor Stinner in branch 'default': Close #14309: Deprecate time.clock() http://hg.python.org/cpython/rev/314c3faea2fb ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 02:54:23 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 29 Apr 2012 00:54:23 +0000 Subject: [issue14309] Deprecate time.clock() In-Reply-To: <1331772722.48.0.0484604711161.issue14309@psf.upfronthosting.co.za> Message-ID: <1335660863.56.0.473047815577.issue14309@psf.upfronthosting.co.za> STINNER Victor added the comment: The PEP 418 has been accepted: read it to understand why time.clock() is now deprecated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 02:55:11 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 29 Apr 2012 00:55:11 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1335660911.18.0.518383478117.issue9260@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch fixes the performance issue and disposes of module locks when they aren't used anymore. Only the afterfork question remains. Should I hook in threading's own facility? Should we wait for an atfork module? Something else. ---------- Added file: http://bugs.python.org/file25398/module_locks3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 02:57:35 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 29 Apr 2012 00:57:35 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1335661055.59.0.530410048975.issue9260@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file25398/module_locks3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 03:00:06 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 29 Apr 2012 01:00:06 +0000 Subject: [issue9260] A finer grained import lock In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za> Message-ID: <1335661206.49.0.656311401404.issue9260@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Added file: http://bugs.python.org/file25399/module_locks3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 03:04:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 01:04:18 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset bd195749c0a2 by Victor Stinner in branch 'default': Issue #14428: Use the new time.perf_counter() and time.process_time() functions http://hg.python.org/cpython/rev/bd195749c0a2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 03:18:54 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 29 Apr 2012 01:18:54 +0000 Subject: [issue14690] Use monotonic time for sched, trace and subprocess modules Message-ID: <1335662334.09.0.251528208694.issue14690@psf.upfronthosting.co.za> New submission from STINNER Victor : The PEP 418 added a new time.monotonic() function. The sched, trace and subprocess modules should use it, if available, to avoid issues when the system time is changed. Attached patch uses the time.monotonic() function when available. See also the issue #14222 (same issue for queue and threading) and the PEP 418. -- socket and ssl modules should also use a monotonic clock if available, but these modules are implemented in C. The C implementation of time.monotonic() requires the librt library and is written in the timemodule.c. It requires more work to reuse it in the socket and ssl modules. ---------- files: use_monotonic.patch keywords: patch messages: 159559 nosy: haypo, neologix, rhettinger priority: normal severity: normal status: open title: Use monotonic time for sched, trace and subprocess modules Added file: http://bugs.python.org/file25400/use_monotonic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 03:22:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 29 Apr 2012 01:22:46 +0000 Subject: [issue14690] Use monotonic time for sched, trace and subprocess modules In-Reply-To: <1335662334.09.0.251528208694.issue14690@psf.upfronthosting.co.za> Message-ID: <1335662566.38.0.549799294084.issue14690@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 03:27:20 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 29 Apr 2012 01:27:20 +0000 Subject: [issue14690] Use monotonic time for sched, trace and subprocess modules In-Reply-To: <1335662334.09.0.251528208694.issue14690@psf.upfronthosting.co.za> Message-ID: <1335662840.63.0.283594838464.issue14690@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 03:53:29 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 01:53:29 +0000 Subject: [issue14155] Deja vu in re's documentation In-Reply-To: <1330481540.05.0.869825762197.issue14155@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 142297db28f1 by Ezio Melotti in branch '2.7': #14155: add a note about \b. http://hg.python.org/cpython/rev/142297db28f1 New changeset f4b167309bee by Ezio Melotti in branch '3.2': #14155: add a note about \b. http://hg.python.org/cpython/rev/f4b167309bee New changeset b1f29667a3c7 by Ezio Melotti in branch 'default': #14155: merge note about \b from 3.2. http://hg.python.org/cpython/rev/b1f29667a3c7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 03:55:19 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 01:55:19 +0000 Subject: [issue14155] Deja vu in re's documentation In-Reply-To: <1330481540.05.0.869825762197.issue14155@psf.upfronthosting.co.za> Message-ID: <1335664519.62.0.782281772599.issue14155@psf.upfronthosting.co.za> Ezio Melotti added the comment: I added a note about \b. I don't think the duplicate description of the octal escapes is a problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 04:03:51 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 02:03:51 +0000 Subject: [issue11379] Remove "lightweight" from minidom description In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za> Message-ID: <1335665031.72.0.551298264529.issue11379@psf.upfronthosting.co.za> Ezio Melotti added the comment: Any news on this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 04:08:17 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 02:08:17 +0000 Subject: [issue14009] Clearer documentation for cElementTree In-Reply-To: <1329233203.38.0.944311933185.issue14009@psf.upfronthosting.co.za> Message-ID: <1335665297.16.0.216128890621.issue14009@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 04:21:50 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 02:21:50 +0000 Subject: [issue13684] httplib tunnel infinite loop In-Reply-To: <1325260587.05.0.642107056326.issue13684@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 685c1db976c4 by Senthil Kumaran in branch '2.7': httplib test for early eof response. related to Issue13684 http://hg.python.org/cpython/rev/685c1db976c4 New changeset afabb0635b15 by Senthil Kumaran in branch '3.2': httplib test for early eof response. related to Issue13684 http://hg.python.org/cpython/rev/afabb0635b15 New changeset cfff6a53f4a3 by Senthil Kumaran in branch 'default': httplib test for early eof response. related to Issue13684 http://hg.python.org/cpython/rev/cfff6a53f4a3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 04:26:01 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 29 Apr 2012 02:26:01 +0000 Subject: [issue13684] httplib tunnel infinite loop In-Reply-To: <1325260587.05.0.642107056326.issue13684@psf.upfronthosting.co.za> Message-ID: <1335666361.1.0.437812026379.issue13684@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I added a simple test for the early eof condition. It is not specific under _tunnel. I find that Mocks yet to be written that cover the response from httplib ( the mocks in the tests -httplib,urllib2), have their own overridden read() method which may not cover this scenario). The early eof test may be helpful to some extent as general test case. I am closing this bug report as fix has been covered. ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 04:38:35 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 02:38:35 +0000 Subject: [issue13850] Summary tables for argparse add_argument options In-Reply-To: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za> Message-ID: <1335667115.93.0.00534388114674.issue13850@psf.upfronthosting.co.za> Ezio Melotti added the comment: > * It's incredibly not helpful for people who don't know argparse Indeed. Maybe this should be moved down in the page, and possibly provide a link to the top (see e.g. the unittest doc [0] and the link on top to jump to the list of assert methods). Once people know it's there they will find it easily, but opening the doc with this table is a bit confusing IMHO. Adding a couple of line to explain what the table is for might also help. > * I tried adding effects descriptions in the cells instead of mere > tick marks, the table becomes completely unreadable. In the rst source only latin-1 chars are allowed (otherwise `make pdf` breaks), so you should replace the tick marks with something else (e.g. "x" or "yes"/"no"). > I added a note directive below the table but it only lists a few > really important/weird things, and it really won't scale beyond the > current 3 items (which might already be too much) You can also add notes numbers just next to the "x"s and add a description below [1]. This could be applied to the "const" column as well if you want to save some horizontal space. If you want to save even more space you could remove the version row/column and add a note about it. > * I completely removed the ``help`` action from the table as it's > unlikely anyone will want to override it (and its row was completely blank) Maybe you could add a note about this too. > * Hyperlinking and cross-linking (to the params, the actions, > footnotes) would probably be a good idea, although it would > definitely make the "raw text" (in-rst) This might be useful (I did it in the assert methods' tables in the unittest doc [0]), and having links in the HTML probably outweighs the fact that the rst source becomes less readable. Note that (depending on what you change), you might be able to use the lightweight syntax for tables if you prefer. [0]: http://docs.python.org/library/unittest.html [1]: e.g. http://docs.python.org/library/stdtypes.html#numeric-types-int-float-long-complex ---------- stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 05:53:22 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 03:53:22 +0000 Subject: [issue14427] urllib.request.Request get_header and header_items not documented In-Reply-To: <1332875424.01.0.0659150950753.issue14427@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 6a9f100e138c by Senthil Kumaran in branch '3.2': issue14427 - Document Request.get_header and Request.header_items http://hg.python.org/cpython/rev/6a9f100e138c New changeset 261de1701343 by Senthil Kumaran in branch 'default': issue14427 - Document Request.get_header and Request.header_items http://hg.python.org/cpython/rev/261de1701343 New changeset 9a1f525b98d9 by Senthil Kumaran in branch '2.7': issue14427 - Document Request.get_header and Request.header_items http://hg.python.org/cpython/rev/9a1f525b98d9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 05:54:16 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 29 Apr 2012 03:54:16 +0000 Subject: [issue14427] urllib.request.Request get_header and header_items not documented In-Reply-To: <1332875424.01.0.0659150950753.issue14427@psf.upfronthosting.co.za> Message-ID: <1335671656.78.0.88484885777.issue14427@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Just documented it. Surprising that it was not already! :( ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 05:58:18 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 03:58:18 +0000 Subject: [issue14034] Add argparse howto In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za> Message-ID: <1335671898.97.0.0289197934988.issue14034@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Would be nice to get another review. I left several comments on rietveld. Overall the tutorial seems really nice and easy to follow (except a couple of parts, noted in the comments). I would replace all the uses of pow(x, y) with x**y in the code, and possibly with x^y in the output/descriptions (x**y is probably fine there too). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 06:19:00 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 29 Apr 2012 04:19:00 +0000 Subject: [issue11379] Remove "lightweight" from minidom description In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za> Message-ID: <1335673140.35.0.707327756203.issue11379@psf.upfronthosting.co.za> ?ric Araujo added the comment: I?ve been unresponsive of late, sorry, but I?m still here. Will see if I have time tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 06:21:33 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 04:21:33 +0000 Subject: [issue14034] Add argparse howto In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za> Message-ID: <1335673293.49.0.412663048682.issue14034@psf.upfronthosting.co.za> Ezio Melotti added the comment: A few more comments: * in the review I mentioned highlighting specific code lines (this would be really great given the incremental nature of the howto), but apparently that requires a pygment 1.1 [0]. * all the output examples could use ".. highlightlang:: sh", but: 1. the sh highlighter is not so good imho; 2. you would have to switch back and forth from sh and python (unless there's a better way to do it); * the sidebar box with the tutorial looks better if you put it between the

and the introductory paragraph. Maybe Georg has something to say about the first two comments. [0]: see last example in http://sphinx.pocoo.org/markup/code.html#line-numbers ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 06:35:39 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 04:35:39 +0000 Subject: [issue14461] In re's positive lookbehind assertion documentation match() cannot match In-Reply-To: <1333267920.68.0.0890741084259.issue14461@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 7c262962b681 by Ezio Melotti in branch '2.7': #14461: fix wording. http://hg.python.org/cpython/rev/7c262962b681 New changeset 7f35da912739 by Ezio Melotti in branch '3.2': #14461: fix wording. http://hg.python.org/cpython/rev/7f35da912739 New changeset d68b4885fc0f by Ezio Melotti in branch 'default': #14461: merge with 3.2. http://hg.python.org/cpython/rev/d68b4885fc0f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 06:40:16 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 04:40:16 +0000 Subject: [issue14461] In re's positive lookbehind assertion documentation match() cannot match In-Reply-To: <1333267920.68.0.0890741084259.issue14461@psf.upfronthosting.co.za> Message-ID: <1335674416.6.0.211378204394.issue14461@psf.upfronthosting.co.za> Ezio Melotti added the comment: Technically you are correct, however using zero-width classes inside a lookbehind doesn't make much sense, because the result would be equivalent even without lookbehind. I replaced 'never' with 'not', because usually it will not match, except in these corner cases that can IMHO be ignored. ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 06:52:18 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 04:52:18 +0000 Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes lag In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 64a6824d129d by Senthil Kumaran in branch 'default': Fix Issue6085 - SimpleHTTPServer address_string to return client ip instead of client hostname http://hg.python.org/cpython/rev/64a6824d129d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 06:54:16 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 04:54:16 +0000 Subject: [issue14462] In re's named group the name cannot contain unicode characters In-Reply-To: <1333268208.65.0.802050679023.issue14462@psf.upfronthosting.co.za> Message-ID: <1335675256.73.0.663825304266.issue14462@psf.upfronthosting.co.za> Ezio Melotti added the comment: There are two options here: 1. fix the doc; 2. fix the code; Matthew, do you have any opinion on this? Does this work on regex? ---------- stage: -> needs patch type: behavior -> enhancement versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 07:10:06 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 05:10:06 +0000 Subject: [issue14405] Some "Other Resources" in the sidebar are hopelessly out of date In-Reply-To: <1332696210.48.0.175266420412.issue14405@psf.upfronthosting.co.za> Message-ID: <1335676206.31.0.183244910924.issue14405@psf.upfronthosting.co.za> Ezio Melotti added the comment: Here's a patch that removes a few links: * FAQs: the link is already in the page; * Guido's Essays: the content is outdated; * New-style Classes: the content is outdated; * Other Doc Collections: link is broken; * Report a Bug: the link is already in the page; Someone should also update the pages about New-style Classes and Guido's Essays. ---------- assignee: docs at python -> ezio.melotti keywords: +patch nosy: +eric.araujo, georg.brandl stage: -> patch review type: -> enhancement versions: +Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25401/issue14405.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 07:17:35 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 05:17:35 +0000 Subject: [issue14244] No information about behaviour with groups in pattern in the docstring for re.split In-Reply-To: <1331348902.51.0.968875082813.issue14244@psf.upfronthosting.co.za> Message-ID: <1335676655.29.0.0974350411749.issue14244@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> committed/rejected type: -> enhancement versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 07:24:11 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 05:24:11 +0000 Subject: =?utf-8?q?=5Bissue14236=5D_re=3A_Docstring_for_=5Cs_and_=5CS_doesn?= =?utf-8?q?=E2=80=99t_mention_Unicode?= In-Reply-To: <1331273217.26.0.527770128505.issue14236@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset da9179248118 by Ezio Melotti in branch '3.2': #14236: mention Unicode whitespace in \s documentation. http://hg.python.org/cpython/rev/da9179248118 New changeset db39b9513e71 by Ezio Melotti in branch 'default': #14236: merge with 3.2. http://hg.python.org/cpython/rev/db39b9513e71 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 07:24:59 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 05:24:59 +0000 Subject: =?utf-8?q?=5Bissue14236=5D_re=3A_Docstring_for_=5Cs_and_=5CS_doesn?= =?utf-8?q?=E2=80=99t_mention_Unicode?= In-Reply-To: <1331273217.26.0.527770128505.issue14236@psf.upfronthosting.co.za> Message-ID: <1335677099.85.0.368783115889.issue14236@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report! ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 07:26:27 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 29 Apr 2012 05:26:27 +0000 Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes lag In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za> Message-ID: <1335677187.79.0.538737502082.issue6085@psf.upfronthosting.co.za> Senthil Kumaran added the comment: The original change was introduced in this issue401197 which seems to use fqdn at *all appropriate places*. In this case, after about a decade, it was realized that using fdqn for client connection may not be appropriate when hostname is not set. In 3.3, this is fixed by making address_string return client ip instead of client hostname. In 2.7 and 3.2, I would like to see it fixed wherein, inside the log_message call, the address_string is not called instead direct client address is used. In this manner, we are not changing any return values of public api (address_string), but we are effectively eliminating the delay cased by fqdn looking while logging to sys.stderr. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 07:44:35 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 05:44:35 +0000 Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes lag In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset fb1e71c7619a by Senthil Kumaran in branch '2.7': Fix issue6085 - Remove the delay caused by fqdn lookup while logging in BaseHTTPRequestHandler http://hg.python.org/cpython/rev/fb1e71c7619a New changeset 6adad27fcc8c by Senthil Kumaran in branch '3.2': Fix issue6085 - Remove the delay caused by fqdn lookup while logging in BaseHTTPRequestHandler http://hg.python.org/cpython/rev/6adad27fcc8c New changeset f9f11998a20d by Senthil Kumaran in branch 'default': issue6085 - update docs in default branch http://hg.python.org/cpython/rev/f9f11998a20d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 07:45:26 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 29 Apr 2012 05:45:26 +0000 Subject: [issue6085] Logging in BaseHTTPServer.BaseHTTPRequestHandler causes lag In-Reply-To: <1242987160.68.0.883140966896.issue6085@psf.upfronthosting.co.za> Message-ID: <1335678326.62.0.104464272974.issue6085@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Fixed in all codelines. Closing this. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 07:46:02 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 05:46:02 +0000 Subject: [issue14468] Update cloning guidelines in devguide In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za> Message-ID: <1335678362.51.0.714217788923.issue14468@psf.upfronthosting.co.za> Ezio Melotti added the comment: Are you referring to http://docs.python.org/devguide/committing.html#forward-porting ? ---------- stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 07:52:57 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 29 Apr 2012 05:52:57 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1335650825.24.0.968398225772.issue14304@psf.upfronthosting.co.za> Message-ID: <1335678928.4263.7.camel@raxxla> Serhiy Storchaka added the comment: Andrew, imagine that the utf-8-bmp codec is already there (I will do it for you, if I see its necessity). How are you going to use it? Show a patch that fixes IDLE and tkinter using this codec. It seems to me that any result can be achieved without the codec, and not higher cost. And that's not counting cost of the codec itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 08:37:03 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 29 Apr 2012 06:37:03 +0000 Subject: [issue1739648] zipfile.testzip() using progressive file reads Message-ID: <1335681423.03.0.756706382431.issue1739648@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm not sure about new tests, but the changes in the docstring and old tests look necessary. ---------- Added file: http://bugs.python.org/file25402/testzip-patch4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 08:44:54 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 29 Apr 2012 06:44:54 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1331810146.14.0.995585507713.issue14315@psf.upfronthosting.co.za> Message-ID: <1335681894.6.0.115908307705.issue14315@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Anyone can look at the patch? This same problem reported in http://bugs.python.org/msg73317 . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 10:24:13 2012 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 29 Apr 2012 08:24:13 +0000 Subject: [issue14657] Avoid two importlib copies In-Reply-To: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za> Message-ID: <1335687853.57.0.312121235577.issue14657@psf.upfronthosting.co.za> Nick Coghlan added the comment: Uploaded new bootstrapping patch that handles the fully explicit import machinery. I also tweaked a couple of things so it plays nicely in terms of building an initial version with the checked in importlib.h. Specifically: pythonrun still calls _frozen_importlib._install and can tolerate that function returning None. Longer term, we'd give the two hooks different names and returning None will become a fatal error, but for the moment, the current behaviour makes the patch much easier to work with. Order is still wrong relative to the zipimport machinery and I haven't benchmarked the startup time overheads. ---------- Added file: http://bugs.python.org/file25403/issue14657_bootstrap_from_disk_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 10:25:50 2012 From: report at bugs.python.org (py.user) Date: Sun, 29 Apr 2012 08:25:50 +0000 Subject: =?utf-8?q?=5Bissue14236=5D_re=3A_Docstring_for_=5Cs_and_=5CS_doesn?= =?utf-8?q?=E2=80=99t_mention_Unicode?= In-Reply-To: <1331273217.26.0.527770128505.issue14236@psf.upfronthosting.co.za> Message-ID: <1335687950.93.0.357398596816.issue14236@psf.upfronthosting.co.za> py.user added the comment: \S is equivalent to [^\s] like \d with \D ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 10:28:14 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 08:28:14 +0000 Subject: [issue14558] Documentation for unittest.main does not describe some keyword arguments. In-Reply-To: <1334208375.3.0.0230518732022.issue14558@psf.upfronthosting.co.za> Message-ID: <1335688094.41.0.603102270213.issue14558@psf.upfronthosting.co.za> Ezio Melotti added the comment: Here's a patch. ---------- assignee: docs at python -> ezio.melotti keywords: +patch stage: needs patch -> commit review Added file: http://bugs.python.org/file25404/issue14558.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 10:49:04 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 08:49:04 +0000 Subject: [issue14519] In re's examples the example with scanf() contains wrong analog for %x, %X specifiers In-Reply-To: <1333757996.58.0.360922081437.issue14519@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b26471a2a115 by Ezio Melotti in branch '2.7': #14519: fix the regex used in the scanf example. http://hg.python.org/cpython/rev/b26471a2a115 New changeset e317d651ccf8 by Ezio Melotti in branch '3.2': #14519: fix the regex used in the scanf example. http://hg.python.org/cpython/rev/e317d651ccf8 New changeset 7cc1cddb378d by Ezio Melotti in branch 'default': #14519: merge with 3.2. http://hg.python.org/cpython/rev/7cc1cddb378d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 10:50:58 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 08:50:58 +0000 Subject: [issue14519] In re's examples the example with scanf() contains wrong analog for %x, %X specifiers In-Reply-To: <1333757996.58.0.360922081437.issue14519@psf.upfronthosting.co.za> Message-ID: <1335689458.75.0.178850842943.issue14519@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report and the suggestions! ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 10:57:30 2012 From: report at bugs.python.org (Ramchandra Apte) Date: Sun, 29 Apr 2012 08:57:30 +0000 Subject: [issue14691] a code example not highlighted in http://docs.python.org/dev/library/stdtypes.html#memoryview Message-ID: <1335689850.36.0.828007836138.issue14691@psf.upfronthosting.co.za> New submission from Ramchandra Apte : A code example is not highlighted in the 3.3 docs for memoryview (http://docs.python.org/dev/library/stdtypes.html#memoryview) Only 3.3 is affected by this bug as the code example is for a feature in 3.3. ---------- assignee: docs at python components: Documentation messages: 159590 nosy: docs at python, ramchandra.apte priority: normal severity: normal status: open title: a code example not highlighted in http://docs.python.org/dev/library/stdtypes.html#memoryview versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 11:02:51 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 29 Apr 2012 09:02:51 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1335690171.59.0.34599291923.issue14428@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: test_process_time_threads is failing on one of the buildbots: """ ====================================================================== FAIL: test_process_time_threads (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_time.py", line 408, in test_process_time_threads self.assertGreater(t2 - t1, 0.1) AssertionError: 0.08041412500006118 not greater than 0.1 """ The test is a bit too optimistic: a thread is looping for 0.2s, and the test checks that the process time (user + system) increased of at least 0.1s. If the thread is preempted, there's a high chance you won't get even as low as 0.1s. I see two options: either increase the total running time, to make it really likely you'll get a chance to run (or decrase the lower threshold), or use times(2), and check the result against that (does Windows have such a syscall?). ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 11:12:01 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 29 Apr 2012 09:12:01 +0000 Subject: [issue14690] Use monotonic time for sched, trace and subprocess modules In-Reply-To: <1335662334.09.0.251528208694.issue14690@psf.upfronthosting.co.za> Message-ID: <1335690721.57.0.52077841623.issue14690@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: LGTM. Juste one nitpick: why do you sometimes import the clock source as get_time() and others _time()? _time() looks fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 11:25:22 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 09:25:22 +0000 Subject: [issue12947] Examples in library/doctest.html lack the flags In-Reply-To: <1315588954.16.0.979263107509.issue12947@psf.upfronthosting.co.za> Message-ID: <1335691522.74.0.302648951002.issue12947@psf.upfronthosting.co.za> Ezio Melotti added the comment: Is there a way to add a :keep-doctest-flags: options to literal blocks? ---------- stage: test needed -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 11:41:03 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 29 Apr 2012 09:41:03 +0000 Subject: [issue6759] zipfile.ZipExtFile.read() is missing universal newline support In-Reply-To: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za> Message-ID: <1335692463.66.0.480046984199.issue6759@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Support lines in zipfile looks contradictory and buggy. This complicates the code and makes the behavior of zipfile.ZipExtFile incompatible with the interface of other file-like objects. For example, the behavior of the read, read1 and peek differ from one described in io module. If we are working with binary data, conversion of newlines is meaningless (and how about newlines in comments?). If we are working with text, the bytes must be decoded to str. This will help io.TextIOWrapper. I suggest two alternatives: 1. Deprecate universal newline support in zipfile. zipfile.ZipExtFile should always work with non-modified bytes, and who need the text, let wraps zipfile.ZipExtFile with io.TextIOWrapper. 2. Automatically wrap a zipfile.ZipExtFile with io.TextIOWrapper if universal newlines mode is enabled. In this case, the data type will change from bytes to str. Add modes "t" and "b" to explicitly specify the data type. Add an encoding parameter (and other parameters if needed). ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 12:20:22 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 29 Apr 2012 10:20:22 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1335694822.08.0.77766789768.issue11352@psf.upfronthosting.co.za> Hynek Schlawack added the comment: What is the reason for this one to languish for over a year now? Lack of proper patch? It?s marked ?high priority?, so let?s get moving. ---------- nosy: +hynek, sandro.tosi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 12:34:25 2012 From: report at bugs.python.org (Jakob Simon-Gaarde) Date: Sun, 29 Apr 2012 10:34:25 +0000 Subject: [issue14692] json.joads parse_constant callback not working anymore Message-ID: <1335695665.87.0.370023915793.issue14692@psf.upfronthosting.co.za> New submission from Jakob Simon-Gaarde : Hi It seems like the parse_constant keyword parameter for registering a callback function is no longer called in Python 2.7. http://docs.python.org/library/json.html#json.load I am using Python 2.7.3 on Ubuntu 12.04 I have created and attached a script that shows the problem. Output in Python 2.6: Met an int! Met a constant! {u'a': None, u'b': None} Output in Python 2.7: Met an int! {u'a': None, u'b': False} So parse_int callback still works btw. Best Regards Jakob Simon-Gaarde ---------- components: Extension Modules files: test_parse_constant.py messages: 159596 nosy: Jakob.Simon-Gaarde priority: normal severity: normal status: open title: json.joads parse_constant callback not working anymore type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file25405/test_parse_constant.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 12:37:18 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 10:37:18 +0000 Subject: =?utf-8?q?=5Bissue14236=5D_re=3A_Docstring_for_=5Cs_and_=5CS_doesn?= =?utf-8?q?=E2=80=99t_mention_Unicode?= In-Reply-To: <1331273217.26.0.527770128505.issue14236@psf.upfronthosting.co.za> Message-ID: <1335695838.6.0.769638222157.issue14236@psf.upfronthosting.co.za> Ezio Melotti added the comment: Good point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 12:37:26 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 10:37:26 +0000 Subject: =?utf-8?q?=5Bissue14236=5D_re=3A_Docstring_for_=5Cs_and_=5CS_doesn?= =?utf-8?q?=E2=80=99t_mention_Unicode?= In-Reply-To: <1331273217.26.0.527770128505.issue14236@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 23d5b457dc71 by Ezio Melotti in branch '3.2': #14236: fix docs for \S. http://hg.python.org/cpython/rev/23d5b457dc71 New changeset 9165774a8055 by Ezio Melotti in branch 'default': #14236: merge with 3.2. http://hg.python.org/cpython/rev/9165774a8055 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 12:38:49 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 10:38:49 +0000 Subject: [issue14692] json.joads parse_constant callback not working anymore In-Reply-To: <1335695665.87.0.370023915793.issue14692@psf.upfronthosting.co.za> Message-ID: <1335695929.37.0.53056003293.issue14692@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 13:19:05 2012 From: report at bugs.python.org (Q) Date: Sun, 29 Apr 2012 11:19:05 +0000 Subject: [issue14671] isinstance(obj, object) returns True for _old style_ class instances In-Reply-To: <1335408816.14.0.0332999907924.issue14671@psf.upfronthosting.co.za> Message-ID: <1335698345.09.0.883818961834.issue14671@psf.upfronthosting.co.za> Q added the comment: thanks, that's rather convenient ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 13:21:26 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 29 Apr 2012 11:21:26 +0000 Subject: [issue14692] json.joads parse_constant callback not working anymore In-Reply-To: <1335695665.87.0.370023915793.issue14692@psf.upfronthosting.co.za> Message-ID: <1335698486.65.0.0374740728085.issue14692@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This behavior was changed in changeset f686aced02a3 three year ago. If this change is intentional, then you need edit documentation. ---------- nosy: +storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 13:25:05 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 29 Apr 2012 11:25:05 +0000 Subject: [issue14692] json.joads parse_constant callback not working anymore In-Reply-To: <1335695665.87.0.370023915793.issue14692@psf.upfronthosting.co.za> Message-ID: <1335698705.15.0.779994702943.issue14692@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Hi Jakob, parse_constant has been changed as of d95e5add3ca4 to be called only on "-Infinity, Infinity, NaN": ``parse_constant``, if specified, will be called with one of the following strings: -Infinity, Infinity, NaN. This can be used to raise an exception if invalid JSON numbers are encountered. And indeed, if you change your example to Infinity, it gets called. That said, neither the 2.7 nor the dev docs reflect that. So it seems like a documentation bug to me. ---------- assignee: -> docs at python components: +Documentation -Extension Modules nosy: +docs at python, eric.araujo, georg.brandl, hynek versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 13:33:53 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 29 Apr 2012 11:33:53 +0000 Subject: [issue14692] json.joads parse_constant callback not working anymore In-Reply-To: <1335695665.87.0.370023915793.issue14692@psf.upfronthosting.co.za> Message-ID: <1335699233.41.0.598066525172.issue14692@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file25406/json_parse_constant_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 13:45:33 2012 From: report at bugs.python.org (Yuval Greenfield) Date: Sun, 29 Apr 2012 11:45:33 +0000 Subject: [issue14315] zipfile.ZipFile() unable to open zip File In-Reply-To: <1331810146.14.0.995585507713.issue14315@psf.upfronthosting.co.za> Message-ID: <1335699933.34.0.381560098026.issue14315@psf.upfronthosting.co.za> Yuval Greenfield added the comment: If we're modifying zipfile, please consider adding the reviewed patch for ZipFile.remove at http://bugs.python.org/issue6818 ---------- nosy: +ubershmekel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 13:56:58 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 29 Apr 2012 11:56:58 +0000 Subject: [issue10376] ZipFile unzip is unbuffered In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za> Message-ID: <1335700618.41.0.601864632044.issue10376@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Actually reading from the zip file is buffered (at least 4 KiB of uncompressed data at a time). Can you give tests, scripts and data, which show the problem? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 14:23:30 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 12:23:30 +0000 Subject: [issue14671] isinstance(obj, object) returns True for _old style_ class instances In-Reply-To: <1335408816.14.0.0332999907924.issue14671@psf.upfronthosting.co.za> Message-ID: <1335702210.44.0.412732452552.issue14671@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 14:51:25 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 12:51:25 +0000 Subject: [issue14692] json.joads parse_constant callback not working anymore In-Reply-To: <1335695665.87.0.370023915793.issue14692@psf.upfronthosting.co.za> Message-ID: <1335703885.5.0.341809233311.issue14692@psf.upfronthosting.co.za> Ezio Melotti added the comment: The original changeset is at [0], and the commit message just says "even more decoder optimizations". The official website[1] and the RFC[2] don't list any constant, so I guess the definition of what a constant is is not well defined. [0]: http://code.google.com/p/simplejson/source/detail?spec=svn103&r=103 [1]: http://www.json.org/ [2]: http://tools.ietf.org/html/rfc4627 ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 15:04:10 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 13:04:10 +0000 Subject: [issue8767] Configure: Cannot disable unicode In-Reply-To: <1274286115.56.0.588868311562.issue8767@psf.upfronthosting.co.za> Message-ID: <1335704650.18.0.563130966284.issue8767@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 15:05:44 2012 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 29 Apr 2012 13:05:44 +0000 Subject: [issue14643] Security page out of date In-Reply-To: <1335086892.52.0.709735016989.issue14643@psf.upfronthosting.co.za> Message-ID: <1335704744.4.0.842824327433.issue14643@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 15:17:56 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 29 Apr 2012 13:17:56 +0000 Subject: [issue14313] zipfile should raise an exception for unsupported compression methods In-Reply-To: <1331786135.76.0.307574406169.issue14313@psf.upfronthosting.co.za> Message-ID: <1335705476.18.0.779450373551.issue14313@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file25407/zipfile_unsupported_compression.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 15:27:34 2012 From: report at bugs.python.org (Daniel Swanson) Date: Sun, 29 Apr 2012 13:27:34 +0000 Subject: [issue14672] Windows installer: add desktop shortcut(s) In-Reply-To: <1335414011.97.0.984037154974.issue14672@psf.upfronthosting.co.za> Message-ID: <1335706054.78.0.669596596017.issue14672@psf.upfronthosting.co.za> Daniel Swanson added the comment: Never mind. I think I used the start menu to do it myself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 15:39:16 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 29 Apr 2012 13:39:16 +0000 Subject: [issue4653] Patch to fix typos in C code In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za> Message-ID: <1335706756.48.0.225302779052.issue4653@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: -mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 15:39:33 2012 From: report at bugs.python.org (Dov Feldstern) Date: Sun, 29 Apr 2012 13:39:33 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time Message-ID: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za> New submission from Dov Feldstern : Python has its own implementations of various hash functions, that can be used as fallbacks when openssl is not available. However, if openssl *is* available at build time, then these fallbacks don't get built. It would be nice if they would get built even if openssl *was* found at build time: (1) for (perceived?) licensing issues, one might choose to run without linking with openssl (see http://mail.python.org/pipermail/python-dev/2011-March/109053.html; that message requests that a bug be opened about this, but I wasn't able to find it?) (2) for "portable" builds: build onto portable or shared storage, and run on multiple machines, even if openssl happens not to be available on some of the machines. ---------- components: Build messages: 159606 nosy: dov priority: normal severity: normal status: open title: hashlib fallback modules should be built even if openssl *is* available at build time versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 15:50:08 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 29 Apr 2012 13:50:08 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time In-Reply-To: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za> Message-ID: <1335707408.35.0.42372421944.issue14693@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > that message requests that a bug be opened about this, but I wasn't able to find it? Probably because no-one opened an issue. > build onto portable or shared storage, and run on multiple machines, > even if openssl happens not to be available on some of the machines. For portable builds, I would suggest you ship OpenSSL as part of the build. ---------- nosy: +gregory.p.smith, pitrou type: -> enhancement versions: +Python 3.3 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 15:54:46 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 29 Apr 2012 13:54:46 +0000 Subject: [issue6759] zipfile.ZipExtFile.read() is missing universal newline support In-Reply-To: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za> Message-ID: <1335707686.37.0.434806067427.issue6759@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Deprecate universal newline support in zipfile. zipfile.ZipExtFile > should always work with non-modified bytes, and who need the text, let > wraps zipfile.ZipExtFile with io.TextIOWrapper. This would be fine with me. ---------- nosy: +pitrou stage: patch review -> needs patch type: behavior -> enhancement versions: +Python 3.3 -Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 15:55:32 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 29 Apr 2012 13:55:32 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time In-Reply-To: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za> Message-ID: <1335707732.76.0.349122808799.issue14693@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 16:30:16 2012 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 29 Apr 2012 14:30:16 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1332785811.84.0.616508221107.issue14417@psf.upfronthosting.co.za> Message-ID: <1335709816.55.0.839065321257.issue14417@psf.upfronthosting.co.za> Guido van Rossum added the comment: I could check it in, but I probably would mess up something (which branches are affected?). Let me know if you want me to. The priorities after that would be: 1) update docs (the warning about RuntimeError needs to be moderated) 2) convert stress tests to unittests ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 16:32:06 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 14:32:06 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset c468511fc887 by Mark Dickinson in branch 'default': Issue #14521: Make result of float('nan') and float('-nan') more consistent across platforms. Further, don't rely on Py_HUGE_VAL for float('inf'). http://hg.python.org/cpython/rev/c468511fc887 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 16:32:42 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 29 Apr 2012 14:32:42 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1335709962.26.0.644374431269.issue14521@psf.upfronthosting.co.za> Mark Dickinson added the comment: Now fixed. ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 16:33:05 2012 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 29 Apr 2012 14:33:05 +0000 Subject: [issue14417] dict RuntimeError workaround In-Reply-To: <1332785811.84.0.616508221107.issue14417@psf.upfronthosting.co.za> Message-ID: <1335709985.86.0.508656276905.issue14417@psf.upfronthosting.co.za> Guido van Rossum added the comment: Actually my patch doesn't even apply cleanly. I suspect the dict refactoring for shared keys interfered. Someone please help! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 16:54:42 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 29 Apr 2012 14:54:42 +0000 Subject: [issue6759] zipfile.ZipExtFile.read() is missing universal newline support In-Reply-To: <1335707686.37.0.434806067427.issue6759@psf.upfronthosting.co.za> Message-ID: <1335711434.4263.17.camel@raxxla> Serhiy Storchaka added the comment: > This would be fine with me. It may be worth to deprecate PEP 278? Oh, only ten years have passed since 2.3, but it seems it was so long ago. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 17:05:54 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 29 Apr 2012 15:05:54 +0000 Subject: [issue6759] zipfile.ZipExtFile.read() is missing universal newline support In-Reply-To: <1335711434.4263.17.camel@raxxla> Message-ID: <1335711858.3414.9.camel@localhost.localdomain> Antoine Pitrou added the comment: > It may be worth to deprecate PEP 278? Oh, only ten years have passed > since 2.3, but it seems it was so long ago. Well, I don't know if PEPs ever get deprecated. In this case, PEP 3116 is probably the superseder. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 17:23:14 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 29 Apr 2012 15:23:14 +0000 Subject: [issue14691] a code example not highlighted in http://docs.python.org/dev/library/stdtypes.html#memoryview In-Reply-To: <1335689850.36.0.828007836138.issue14691@psf.upfronthosting.co.za> Message-ID: <1335712994.26.0.687284163876.issue14691@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Is it a sphinx version problem? I could not figure out why that particular code is not highlighted. The syntax looks correct. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 17:24:05 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 29 Apr 2012 15:24:05 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1335713045.57.0.636984245927.issue11352@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- assignee: docs at python -> orsenthil nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 17:25:19 2012 From: report at bugs.python.org (Matthew Barnett) Date: Sun, 29 Apr 2012 15:25:19 +0000 Subject: [issue14462] In re's named group the name cannot contain unicode characters In-Reply-To: <1333268208.65.0.802050679023.issue14462@psf.upfronthosting.co.za> Message-ID: <1335713119.11.0.323934555298.issue14462@psf.upfronthosting.co.za> Matthew Barnett added the comment: It doesn't work in regex, but it probably should. IMHO, if it's a valid identifier, then it should be allowed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 17:33:33 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 29 Apr 2012 15:33:33 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time In-Reply-To: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za> Message-ID: <1335713613.47.0.180011094467.issue14693@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Actually, the modules are always compiled when in debug mode. Here is a patch to always compile them. ---------- keywords: +patch Added file: http://bugs.python.org/file25408/hashlibfallbacks.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 17:41:01 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 29 Apr 2012 15:41:01 +0000 Subject: [issue14157] time.strptime without a year fails on Feb 29 In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za> Message-ID: <1335714061.56.0.682004905066.issue14157@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- keywords: +needs review stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 17:46:01 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 29 Apr 2012 15:46:01 +0000 Subject: [issue14082] shutil doesn't copy extended attributes In-Reply-To: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za> Message-ID: <1335714361.27.0.473910640952.issue14082@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 17:49:10 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 29 Apr 2012 15:49:10 +0000 Subject: [issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails) In-Reply-To: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za> Message-ID: <1335714550.37.0.724414783853.issue14662@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- components: +Library (Lib) -None stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 17:56:56 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 29 Apr 2012 15:56:56 +0000 Subject: [issue9009] Improve quality of Python/dtoa.c In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za> Message-ID: <1335715016.12.0.170667390477.issue9009@psf.upfronthosting.co.za> Mark Dickinson added the comment: Dropping this due to lack of time; unless anyone else wants to pick it up, it should probably be closed as "won't fix". ---------- assignee: mark.dickinson -> priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 17:57:59 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 29 Apr 2012 15:57:59 +0000 Subject: [issue14521] math.copysign(1., float('nan')) returns -1. In-Reply-To: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za> Message-ID: <1335715079.72.0.00297764723816.issue14521@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 17:59:45 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 29 Apr 2012 15:59:45 +0000 Subject: [issue11012] Add log1p(), exp1m(), gamma(), and lgamma() to cmath In-Reply-To: <1295997901.71.0.113497713942.issue11012@psf.upfronthosting.co.za> Message-ID: <1335715185.02.0.0291562911228.issue11012@psf.upfronthosting.co.za> Mark Dickinson added the comment: Unassigning. I'm not planning to work on this in the forseeable future, though I'd be happy to review patches. ---------- assignee: mark.dickinson -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 18:06:23 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Sun, 29 Apr 2012 16:06:23 +0000 Subject: [issue10433] Document unique behavior of 'getgroups' on OSX In-Reply-To: <1289916367.38.0.763799196023.issue10433@psf.upfronthosting.co.za> Message-ID: <1335715583.77.0.590293967698.issue10433@psf.upfronthosting.co.za> Hynek Schlawack added the comment: This one LGTM, still applies cleanly against current tip and is languishing for a way to long time. Commit & close? ---------- nosy: +hynek versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 18:08:26 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 29 Apr 2012 16:08:26 +0000 Subject: [issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu In-Reply-To: <1334734810.54.0.87567518387.issue14610@psf.upfronthosting.co.za> Message-ID: <1335715706.53.0.717877746931.issue14610@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: I'm closing as invalid. If you decide to fill a bug report to your distribution (or directly to the libc in this case), it'd be interesting to post a link to the bug report here. Thanks. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed type: crash -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 18:11:15 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 29 Apr 2012 16:11:15 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1335540042.16.0.461025934486.issue4489@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Anybody working on this one? I?d give it a shot otherwise. Go ahead. You could - should? - probably use the new os.fwalk() to walk directories in a safe maner. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 18:12:15 2012 From: report at bugs.python.org (endolith) Date: Sun, 29 Apr 2012 16:12:15 +0000 Subject: [issue14694] Option to show leading zeros for bin/hex/oct Message-ID: <1335715935.12.0.0678651117983.issue14694@psf.upfronthosting.co.za> New submission from endolith : Suggestion: Add an option to bin/hex/oct functions to format binary output with a minimum fixed width, including leading zeros. Also might be useful for hex and oct. Currently, bin(18) produces '0b10010' with this change, something like bin(18, foo=8) would produce '0b00010010' Examples of people wanting this: http://stackoverflow.com/questions/3258330/converting-from-hex-to-binary-without-losing-leading-0s-python http://stackoverflow.com/questions/1002116/can-bin-be-overloaded-like-oct-and-hex-in-python-2-6 http://stackoverflow.com/a/1425558/125507 https://www.linuxquestions.org/questions/programming-9/in-python-printing-leading-zero-for-hex-numbers-0-through-f-719426/ ---------- components: Interpreter Core messages: 159623 nosy: endolith priority: normal severity: normal status: open title: Option to show leading zeros for bin/hex/oct type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 18:15:22 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 29 Apr 2012 16:15:22 +0000 Subject: [issue14694] Option to show leading zeros for bin/hex/oct In-Reply-To: <1335715935.12.0.0678651117983.issue14694@psf.upfronthosting.co.za> Message-ID: <1335716122.04.0.195673875501.issue14694@psf.upfronthosting.co.za> Mark Dickinson added the comment: -1. str.format already does this quite effectively; I don't see a real need to complicate the bin, hex and oct signatures. >>> '{:016b}'.format(324) '0000000101000100' >>> '{:016o}'.format(324) '0000000000000504' >>> '{:016x}'.format(324) '0000000000000144' ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 18:17:10 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 29 Apr 2012 16:17:10 +0000 Subject: [issue14694] Option to show leading zeros for bin/hex/oct In-Reply-To: <1335715935.12.0.0678651117983.issue14694@psf.upfronthosting.co.za> Message-ID: <1335716230.44.0.564055203506.issue14694@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- versions: +Python 3.3 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 18:26:41 2012 From: report at bugs.python.org (endolith) Date: Sun, 29 Apr 2012 16:26:41 +0000 Subject: [issue13698] Mailbox module should support other mbox formats in addition to mboxo In-Reply-To: <1325540787.88.0.149207146949.issue13698@psf.upfronthosting.co.za> Message-ID: <1335716801.08.0.0306559190157.issue13698@psf.upfronthosting.co.za> endolith added the comment: Ok. I'm not sure what backwards compatibility issues would exist, though. The only difference is that mboxrd converts "\nFrom " ? "\n>From " "\n>From " ? "\n>>From " making the conversion reversible, while mboxo does "\nFrom " ? "\n>From " "\n>From " ? "\n>From " (no change) which is ambiguous, and both get converted back to "\nFrom " when converting back to text, corrupting the original message. mboxrd is essentially a bugfix for mboxo rather than a fundamentally different format. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 18:28:20 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 29 Apr 2012 16:28:20 +0000 Subject: [issue14694] Option to show leading zeros for bin/hex/oct In-Reply-To: <1335715935.12.0.0678651117983.issue14694@psf.upfronthosting.co.za> Message-ID: <1335716900.52.0.484563798954.issue14694@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 18:35:18 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 29 Apr 2012 16:35:18 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <1335717318.32.0.57602608426.issue14626@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Well, it always boils down to the same problem: should we offer thin wrappers around underlying syscalls or offer higher-level functions? I personally think that offering mere wrappers around syscalls doesn't make much sense: Python is a very-high level language, and so should its library be. Now, I'm in favor of adding optional argument to tune the behavior with regard to symlinks, however I'm skeptical about merging regular syscalls and *at() syscalls, for the following reasons: - *at() syscalls are not portable: if it's not supported, what's remove(path='toto', dir_fd=fd) supposed to do? Throw an exception? - it's not clear how one's supposed to check that the functions are available: right now, one can do if hasattr(os, 'unlinkat'): # use unlinkat() else: # fallback to unlink() How would that work with dir_fd argument? - some functions have actually really different prototypes: for example: rename(, ) -> renameat(, , , ) trying to coalesce them into a single function will lead to awkward and ugly API: some arguments will be exclusive (which is almost always a sign of a bad API), and the order sounds really wrong: stat(path, *, followlinks=True, dirfd=None) is backwards, it should be stat(dirfd, path, *, followlinks=True) since, `path` is relative to `dirfd`. Actually, the proper way to do this would be to use overloading, but Python doesn't support it (and even if it did, I think overloading would probably be a bad idea anyway). - taking for a second the point of view of a user that has never heard of the *at() family, if I come across such a function: chmod(path, mode, *, followlinks=True, dir_fd=None) I'll probably have to think some time to understand what the hell is the last dir_fd argument. Renaming, removing a file is simple and direct, so should the API be. - finally, although useful, the *at() family is a really poor and confusing API, which will likely be used by less than 0.1% of the overall Python users. Complicating the whole posix module API just to shave off a few functions is IMHO a bad idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 18:36:08 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 16:36:08 +0000 Subject: [issue14688] Typos in sorting.rst In-Reply-To: <1335605311.94.0.280572266619.issue14688@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 295fec2cd5ed by Raymond Hettinger in branch '3.2': Issue 14688: Fix typo http://hg.python.org/cpython/rev/295fec2cd5ed ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 18:37:43 2012 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 29 Apr 2012 16:37:43 +0000 Subject: [issue14688] Typos in sorting.rst In-Reply-To: <1335605311.94.0.280572266619.issue14688@psf.upfronthosting.co.za> Message-ID: <1335717463.65.0.4224347745.issue14688@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 18:50:38 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 16:50:38 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset eb5c5c23ca9b by Brett Cannon in branch 'default': Issue #13959: Re-implement imp.NullImporter in Lib/imp.py. http://hg.python.org/cpython/rev/eb5c5c23ca9b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 18:55:12 2012 From: report at bugs.python.org (R. David Murray) Date: Sun, 29 Apr 2012 16:55:12 +0000 Subject: [issue13698] Mailbox module should support other mbox formats in addition to mboxo In-Reply-To: <1325540787.88.0.149207146949.issue13698@psf.upfronthosting.co.za> Message-ID: <1335718512.54.0.347328492073.issue13698@psf.upfronthosting.co.za> R. David Murray added the comment: If that's really the only difference we might indeed be able to treat it as a bug fix. I'd have to look at a proposed patch to be sure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 19:20:22 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 29 Apr 2012 17:20:22 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335720022.29.0.472310212392.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: Update time! With NullImporter dealt with, that leaves get_magic(), get_tag(), reload(), and get_suffixes() as things to potentially move to Lib/imp.py. I would also like to re-implement PyImport_ExecCodeModuleObject() as it's keeping a lot of C code alive just for its personal use. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 19:23:15 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 29 Apr 2012 17:23:15 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335720195.75.0.593895929768.issue13959@psf.upfronthosting.co.za> ?ric Araujo added the comment: 1659 lines less than 3.2?s import.c so far! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 19:36:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 17:36:09 +0000 Subject: [issue9154] Parser module doesn't understand function annotations. In-Reply-To: <1278270204.2.0.0990664909847.issue9154@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 9f57d66689ca by Mark Dickinson in branch '3.2': Issue #9154: Fix parser module to understand function annotations. http://hg.python.org/cpython/rev/9f57d66689ca New changeset cee5cb877631 by Mark Dickinson in branch 'default': Issue #9154: Merge fix from 3.2. http://hg.python.org/cpython/rev/cee5cb877631 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 19:40:34 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 29 Apr 2012 17:40:34 +0000 Subject: [issue14034] Add argparse howto In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za> Message-ID: <1335721234.1.0.968103972332.issue14034@psf.upfronthosting.co.za> Tshepang Lekhonkhobe added the comment: addressing the bulk of your comments this does not address last message, where you want the lines highlighted; it will be rather tedious; to me the code snippets are short enough, removing the need for highlighting ---------- Added file: http://bugs.python.org/file25409/argparse_howto4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 19:48:14 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 17:48:14 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 1255cac63dfc by Victor Stinner in branch 'default': Issue #14428: Rewrite test_process_time_threads() test http://hg.python.org/cpython/rev/1255cac63dfc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 19:57:10 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 29 Apr 2012 17:57:10 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1335722230.9.0.961693630469.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: "The test is a bit too optimistic: a thread is looping for 0.2s, and the test checks that the process time (user + system) increased of at least 0.1s. If the thread is preempted, there's a high chance you won't get even as low as 0.1s." Hum, the problem is maybe that the thread is preempted, but the first problem is that the test considers that time.process_time() uses seconds. I rewrote the test to make it more reliable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 19:57:45 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 29 Apr 2012 17:57:45 +0000 Subject: [issue14433] Python 3 interpreter crash on windows when stdin closed in Python shell In-Reply-To: <1332959225.81.0.904497362889.issue14433@psf.upfronthosting.co.za> Message-ID: <1335722265.33.0.552632754529.issue14433@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Martin, is there any reason not to commit your patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 19:57:52 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 29 Apr 2012 17:57:52 +0000 Subject: [issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds In-Reply-To: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za> Message-ID: <1335722272.72.0.970549476503.issue14127@psf.upfronthosting.co.za> STINNER Victor added the comment: Failure on x86 OpenIndiana 3.x: FAIL: test_stat_attributes (test.test_os.StatAttributeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_os.py", line 240, in test_stat_attributes self.check_stat_attributes(self.fname) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_os.py", line 199, in check_stat_attributes self.assertEqual(floaty, nanosecondy) AssertionError: 133572199178458 != 133572199178457 http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/3494/steps/test/logs/stdio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 20:11:32 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 29 Apr 2012 18:11:32 +0000 Subject: [issue9154] Parser module doesn't understand function annotations. In-Reply-To: <1278270204.2.0.0990664909847.issue9154@psf.upfronthosting.co.za> Message-ID: <1335723092.76.0.792031889802.issue9154@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 20:35:17 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 18:35:17 +0000 Subject: [issue14691] a code example not highlighted in http://docs.python.org/dev/library/stdtypes.html#memoryview In-Reply-To: <1335689850.36.0.828007836138.issue14691@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 925fbcfbbc45 by Sandro Tosi in branch 'default': Issue #14691: indent the traceback so the example is highlighted http://hg.python.org/cpython/rev/925fbcfbbc45 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 20:39:53 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 29 Apr 2012 18:39:53 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1335722230.9.0.961693630469.issue14428@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Hum, the problem is maybe that the thread is preempted, but the first > problem is that the test considers that time.process_time() uses seconds. Hum, what? You mean that process_time() doesn't return seconds? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 20:40:26 2012 From: report at bugs.python.org (Sandro Tosi) Date: Sun, 29 Apr 2012 18:40:26 +0000 Subject: [issue14691] a code example not highlighted in http://docs.python.org/dev/library/stdtypes.html#memoryview In-Reply-To: <1335689850.36.0.828007836138.issue14691@psf.upfronthosting.co.za> Message-ID: <1335724826.74.0.136328617248.issue14691@psf.upfronthosting.co.za> Sandro Tosi added the comment: It's seems like a deja-vu: I thought I saw this problem once, and was already fixed - bah, it was tricky (traceback needs to be indented for the code to be highlighted), that's why I remember it ---------- nosy: +sandro.tosi resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 20:40:52 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 18:40:52 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset eb68502731dd by Brett Cannon in branch 'default': Issues #13959, 14647: Re-implement imp.reload() in Lib/imp.py. http://hg.python.org/cpython/rev/eb68502731dd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 20:41:57 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 29 Apr 2012 18:41:57 +0000 Subject: [issue14647] imp.reload() on a package leads to a segfault or a GC assertion failure In-Reply-To: <1335136677.5.0.49699953472.issue14647@psf.upfronthosting.co.za> Message-ID: <1335724917.12.0.783676501206.issue14647@psf.upfronthosting.co.za> Brett Cannon added the comment: Fixed by http://hg.python.org/cpython/rev/eb68502731dd ---------- assignee: -> brett.cannon resolution: -> fixed stage: test needed -> status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 20:59:09 2012 From: report at bugs.python.org (Dov Feldstern) Date: Sun, 29 Apr 2012 18:59:09 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time In-Reply-To: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za> Message-ID: <1335725949.6.0.34826511534.issue14693@psf.upfronthosting.co.za> Dov Feldstern added the comment: Thanks for the prompt response! Yes, this looks good, I made a very similar patch myself and it seemed to work correctly (but that was on 2.7, and I didn't know how exactly to fix up the tests...). Thanks again! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 21:38:21 2012 From: report at bugs.python.org (Brett Cannon) Date: Sun, 29 Apr 2012 19:38:21 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1335728301.91.0.999415738528.issue13959@psf.upfronthosting.co.za> Brett Cannon added the comment: So here is the deal with PyImport_ExecCodeModuleObject(): bootstrapping and Barry has made this a little annoying. =) First off, PyImport_ImportFrozenModuleObject() uses PyImport_ExecCodeModuleObject(), so that precludes just directly importing imp to handle this function entirely. OK, so that means just trying to chop out the path manipulation stuff since that is duplicating code found in imp/importlib. The problem, though, is that PyImport_ExecCodeModuleWithPathnames() will take its pathname argument and try to get a source path from it if it points to some .pyc file (PEP 3147 or sourceless .pyc, and if that new path exists then it is used instead of the given path. Unfortunately that API was introduced in Python 3.2, so there is a backwards-compatibility issue in that one can't just rip out the code w/o supporting it. But those semantics are the reason the equivalent of imp.source_from_cache() continues to exist in Python/import.c. I see two options here. One is to simply leave the C code in, but that has the drawback of duplicated Python and C code. Two is to stick in a call to imp.source_from_cache() between PyImport_ExecCodeModuleWithPathnames() and PyImport_ExecCodeModuleObject() so the former retains the semantics and the latter doesn't pick up the bad habit before 3.3 is released. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 21:44:34 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 29 Apr 2012 19:44:34 +0000 Subject: [issue14695] Tools/parser/unparse.py is out of date. Message-ID: <1335728674.11.0.179577366721.issue14695@psf.upfronthosting.co.za> New submission from Mark Dickinson : Here's a patch that makes all tests in Tools/parser/test_unparse.py pass on the default branch. (The 'yield from' bits would have to be removed for 3.2.) ---------- components: Demos and Tools files: unparse.patch keywords: patch messages: 159645 nosy: mark.dickinson priority: normal severity: normal stage: patch review status: open title: Tools/parser/unparse.py is out of date. type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25410/unparse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 22:21:43 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 29 Apr 2012 20:21:43 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time In-Reply-To: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za> Message-ID: <1335730903.04.0.669588479382.issue14693@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The official way for building certain modules despite auto-configuration is to edit Modules/Setup, or Modules/Setup.local. This already supports the exact use case, so I'm closing this as "works for me". ---------- nosy: +loewis resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 22:22:59 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 29 Apr 2012 20:22:59 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time In-Reply-To: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za> Message-ID: <1335730979.78.0.150423072464.issue14693@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: works for me -> stage: needs patch -> patch review status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 22:29:40 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 29 Apr 2012 20:29:40 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time In-Reply-To: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za> Message-ID: <1335731380.23.0.452723580072.issue14693@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Antoine: why did you reopen it? Leave *at least* an explanation please. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 22:32:18 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 29 Apr 2012 20:32:18 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time In-Reply-To: <1335731380.23.0.452723580072.issue14693@psf.upfronthosting.co.za> Message-ID: <1335731441.3414.12.camel@localhost.localdomain> Antoine Pitrou added the comment: > Antoine: why did you reopen it? Leave *at least* an explanation please. Ah, sorry. I think it's a reasonable enhancement request, and furthermore the patch simplifies the setup code. Also, it allows us to test the _md5 (etc.) modules in non-debug mode as well. Perhaps Gregory can tell us what he thinks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 22:42:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 20:42:09 +0000 Subject: [issue10941] imaplib: Internaldate2tuple produces wrong result if date is near a DST change In-Reply-To: <1295394107.36.0.490316527511.issue10941@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 90b9781ccb5f by Alexander Belopolsky in branch '3.2': Issue #10941: Fix imaplib.Internaldate2tuple to produce correct result near http://hg.python.org/cpython/rev/90b9781ccb5f New changeset 6e029b6c142a by Alexander Belopolsky in branch 'default': Issue #10941: Fix imaplib.Internaldate2tuple to produce correct result near http://hg.python.org/cpython/rev/6e029b6c142a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 22:42:36 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 29 Apr 2012 20:42:36 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time In-Reply-To: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za> Message-ID: <1335732156.46.0.354341140101.issue14693@psf.upfronthosting.co.za> Martin v. L?wis added the comment: If it's an official feature that these modules are always built, the patch is insufficient: it then also needs to adjust the build environment for Windows, and the packaging. It potentially also affects packaging for OSX and Linux. I still think that users with special needs such as (1) and (2) in the original message are better served by editig Modules/Setup, as that also allows e.g. to make the modules truly builtin. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 22:58:50 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 29 Apr 2012 20:58:50 +0000 Subject: [issue14696] parser module doesn't support nonlocal statement Message-ID: <1335733130.9.0.362918429472.issue14696@psf.upfronthosting.co.za> New submission from Mark Dickinson : Here's a patch. ---------- files: parser_nonlocal.patch keywords: patch messages: 159651 nosy: mark.dickinson priority: normal severity: normal stage: patch review status: open title: parser module doesn't support nonlocal statement type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25411/parser_nonlocal.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 23:10:01 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 29 Apr 2012 21:10:01 +0000 Subject: [issue14696] parser module doesn't support nonlocal statement In-Reply-To: <1335733130.9.0.362918429472.issue14696@psf.upfronthosting.co.za> Message-ID: <1335733801.59.0.0288236879506.issue14696@psf.upfronthosting.co.za> Mark Dickinson added the comment: Better test: the nonlocal statements should be in a nested scope. ---------- Added file: http://bugs.python.org/file25412/parser_nonlocal.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 23:10:25 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 29 Apr 2012 21:10:25 +0000 Subject: [issue14696] parser module doesn't support nonlocal statement In-Reply-To: <1335733130.9.0.362918429472.issue14696@psf.upfronthosting.co.za> Message-ID: <1335733825.64.0.899531792986.issue14696@psf.upfronthosting.co.za> Changes by Mark Dickinson : Removed file: http://bugs.python.org/file25411/parser_nonlocal.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 23:17:48 2012 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 29 Apr 2012 21:17:48 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1335734268.84.0.626907626751.issue14428@psf.upfronthosting.co.za> Antoine Pitrou added the comment: There are many sporadic failures on the buildbots: ====================================================================== FAIL: test_process_time_threads (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_time.py", line 441, in test_process_time_threads self.assertGreaterEqual(t2 - t1, busy) AssertionError: 0.01249799999999368 not greater than or equal to 0.013093999999966854 ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 23:20:07 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 21:20:07 +0000 Subject: [issue14696] parser module doesn't support nonlocal statement In-Reply-To: <1335733130.9.0.362918429472.issue14696@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b7e491b9094f by Mark Dickinson in branch '3.2': Issue #14696: Fix parser module to understand 'nonlocal' declarations. http://hg.python.org/cpython/rev/b7e491b9094f New changeset 5acddc7c666d by Mark Dickinson in branch 'default': Issue #14696: Merge from 3.2 http://hg.python.org/cpython/rev/5acddc7c666d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 23:24:27 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 29 Apr 2012 21:24:27 +0000 Subject: [issue14696] parser module doesn't support nonlocal statement In-Reply-To: <1335733130.9.0.362918429472.issue14696@psf.upfronthosting.co.za> Message-ID: <1335734667.78.0.429814118678.issue14696@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- assignee: -> mark.dickinson components: +Library (Lib) resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 23:26:35 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 29 Apr 2012 21:26:35 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time In-Reply-To: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za> Message-ID: <1335734795.44.0.0178871130533.issue14693@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I don't have a problem with always compiling them. Distro packagers should see that the stand alone versions are not distributed with their package that has a dependency on openssl as they'll just be a waste of space. But that is up to the distro package maintainers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 29 23:44:58 2012 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 29 Apr 2012 21:44:58 +0000 Subject: [issue14697] parser module doesn't support set displays or set comprehensions Message-ID: <1335735898.27.0.486602524616.issue14697@psf.upfronthosting.co.za> New submission from Mark Dickinson : >>> parser.tuple2st(parser.expr('{2}').totuple()) Traceback (most recent call last): File "", line 1, in parser.ParserError: could not validate expression tuple [70677 refs] >>> parser.tuple2st(parser.expr('{x**2 for x in [1, 2, 3]}').totuple()) Traceback (most recent call last): File "", line 1, in parser.ParserError: could not validate expression tuple [70677 refs] This seems to be already fixed in Python 2.7. ---------- components: Library (Lib) messages: 159656 nosy: mark.dickinson priority: normal severity: normal stage: needs patch status: open title: parser module doesn't support set displays or set comprehensions type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 00:53:58 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 22:53:58 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 0bdf0727ee29 by Victor Stinner in branch 'default': Issue #14428: Make test_process_time_threads() less strict http://hg.python.org/cpython/rev/0bdf0727ee29 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 00:56:12 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 29 Apr 2012 22:56:12 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1335740172.93.0.913577185093.issue11352@psf.upfronthosting.co.za> STINNER Victor added the comment: > What is the reason for this one to languish for over a year now? Maybe because few people are concerned by the cgi module? > Lack of proper patch? It would help to have a patch attached to the issue, and a review of the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 01:41:00 2012 From: report at bugs.python.org (Roundup Robot) Date: Sun, 29 Apr 2012 23:41:00 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset ad3d6010379b by Victor Stinner in branch 'default': Issue #14428: Remove test_process_time_threads() from test_time http://hg.python.org/cpython/rev/ad3d6010379b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 01:47:06 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 29 Apr 2012 23:47:06 +0000 Subject: [issue7677] improve error message for setup.py upload --sign without --identity In-Reply-To: <1263223354.89.0.290474495181.issue7677@psf.upfronthosting.co.za> Message-ID: <1335743226.6.0.683973759917.issue7677@psf.upfronthosting.co.za> ?ric Araujo added the comment: We had a look at this bug during a sprint last week. First, it is reasonable to use --sign without --identity, as gpg will fall back to a default identity (see the description of --local-user and --default-key in the gpg man page). Second, it looks like you run distutils commands from a script or makefile and you have a bug there (the ?skipped "gn"? message looks suspicious, maybe -sign was used instead of --sign and interpreted as -s -i gn). Finally, even though we thing this is not a bug, we agreed that it would be nicer to print a message to make clear that distutils2 is not broken but shows the error message from gpg on purpose; this may be done during the next sprint. ---------- assignee: tarek -> eric.araujo components: -Distutils nosy: +alexis versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 01:47:52 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 29 Apr 2012 23:47:52 +0000 Subject: [issue7677] upload: improve display for error messages from gpg In-Reply-To: <1263223354.89.0.290474495181.issue7677@psf.upfronthosting.co.za> Message-ID: <1335743272.87.0.203506937952.issue7677@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- title: improve error message for setup.py upload --sign without --identity -> upload: improve display for error messages from gpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 01:48:49 2012 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 29 Apr 2012 23:48:49 +0000 Subject: [issue6114] distutils build_ext path comparison only based on strings In-Reply-To: <1243335359.03.0.865660639037.issue6114@psf.upfronthosting.co.za> Message-ID: <1335743329.7.0.148443130542.issue6114@psf.upfronthosting.co.za> ?ric Araujo added the comment: Two people started working on this during the first Montreal sprint. ---------- versions: +Python 3.3 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 01:54:02 2012 From: report at bugs.python.org (STINNER Victor) Date: Sun, 29 Apr 2012 23:54:02 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1332897091.91.0.591449917803.issue14428@psf.upfronthosting.co.za> Message-ID: <1335743642.42.0.704235430298.issue14428@psf.upfronthosting.co.za> STINNER Victor added the comment: > You mean that process_time() doesn't return seconds? Yes, dt is not a number of seconds in the following example: t1=time.process_time(); (...); t2=time.process_time(); dt=t2-t1 > I see two options: either increase the total running time, > to make it really likely you'll get a chance to run > (or decrase the lower threshold), or use times(2), and > check the result against that (does Windows have such a syscall?). I wrote the test to check if time.process_time() measures the total CPU of the process, and not the CPU time of only the current thread. I'm tired of this PEP, so I just removed the test. I don't think that it is really interesting and it looks difficult to write a reliable test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 03:10:11 2012 From: report at bugs.python.org (STINNER Victor) Date: Mon, 30 Apr 2012 01:10:11 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: <1335748211.39.0.249899928345.issue14687@psf.upfronthosting.co.za> STINNER Victor added the comment: Updated patch: - use also PyUnicode_Kind for kind and fmtkind - fix compiler warnings - initialize data outside the loop - avoid duplicate PyUnicode_READ() where it is possible - minor code cleanup ---------- Added file: http://bugs.python.org/file25413/pyunicode_format-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 05:25:21 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 30 Apr 2012 03:25:21 +0000 Subject: [issue14687] Optimize str%tuple for the PEP 393 In-Reply-To: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 42fbb4f9b540 by Victor Stinner in branch 'default': Issue #14687: Cleanup PyUnicode_Format() http://hg.python.org/cpython/rev/42fbb4f9b540 New changeset 08b54c635586 by Victor Stinner in branch 'default': Issue #14687: Avoid an useless duplicated string in PyUnicode_Format() http://hg.python.org/cpython/rev/08b54c635586 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 06:28:45 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 30 Apr 2012 04:28:45 +0000 Subject: [issue14433] Python 3 interpreter crash on windows when stdin closed in Python shell In-Reply-To: <1332959225.81.0.904497362889.issue14433@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2de5e9715fe9 by Martin v. L?wis in branch '3.2': Issue #14433: Prevent msvcrt crash in interactive prompt when stdin is closed. http://hg.python.org/cpython/rev/2de5e9715fe9 New changeset 2c27093fd11f by Martin v. L?wis in branch 'default': Merge with 3.2: issue #14433 http://hg.python.org/cpython/rev/2c27093fd11f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 06:28:51 2012 From: report at bugs.python.org (Israel Fruchter) Date: Mon, 30 Apr 2012 04:28:51 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time In-Reply-To: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za> Message-ID: <1335760131.11.0.263150599964.issue14693@psf.upfronthosting.co.za> Israel Fruchter added the comment: I think (2) is very important, and I agree Gregory about the distro responsibility for size. further more, if everything is define using the standard Modules/Setup, or Modules/Setup.local during compile/build time, why having a fallback anyhow in hashlib.py ? BTW anyone that compiles for embedded systems adds a patch for remove all the code that detects modules automatically see this from openembeded.org: http://cgit.openembedded.org/openembedded/tree/recipes/python/python-2.6.6/nohostlibs.patch?id=9389f986ac8672cb671f00ab749ce323340b9500 ---------- nosy: +fruch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 06:29:14 2012 From: report at bugs.python.org (Israel Fruchter) Date: Mon, 30 Apr 2012 04:29:14 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time In-Reply-To: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za> Message-ID: <1335760154.42.0.946071573268.issue14693@psf.upfronthosting.co.za> Changes by Israel Fruchter : ---------- versions: +Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 06:31:25 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 30 Apr 2012 04:31:25 +0000 Subject: [issue14433] Python 3 interpreter crash on windows when stdin closed in Python shell In-Reply-To: <1332959225.81.0.904497362889.issue14433@psf.upfronthosting.co.za> Message-ID: <1335760285.91.0.546218015718.issue14433@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Out of the original report, ISTM that: a) the exit of the interpreter on closing stdin is considered correct behavior, and b) the crash on Windows is now fixed for 3.2, and 3.3 Hence I'm closing this issue as fixed. ---------- resolution: -> fixed status: open -> closed versions: +Python 3.3 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 08:06:50 2012 From: report at bugs.python.org (Jon Oberheide) Date: Mon, 30 Apr 2012 06:06:50 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1335766010.24.0.936830053463.issue14532@psf.upfronthosting.co.za> Jon Oberheide added the comment: Ok, patch v4 uploaded. Only change is the rename to "secure_compare". ---------- Added file: http://bugs.python.org/file25414/hmac-time-independent-v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 08:56:40 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 30 Apr 2012 06:56:40 +0000 Subject: [issue14428] Implementation of the PEP 418 In-Reply-To: <1335743642.42.0.704235430298.issue14428@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Yes, dt is not a number of seconds in the following example: > > t1=time.process_time(); (...); t2=time.process_time(); dt=t2-t1 OK, so what is it then? It's not written anywhere - neither in the PEP nor in the documentation - and it should. Furthermore: """ $ cat /tmp/test_ptime.py import sys import time rt = time.time() pt = time.process_time() for i in range(int(sys.argv[1])): pass print("real time: %f" % (time.time() - rt)) print("process time: %f" % (time.process_time() - pt)) $ ./python /tmp/test_ptime.py 100000 real time: 0.168570 process time: 0.168425 """ It really looks like seconds to me, definitely not jiffies ;-) Also, I've had a quick look at the code, and ISTM that it does indeed return seconds. > I wrote the test to check if time.process_time() measures the total CPU of > the process, and not the CPU time of only the current thread. > > I'm tired of this PEP, so I just removed the test. I don't think that it is > really interesting and it looks difficult to write a reliable test. Hum, right now, the only process_time test I see is test_process_time, which just checks that a sleep almost doesn't consume "process time", which is a bit light. """ # Use a factor of 0.75 because time.process_time() is maybe not precise self.assertGreaterEqual(t2 - t1, busy * 0.75) """ It's not that process_time() is not precise (I assume you mean accurate ;-). It's just that since it measures CPU time (user+system), it depends on the scheduling: in fact, if you have let's say a real-time priority task running at the same time, on a uniprocessor system, the thread could in theory not even get a chance to run, which would yield a CPU time of 0: that would still be accurate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 09:44:31 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 30 Apr 2012 07:44:31 +0000 Subject: [issue1522400] irda socket support Message-ID: <1335771871.67.0.628879152688.issue1522400@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: > Actually I think it suffers from the same problem as AF_UNIX: > sockaddr_irda->sir_name, like sockaddr_un->sun_path, don't have to be > NUL-terminated, and the kernel can return non NUL-terminated strings. Actually, I've had a look at the Linux and Windows documentation, and sir_name is NUL-terminated. I've also had a look at the kernel source, and it treats sir_name as NUL-terminated, so it should be safe. Here's a new patch, with a couple new constants, documentation update and some - really basic - tests. I guess Gregory is right, and we could push this as-is, and wait until some users is interested in improving the support and tests. ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 09:45:05 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 30 Apr 2012 07:45:05 +0000 Subject: [issue1522400] irda socket support Message-ID: <1335771905.72.0.908197409733.issue1522400@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file25415/irda-default-1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 09:47:55 2012 From: report at bugs.python.org (Pierre Quentel) Date: Mon, 30 Apr 2012 07:47:55 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1335772075.24.0.314233027309.issue11352@psf.upfronthosting.co.za> Pierre Quentel added the comment: Thanks Hynek for raising this issue from the dead Patch proposal attached. Sorry if there are markup errors, it's my first contact with rst ---------- Added file: http://bugs.python.org/file25416/cgi.rst _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 09:48:14 2012 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 30 Apr 2012 07:48:14 +0000 Subject: [issue14034] Add argparse howto In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za> Message-ID: <1335772094.16.0.420445225146.issue14034@psf.upfronthosting.co.za> Tshepang Lekhonkhobe added the comment: Thanks so much for your thorough attention to detail. I've addressed all your latest comments. ---------- Added file: http://bugs.python.org/file25417/argparse_howto5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 09:51:22 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 30 Apr 2012 07:51:22 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time In-Reply-To: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za> Message-ID: <1335772282.86.0.136858328791.issue14693@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- versions: -Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 09:59:22 2012 From: report at bugs.python.org (Stefano Taschini) Date: Mon, 30 Apr 2012 07:59:22 +0000 Subject: [issue8767] Configure: Cannot disable unicode In-Reply-To: <1274286115.56.0.588868311562.issue8767@psf.upfronthosting.co.za> Message-ID: <1335772762.29.0.865543554586.issue8767@psf.upfronthosting.co.za> Stefano Taschini added the comment: Martin, That was exactly my first approach. What made me change my mind is that i) it is also fairly hacky (one might rightfully object that it is the isinstance(x, unicode) tests that should be changed) ii) it is now a hack spread over a dozen files, instead of the site.py alone. iii) the alterations in those files are executed even in the case of built-in unicode support, thus increasing the risk of introducing a regression in the stdlib. In the end I was a bit loath to alter quite a few of the stdlib modules (including some of the "core" ones) for a rather infrequent case. My solution, on the other hand, is such that in the regular case of built-in unicode support those modules are not touched at all, thus reducing the risk of introducing a regression in the stdlib. Still, if you guys do think that the maintainability risk due to the hackiness of my suggestion exceeds the potential benefits, it might be better to split the issue (and the patch) into two: one for the autoconf and interpreter, and one for the stdlib. In this way, the patch for autconf and interpreter (which should be less controversial) might be accepted sooner, while we bide our time until we come up with a better solution for the stdlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 10:02:47 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 30 Apr 2012 08:02:47 +0000 Subject: [issue8767] Configure: Cannot disable unicode In-Reply-To: <1335772762.29.0.865543554586.issue8767@psf.upfronthosting.co.za> Message-ID: <4F9E4726.4080902@v.loewis.de> Martin v. L?wis added the comment: > it might be better to split the issue (and the patch) into two: one for the autoconf and interpreter, and one for the stdlib. Please do that. Splitting the patch could be enough, no need to split the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 10:05:28 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 30 Apr 2012 08:05:28 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1335773128.05.0.669370334615.issue11352@psf.upfronthosting.co.za> Hynek Schlawack added the comment: That?s not a patch. :) Posting whole files makes them very hard to review because you can?t spot the changes. The best thing would be to get a fresh clone of the repo: http://docs.python.org/devguide/setup.html#setup , copy your edited file to the appropriate place and run `hg diff`. If it looks okay, redirect the output into a file (something like `hg diff >cgi-doc-update.patch`) and attach it to this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 10:17:16 2012 From: report at bugs.python.org (Stefano Taschini) Date: Mon, 30 Apr 2012 08:17:16 +0000 Subject: [issue8767] Configure: Cannot disable unicode In-Reply-To: <1274286115.56.0.588868311562.issue8767@psf.upfronthosting.co.za> Message-ID: <1335773836.28.0.299857812992.issue8767@psf.upfronthosting.co.za> Changes by Stefano Taschini : Added file: http://bugs.python.org/file25418/issue8767_interpreter.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 10:18:34 2012 From: report at bugs.python.org (Stefano Taschini) Date: Mon, 30 Apr 2012 08:18:34 +0000 Subject: [issue8767] Configure: Cannot disable unicode In-Reply-To: <1274286115.56.0.588868311562.issue8767@psf.upfronthosting.co.za> Message-ID: <1335773914.33.0.88191450719.issue8767@psf.upfronthosting.co.za> Stefano Taschini added the comment: Here we go. ---------- Added file: http://bugs.python.org/file25419/issue8767_stdlib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 10:30:40 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 30 Apr 2012 08:30:40 +0000 Subject: [issue14698] test_posix failures - getpwduid()/initgroups()/getgroups() Message-ID: <1335774640.36.0.246153891142.issue14698@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali : test_posix is consistently failing on the bigmem buildbot: http://python.org/dev/buildbot/all/builders/AMD64 debian bigmem 3.x/builds/291/steps/test/logs/stdio """ ====================================================================== ERROR: test_getgrouplist (test.test_posix.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/test_posix.py", line 633, in test_getgrouplist set(posix.getgrouplist(pwd.getpwuid(os.getuid())[0], KeyError: 'getpwuid(): uid not found: 5025' ====================================================================== ERROR: test_initgroups (test.test_posix.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/test_posix.py", line 111, in test_initgroups name = pwd.getpwuid(posix.getuid()).pw_name KeyError: 'getpwuid(): uid not found: 5025' """ I assume that's because the buildbot tests run with a UID without any corresponding pwd entry (which is legit). The attached patch should fix thoe failures, by making the tests more robust. ---------- components: Tests files: test_no_pwd.diff keywords: buildbot, easy, needs review, patch messages: 159677 nosy: neologix, pitrou priority: normal severity: normal status: open title: test_posix failures - getpwduid()/initgroups()/getgroups() type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25420/test_no_pwd.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 10:40:07 2012 From: report at bugs.python.org (Pierre Quentel) Date: Mon, 30 Apr 2012 08:40:07 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1335775207.55.0.821907367134.issue11352@psf.upfronthosting.co.za> Pierre Quentel added the comment: Sorry about that. I didn't dare to say I was also a Mercurial newbie ---------- Added file: http://bugs.python.org/file25421/cgi-doc-update.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 10:40:26 2012 From: report at bugs.python.org (Pierre Quentel) Date: Mon, 30 Apr 2012 08:40:26 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1335775226.46.0.240283757287.issue11352@psf.upfronthosting.co.za> Changes by Pierre Quentel : Removed file: http://bugs.python.org/file25416/cgi.rst _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 10:41:30 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 30 Apr 2012 08:41:30 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1335775207.55.0.821907367134.issue11352@psf.upfronthosting.co.za> Message-ID: Senthil Kumaran added the comment: Not to worry about that Pierre. I shall review the patch (contents) in the evening (SGT) and I should be able to commit/close this issue. Thanks, Senthil ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 10:47:26 2012 From: report at bugs.python.org (Pierre Quentel) Date: Mon, 30 Apr 2012 08:47:26 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1335775646.45.0.600956023988.issue11352@psf.upfronthosting.co.za> Pierre Quentel added the comment: Thanks Senthil I spot a typo in the first modified paragraph : "cet" instead of "set" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 11:05:08 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 30 Apr 2012 09:05:08 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1300640817.81.0.852617582602.issue11618@psf.upfronthosting.co.za> Message-ID: <1335776708.84.0.784761367867.issue11618@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As it stands, the patch is pointless, and can safely be rejected. We will just not have defined NTDDI_VERSION at NTDDI_VISTA for any foreseeable future, so all the Vista-specific code can be eliminated from the patch. Python had been using dynamic checking for API "forever". In 2.5, there was a check for presence of GetFileAttributesExA; in 2.4, there was a check for CryptAcquireContextA. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 11:11:31 2012 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 30 Apr 2012 09:11:31 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <1335217931.89.0.157136074708.issue14656@psf.upfronthosting.co.za> Message-ID: <1335777091.31.0.0500180782812.issue14656@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Please, go ahead, explain :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 11:14:54 2012 From: report at bugs.python.org (Mark Shannon) Date: Mon, 30 Apr 2012 09:14:54 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: <1335777294.42.0.839698216597.issue13903@psf.upfronthosting.co.za> Mark Shannon added the comment: Change insertdict to follow normal (non-stealing) ref-counting behaviour which fixes possible leakage. Patch attached. ---------- Added file: http://bugs.python.org/file25422/insertdict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 11:16:30 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 30 Apr 2012 09:16:30 +0000 Subject: [issue14669] test_multiprocessing failure on OS X Tiger In-Reply-To: <1335370611.47.0.977907847024.issue14669@psf.upfronthosting.co.za> Message-ID: <1335777390.3.0.503477999775.issue14669@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: > I can't work out what is wrong here. OS-X has known issues with FD-passing over Unix domain sockets, see issues #6560 and #12958. Since those failures only occur on OS-X buildbots, I'd suggest just skipping them... ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 11:54:45 2012 From: report at bugs.python.org (Jakob Simon-Gaarde) Date: Mon, 30 Apr 2012 09:54:45 +0000 Subject: [issue14692] json.joads parse_constant callback not working anymore In-Reply-To: <1335695665.87.0.370023915793.issue14692@psf.upfronthosting.co.za> Message-ID: <1335779685.93.0.461711350228.issue14692@psf.upfronthosting.co.za> Jakob Simon-Gaarde added the comment: Ok, I accept that at some point it was decided to take away the call to parse_constant hook on "true" and "false" values. But how does it help me to know this, I still need to react on these values? It seems a little overkill to parse through all parsed values using object_pairs_hook. Best Regards Jakob Simon-Gaarde ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 12:03:10 2012 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 30 Apr 2012 10:03:10 +0000 Subject: [issue11618] Locks broken wrt timeouts on Windows In-Reply-To: <1335776708.84.0.784761367867.issue11618@psf.upfronthosting.co.za> Message-ID: Kristj?n Valur J?nsson added the comment: Martin, I think you misunderstand completely. the patch is _not_ about using the VISTA features. It is about not using a "mutex" for threading.lock. Currently, the locks in python use Mutex objects, and a WaitForSingleObjects() system call to acquire them. This patch replaces theses locks with user-level objects (critical sections and condition variables.). This drops the time needed for an uncontended acquire/release by 60% since there is no kernel transition and scheduling. The patch comes in two flavors. The current version _emulates_ condition variables on Windows by the same mechanism as I introduced for the new GIL, that is, using a combination of "critical section" objects and a construct made of a "semaphore" and a counter. Also provided, for those that want, and for future reference, is a version that uses native system objects (windows condition variables and SRWLocks). I can drop them from the patch to make you happy, but they are dormant and nicely show how conditional compilation can switch in more modern features for a different target architecture. K > -----Original Message----- > From: Martin v. L?wis [mailto:report at bugs.python.org] > Sent: 30. apr?l 2012 09:05 > To: Kristj?n Valur J?nsson > Subject: [issue11618] Locks broken wrt timeouts on Windows > > > Martin v. L?wis added the comment: > > As it stands, the patch is pointless, and can safely be rejected. We will just > not have defined NTDDI_VERSION at NTDDI_VISTA for any foreseeable > future, so all the Vista-specific code can be eliminated from the patch. > > Python had been using dynamic checking for API "forever". In 2.5, there was > a check for presence of GetFileAttributesExA; in 2.4, there was a check for > CryptAcquireContextA. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 12:11:22 2012 From: report at bugs.python.org (Mark Shannon) Date: Mon, 30 Apr 2012 10:11:22 +0000 Subject: [issue14699] Calling a classmethod_descriptor directly raises a TypeError for wrong number of parameters. Message-ID: <1335780682.19.0.434044540817.issue14699@psf.upfronthosting.co.za> New submission from Mark Shannon : classmethod_descriptor should either be uncallable or (better) accept the correct number of arguments. The classmethod_descriptor can be regarded as the Python object corresponding directly to the underlying C function, as well as a descriptor object. When called it should check that its first parameter is a subtype of the type in which it was declared, and then pass that as the 'self' parameter to the underlying C function. Currently it passes the type in which it was declared as its 'self' parameter, adding the remaining parameters. This means that this fails: float.__dict__['fromhex'](float, "1") and this succeeds: float.__dict__['fromhex']("1") but it should be the other way around, otherwise it is impossible to pass a subtype as a parameter. There is no tests for calling classmethod_descriptors in the test suite. Attached patch includes tests and fixes the behaviour. ---------- components: Interpreter Core files: classmethoddescr_call.patch keywords: patch messages: 159687 nosy: Mark.Shannon priority: normal severity: normal status: open title: Calling a classmethod_descriptor directly raises a TypeError for wrong number of parameters. type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file25423/classmethoddescr_call.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 13:06:15 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 30 Apr 2012 11:06:15 +0000 Subject: [issue7719] distutils: ignore .nfsXXXX files In-Reply-To: <1263669405.52.0.706975841329.issue7719@psf.upfronthosting.co.za> Message-ID: <1335783975.46.0.445074133033.issue7719@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Jeff, the patch LGTM but Eric indicated he'd like to have a higher level test inside Lib/distutils/tests/test_sdist.py. Possibly as part of a bigger test like test_prune_file_list or test_add_defaults; no need to remove the old test though I guess. P.S. There's an extra empty line inside of apiref.rst. You may want to strip it from your next patch. ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 13:22:09 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 30 Apr 2012 11:22:09 +0000 Subject: [issue13152] textwrap: support custom tabsize In-Reply-To: <1318338300.67.0.514985359705.issue13152@psf.upfronthosting.co.za> Message-ID: <1335784929.36.0.235387130527.issue13152@psf.upfronthosting.co.za> Hynek Schlawack added the comment: The code LGTM, the documentation lacks `versionchanged` tag though. Would you mind adding it? ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 15:08:10 2012 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 30 Apr 2012 13:08:10 +0000 Subject: [issue14656] Add a macro for unreachable code In-Reply-To: <1335217931.89.0.157136074708.issue14656@psf.upfronthosting.co.za> Message-ID: <1335791290.28.0.327655512894.issue14656@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Did you see the sample patch I posted? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 15:10:55 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 30 Apr 2012 13:10:55 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time In-Reply-To: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za> Message-ID: <1335791455.56.0.368210951786.issue14693@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Python in Gentoo is also patched to always build _sha256, _sha512, _md5 and _sha1 modules. ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 15:14:47 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 30 Apr 2012 13:14:47 +0000 Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za> Message-ID: <1335791687.63.0.226277092387.issue4489@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 15:29:39 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 30 Apr 2012 13:29:39 +0000 Subject: [issue14157] time.strptime without a year fails on Feb 29 In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za> Message-ID: <1335792579.6.0.089475484969.issue14157@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 15:38:59 2012 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 30 Apr 2012 13:38:59 +0000 Subject: [issue14304] Implement utf-8-bmp codec In-Reply-To: <1331758870.76.0.606902244655.issue14304@psf.upfronthosting.co.za> Message-ID: <1335793139.22.0.0630571970252.issue14304@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 15:40:47 2012 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 30 Apr 2012 13:40:47 +0000 Subject: [issue14157] time.strptime without a year fails on Feb 29 In-Reply-To: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za> Message-ID: <1335793247.71.0.235578322775.issue14157@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This is a bit of a hack, but seems to get the work done. Does anyone have any objections to committing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 15:53:07 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 30 Apr 2012 13:53:07 +0000 Subject: [issue12958] test_socket failures on Mac OS X In-Reply-To: <1315719643.71.0.858357749479.issue12958@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e64bec91ac91 by Richard Oudkerk in branch 'default': Issue #14669: Skip multiprocessing connection pickling test on MacOSX http://hg.python.org/cpython/rev/e64bec91ac91 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 15:53:07 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 30 Apr 2012 13:53:07 +0000 Subject: [issue6560] socket sendmsg(), recvmsg() methods In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e64bec91ac91 by Richard Oudkerk in branch 'default': Issue #14669: Skip multiprocessing connection pickling test on MacOSX http://hg.python.org/cpython/rev/e64bec91ac91 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 15:53:09 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 30 Apr 2012 13:53:09 +0000 Subject: [issue14669] test_multiprocessing failure on OS X Tiger In-Reply-To: <1335370611.47.0.977907847024.issue14669@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset e64bec91ac91 by Richard Oudkerk in branch 'default': Issue #14669: Skip multiprocessing connection pickling test on MacOSX http://hg.python.org/cpython/rev/e64bec91ac91 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 16:13:31 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 30 Apr 2012 14:13:31 +0000 Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za> Message-ID: <1335795211.98.0.611829017781.issue10142@psf.upfronthosting.co.za> Hynek Schlawack added the comment: In some cases you change "invalid" to "unsupported" when encountering an invalid/unsupported `whence' and in others you keep them on "invalid". I find it rather hard to really differentiate these two words in that context; care to shed a light and tell me the thought process behind that? ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 16:15:03 2012 From: report at bugs.python.org (Stefano Taschini) Date: Mon, 30 Apr 2012 14:15:03 +0000 Subject: [issue12947] Examples in library/doctest.html lack the flags In-Reply-To: <1315588954.16.0.979263107509.issue12947@psf.upfronthosting.co.za> Message-ID: <1335795303.99.0.861044107124.issue12947@psf.upfronthosting.co.za> Stefano Taschini added the comment: Ezio, the patch I attached goes into that direction, by adding a ":trim-doctest-flags: disable" option to the code blocks. I thought I had a good reason for having the option worded as ":trim-doctest-flags: disable" instead of ":keep-doctest-flags:", now I'm not so sure. Note: the patch is against the 2.7 branch. ---------- keywords: +patch Added file: http://bugs.python.org/file25424/issue12947_v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 16:23:53 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 30 Apr 2012 14:23:53 +0000 Subject: [issue13903] New shared-keys dictionary implementation In-Reply-To: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset c5fd332e5857 by Benjamin Peterson in branch 'default': change insertdict to not steal references (#13903) http://hg.python.org/cpython/rev/c5fd332e5857 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 16:32:38 2012 From: report at bugs.python.org (Michele Mazzucchi) Date: Mon, 30 Apr 2012 14:32:38 +0000 Subject: [issue7522] random.choice should accept a set as input In-Reply-To: <1260949962.37.0.861133458828.issue7522@psf.upfronthosting.co.za> Message-ID: <1335796358.51.0.67711402504.issue7522@psf.upfronthosting.co.za> Michele Mazzucchi added the comment: Folks, I really think this should be addressed. Python has beautiful data structure semantics, and this is a stain in them. An implementation based on the current underlying hash table is quite simple, just pick random addresses until an active key is found. Even on sparse tables this is probabilistic O(1). Even with average load factor = 50%, only 1 extra attempt is needed; 2 with LF as low as 33%. I'm happy to provide a patch if anyone defines the desired API in Include/setobject.h . ---------- nosy: +michelem _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 16:43:59 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 30 Apr 2012 14:43:59 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset a54b6e321f1c by Senthil Kumaran in branch '3.2': Issue11352 - Update cgi module docs http://hg.python.org/cpython/rev/a54b6e321f1c New changeset 910a4b12c796 by Senthil Kumaran in branch 'default': Issue11352 - Update cgi module docs http://hg.python.org/cpython/rev/910a4b12c796 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 16:46:12 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 30 Apr 2012 14:46:12 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1335797172.38.0.0548119210356.issue11352@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I have made the suggested specific changes, but while reviewing the entire doc, I realized that much improvements can be made. Keeping the documentation more helpful aligned with the cgi.py APIs. I shall keep bug report to update the cgi docs further. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 17:39:11 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 30 Apr 2012 15:39:11 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1335800351.45.0.759424504096.issue11352@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- nosy: -hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 17:48:28 2012 From: report at bugs.python.org (Peter Kleiweg) Date: Mon, 30 Apr 2012 15:48:28 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1335800908.34.0.210650196985.issue11352@psf.upfronthosting.co.za> Changes by Peter Kleiweg : ---------- nosy: -pebbe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 18:01:23 2012 From: report at bugs.python.org (Michael Foord) Date: Mon, 30 Apr 2012 16:01:23 +0000 Subject: [issue14558] Documentation for unittest.main does not describe some keyword arguments. In-Reply-To: <1334208375.3.0.0230518732022.issue14558@psf.upfronthosting.co.za> Message-ID: <1335801683.67.0.120366860855.issue14558@psf.upfronthosting.co.za> Michael Foord added the comment: A good change - thanks Ezio. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 18:11:24 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 30 Apr 2012 16:11:24 +0000 Subject: [issue14558] Documentation for unittest.main does not describe some keyword arguments. In-Reply-To: <1334208375.3.0.0230518732022.issue14558@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 55b2258c1c7c by Ezio Melotti in branch '2.7': #14558: document the module, argv, and testLoader args of unittest.main. http://hg.python.org/cpython/rev/55b2258c1c7c New changeset 06046a6943a7 by Ezio Melotti in branch '3.2': #14558: document the module, argv, and testLoader args of unittest.main. http://hg.python.org/cpython/rev/06046a6943a7 New changeset 6e541ed4e987 by Ezio Melotti in branch 'default': #14558: merge with 3.2. http://hg.python.org/cpython/rev/6e541ed4e987 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 18:12:07 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 30 Apr 2012 16:12:07 +0000 Subject: [issue14558] Documentation for unittest.main does not describe some keyword arguments. In-Reply-To: <1334208375.3.0.0230518732022.issue14558@psf.upfronthosting.co.za> Message-ID: <1335802327.2.0.661458780135.issue14558@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the review! ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 18:25:17 2012 From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=) Date: Mon, 30 Apr 2012 16:25:17 +0000 Subject: [issue13579] string.Formatter doesn't understand the a conversion specifier In-Reply-To: <1323587450.48.0.625379374057.issue13579@psf.upfronthosting.co.za> Message-ID: <1335803117.05.0.565253794659.issue13579@psf.upfronthosting.co.za> Francisco Mart?n Brugu? added the comment: The patch is updated. Please let me know. And as ?ric noticed the NEWS entry could be: Issue #13579: string.Formatter now understands the "a" conversion specifier. Thanks! ---------- Added file: http://bugs.python.org/file25425/issue13579_910a4b12c796.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 18:43:21 2012 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 30 Apr 2012 16:43:21 +0000 Subject: [issue10665] Expand unicodedata module documentation In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za> Message-ID: <1335804201.44.0.512052757514.issue10665@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> patch review type: -> enhancement versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 18:53:17 2012 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 30 Apr 2012 16:53:17 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: <1335804797.2.0.762956123821.issue13183@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Hello Xavier, This issue required some tracing through the calls and I see the problem that you have mentioned and patch fixes the problem. One comment on the patch, for the tests in the module, this line - self.frame_returning = None does not seem to have a coverage. Is there a specific significance in setting this to None and would a test help? def dispatch_return(self, frame, arg): if self.stop_here(frame) or frame == self.returnframe: + self.frame_returning = frame self.user_return(frame, arg) + self.frame_returning = None if self.quitting: raise BdbQuit return self.trace_dispatch Sorry for the delay, I shall commit the fix in 3.3. ---------- assignee: -> orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 18:55:26 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 30 Apr 2012 16:55:26 +0000 Subject: [issue14700] Integer overflow in classic string formatting Message-ID: <1335804926.58.0.135059540144.issue14700@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : Check for integer overflow for width and precision is buggy. Just a few examples (on platform with 32-bit int): >>> '%.21d' % 123 '000000000000000000123' >>> '%.2147483648d' % 123 '123' >>> '%.2147483650d' % 123 Traceback (most recent call last): File "", line 1, in ValueError: prec too big >>> '%.21f' % (1./7) '0.142857142857142849213' >>> '%.2147483648f' % (1./7) '0.142857' >>> '%.2147483650f' % (1./7) Traceback (most recent call last): File "", line 1, in ValueError: prec too big ---------- components: Interpreter Core messages: 159707 nosy: storchaka priority: normal severity: normal status: open title: Integer overflow in classic string formatting type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 19:02:06 2012 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 30 Apr 2012 17:02:06 +0000 Subject: [issue14532] multiprocessing module performs a time-dependent hmac comparison In-Reply-To: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za> Message-ID: <1335805326.95.0.331453227524.issue14532@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 19:05:34 2012 From: report at bugs.python.org (R. David Murray) Date: Mon, 30 Apr 2012 17:05:34 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335804926.58.0.135059540144.issue14700@psf.upfronthosting.co.za> Message-ID: <1335805534.89.0.90393161091.issue14700@psf.upfronthosting.co.za> R. David Murray added the comment: Serhiy: FYI we use the versions field to indicate which versions the fix will be made in, not which versions the bug occurs in. Since only 2.7, 3.2, and 3.3 get bug fixes, I've changed the versions field to be just those three. (3.1 and 2.6 are still in the list because they get *security* fixes, but those are rare.) ---------- nosy: +eric.smith, mark.dickinson, r.david.murray versions: -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 19:16:23 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 30 Apr 2012 17:16:23 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335804926.58.0.135059540144.issue14700@psf.upfronthosting.co.za> Message-ID: <1335806183.53.0.810659725193.issue14700@psf.upfronthosting.co.za> Mark Dickinson added the comment: Indeed, Objects/unicodeobject.c (default branch) has this, at around line 13839: if ((prec*10) / 10 != prec) { PyErr_SetString(PyExc_ValueError, "prec too big"); goto onError; } ... which since 'prec' has type int, will invoke undefined behaviour. There are probably many other cases like this one. Serhiy, what platform are you on? And are you applying any special compile-time flags? For gcc, we should be using -fwrapv, which in this case should make the above code work as intended. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 19:29:46 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 30 Apr 2012 17:29:46 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335804926.58.0.135059540144.issue14700@psf.upfronthosting.co.za> Message-ID: <1335806986.02.0.0255135111696.issue14700@psf.upfronthosting.co.za> Mark Dickinson added the comment: See get_integer in Objects/stringlib/unicode_format.h for a better way to do this sort of thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 19:31:39 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 30 Apr 2012 17:31:39 +0000 Subject: [issue9530] integer undefined behaviors In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za> Message-ID: <1335807099.05.0.557762712975.issue9530@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- dependencies: +Integer overflow in classic string formatting _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 19:35:37 2012 From: report at bugs.python.org (John Regehr) Date: Mon, 30 Apr 2012 17:35:37 +0000 Subject: [issue9530] integer undefined behaviors In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za> Message-ID: <1335807337.15.0.221708153975.issue9530@psf.upfronthosting.co.za> John Regehr added the comment: Hi folks, I realize it was a long time ago that I reported this issue! Since then our tool has been made available: http://embed.cs.utah.edu/ioc/ In particular, that web page contains a pre-compiled version of the tool for recent Ubuntu on x86-64, that should be pretty easy to use. Alternatively, I can re-run the Python test suite on a Python compiled using our tool. Let me know if this would be helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 19:43:59 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 30 Apr 2012 17:43:59 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335805534.89.0.90393161091.issue14700@psf.upfronthosting.co.za> Message-ID: <1335807987.27093.14.camel@raxxla> Serhiy Storchaka added the comment: > Serhiy: FYI we use the versions field to indicate which versions the fix will be made in, not which versions the bug occurs in. Since only 2.7, 3.2, and 3.3 get bug fixes, I've changed the versions field to be just those three. (3.1 and 2.6 are still in the list because they get *security* fixes, but those are rare.) Well, David, I understand. This ridiculous bug is unlikely security issue. Here is a patch that fixes this bug. ---------- keywords: +patch Added file: http://bugs.python.org/file25426/pyunicode_format_integer_overflow.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 6e541ed4e987 Objects/unicodeobject.c --- a/Objects/unicodeobject.c Mon Apr 30 19:11:11 2012 +0300 +++ b/Objects/unicodeobject.c Mon Apr 30 20:42:31 2012 +0300 @@ -13799,7 +13799,7 @@ c = PyUnicode_READ(fmtkind, fmt, fmtpos++); if (c < '0' || c > '9') break; - if ((width*10) / 10 != width) { + if (width >= PY_SSIZE_T_MAX / 10) { PyErr_SetString(PyExc_ValueError, "width too big"); goto onError; @@ -13834,7 +13834,7 @@ c = PyUnicode_READ(fmtkind, fmt, fmtpos++); if (c < '0' || c > '9') break; - if ((prec*10) / 10 != prec) { + if (prec >= INT_MAX / 10) { PyErr_SetString(PyExc_ValueError, "prec too big"); goto onError; From report at bugs.python.org Mon Apr 30 19:56:13 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 30 Apr 2012 17:56:13 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335806183.53.0.810659725193.issue14700@psf.upfronthosting.co.za> Message-ID: <1335808723.27093.23.camel@raxxla> Serhiy Storchaka added the comment: > Serhiy, what platform are you on? 32-bit Linux (Ubuntu), gcc 4.6. But it has to happen on any platform with a 32-bit integer (for 64-bit use 9223372036854775808). 214748364*10/10 == 214748364 -- test passed 214748364*10 + ('8'-'0') == -2147483648 -- oops! See also how is this problem solved in _struct.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 20:04:13 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 30 Apr 2012 18:04:13 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335804926.58.0.135059540144.issue14700@psf.upfronthosting.co.za> Message-ID: <1335809053.43.0.842023438672.issue14700@psf.upfronthosting.co.za> Mark Dickinson added the comment: > But it has to happen on any platform > with a 32-bit integer Not necessarily: it's undefined behaviour, so the compiler can do as it wishes. Your patch should also address possible overflow of the addition. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 20:13:00 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 30 Apr 2012 18:13:00 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335809053.43.0.842023438672.issue14700@psf.upfronthosting.co.za> Message-ID: <1335809729.27093.29.camel@raxxla> Serhiy Storchaka added the comment: > Your patch should also address possible overflow of the addition. Here there is no overflow. The patch limits prec of a little stronger (instead of 2147483647 to 2147483639 on a 32-bit platform). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 20:14:31 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 30 Apr 2012 18:14:31 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335804926.58.0.135059540144.issue14700@psf.upfronthosting.co.za> Message-ID: <1335809671.61.0.296212980132.issue14700@psf.upfronthosting.co.za> Mark Dickinson added the comment: Ah yes, true. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 20:16:22 2012 From: report at bugs.python.org (Roundup Robot) Date: Mon, 30 Apr 2012 18:16:22 +0000 Subject: [issue10433] Document unique behavior of 'getgroups' on OSX In-Reply-To: <1289916367.38.0.763799196023.issue10433@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2468b58f7fce by Ned Deily in branch '2.7': Issue #10433: Document unique behavior of 'os.getgroups' on Mac OS X. http://hg.python.org/cpython/rev/2468b58f7fce New changeset 5c801899cd6d by Ned Deily in branch '3.2': Issue #10433: Document unique behavior of 'os.getgroups' on Mac OS X. http://hg.python.org/cpython/rev/5c801899cd6d New changeset e7d545a5f6bc by Ned Deily in branch 'default': Issue #10433: merge http://hg.python.org/cpython/rev/e7d545a5f6bc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 20:17:08 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 30 Apr 2012 18:17:08 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335804926.58.0.135059540144.issue14700@psf.upfronthosting.co.za> Message-ID: <1335809828.04.0.639689737932.issue14700@psf.upfronthosting.co.za> Mark Dickinson added the comment: Any chance of some tests? :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 20:17:46 2012 From: report at bugs.python.org (Michal Nowikowski) Date: Mon, 30 Apr 2012 18:17:46 +0000 Subject: [issue14570] Document json "sort_keys" parameter properly In-Reply-To: <1334284947.71.0.88941407788.issue14570@psf.upfronthosting.co.za> Message-ID: <1335809866.08.0.00542051962198.issue14570@psf.upfronthosting.co.za> Michal Nowikowski added the comment: Attached a patch. To preserve current order of arguments in dumps/dump functions sort_keys argument has been added to the end of arguments just before **kw. ---------- keywords: +patch Added file: http://bugs.python.org/file25427/json-sort-keys.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 20:19:23 2012 From: report at bugs.python.org (Ned Deily) Date: Mon, 30 Apr 2012 18:19:23 +0000 Subject: [issue10433] Document unique behavior of 'getgroups' on OSX In-Reply-To: <1289916367.38.0.763799196023.issue10433@psf.upfronthosting.co.za> Message-ID: <1335809963.19.0.652128508819.issue10433@psf.upfronthosting.co.za> Ned Deily added the comment: Committed with minor revisions for 2.7.4, 3.2.4, and 3.3.0a3. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 20:25:27 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 30 Apr 2012 18:25:27 +0000 Subject: [issue7522] random.choice should accept a set as input In-Reply-To: <1260949962.37.0.861133458828.issue7522@psf.upfronthosting.co.za> Message-ID: <1335810327.8.0.240751729082.issue7522@psf.upfronthosting.co.za> Mark Dickinson added the comment: Michele, you might want to raise this on the python-dev or python-ideas mailing list---it'll get better exposure there than in this closed issue. For completeness, see also the previous discussion in issue 936988. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 20:28:02 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 30 Apr 2012 18:28:02 +0000 Subject: [issue14697] parser module doesn't support set displays or set comprehensions In-Reply-To: <1335735898.27.0.486602524616.issue14697@psf.upfronthosting.co.za> Message-ID: <1335810482.47.0.252502649107.issue14697@psf.upfronthosting.co.za> Mark Dickinson added the comment: Patch attached. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file25428/parser_dictorsetmaker.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 20:46:07 2012 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 30 Apr 2012 18:46:07 +0000 Subject: [issue14693] hashlib fallback modules should be built even if openssl *is* available at build time In-Reply-To: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za> Message-ID: <1335811567.72.0.180516190248.issue14693@psf.upfronthosting.co.za> Gregory P. Smith added the comment: regarding the attached patch, rather than changing the test at all, I'd leave it as is. The test as is will do what we want on the buildbots (warning us if they failed to compile when in debug mode). I am not concerned about it testing if they compiled in opt mode or not. I also do not think it is worth making them always compile on other platforms that do not use setup.py. In short: if we do anything, just make the setup.py change to get rid of the conditional compilation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 20:55:23 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 30 Apr 2012 18:55:23 +0000 Subject: [issue14701] parser module doesn't support 'raise ... from' Message-ID: <1335812123.91.0.810471517196.issue14701@psf.upfronthosting.co.za> New submission from Mark Dickinson : >>> import parser >>> parser.tuple2st(parser.expr('raise exc from e')) Traceback (most recent call last): File "", line 1, in File "", line 1 raise exc from e ---------- messages: 159724 nosy: mark.dickinson priority: normal severity: normal stage: needs patch status: open title: parser module doesn't support 'raise ... from' type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 20:58:36 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 30 Apr 2012 18:58:36 +0000 Subject: [issue14701] parser module doesn't support 'raise ... from' In-Reply-To: <1335812123.91.0.810471517196.issue14701@psf.upfronthosting.co.za> Message-ID: <1335812316.23.0.651325630288.issue14701@psf.upfronthosting.co.za> Mark Dickinson added the comment: Patch attached. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file25429/parser_yieldfrom.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 21:07:09 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 30 Apr 2012 19:07:09 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335809828.04.0.639689737932.issue14700@psf.upfronthosting.co.za> Message-ID: <1335812979.27093.37.camel@raxxla> Serhiy Storchaka added the comment: > Any chance of some tests? :-) Even a test for struct tests only struct.calcsize on this specific case. For string formatting has no such function, on most platforms testing would be a memory overflow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 21:10:43 2012 From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=) Date: Mon, 30 Apr 2012 19:10:43 +0000 Subject: [issue14466] Rip out mq instructions In-Reply-To: <1333294431.46.0.420841825384.issue14466@psf.upfronthosting.co.za> Message-ID: <1335813043.16.0.975340473648.issue14466@psf.upfronthosting.co.za> Francisco Mart?n Brugu? added the comment: Just for the record: Thanks to the old mq workflow in the devguide I've learned about them and I'm now using it all the time to send and manage the patches. The only thing is that one should first use the ?qqueue? functionality (see ?hg help qqueue?) and then in a "qqueue" all the old devguide stuff (hg qdiff, hg qpush, hg qpop, and so on...). I agree that for a beginner the actual workflow maybe easier. ---------- nosy: +francismb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 21:14:17 2012 From: report at bugs.python.org (Andrew McNabb) Date: Mon, 30 Apr 2012 19:14:17 +0000 Subject: [issue14702] os.makedirs breaks under autofs directories Message-ID: <1335813257.88.0.458381281199.issue14702@psf.upfronthosting.co.za> New submission from Andrew McNabb : When a os.makedirs is used under an autofs directory, it crashes. For example, on my machine, `os.makedirs('/net/prodigy/tmp')` crashes with the following traceback: Traceback (most recent call last): ... File "/usr/lib64/python2.7/os.py", line 157, in makedirs mkdir(name, mode) OSError: [Errno 13] Permission denied: '/net/prodigy/tmp' In this case, '/net' is an autofs directory that automatically mounts the "prodigy" directory by connecting to a host called "prodigy" using NFS. The problem seems to be related to the fact that the "/net/prodigy" directory does not actually exist until it is first accessed. I tried running `mkdir -p /net/prodigy/tmp`, and it succeeds even though the "/net/prodigy" directory did not exist before the "mkdir" command was run. I'm not sure exactly how `mkdir -p` is implemented, but one potential workaround for Python's makedirs would be to add the following at the top of the function: os.stat(name) This stat call really only needs to be run the first time makedirs is called (it does not need to be used for each recursive call). ---------- components: Library (Lib) messages: 159728 nosy: amcnabb priority: normal severity: normal status: open title: os.makedirs breaks under autofs directories versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 21:21:40 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 30 Apr 2012 19:21:40 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335808723.27093.23.camel@raxxla> Message-ID: <1335813849.27093.38.camel@raxxla> Serhiy Storchaka added the comment: > 32-bit Linux (Ubuntu), gcc 4.6. Sorry, gcc 4.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 21:32:17 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 30 Apr 2012 19:32:17 +0000 Subject: [issue14702] os.makedirs breaks under autofs directories In-Reply-To: <1335813257.88.0.458381281199.issue14702@psf.upfronthosting.co.za> Message-ID: <1335814337.51.0.880996094628.issue14702@psf.upfronthosting.co.za> Hynek Schlawack added the comment: As makedirs in 3.x doesn?t handle EPERM and is otherwise the same, I presume the error is there as well. I also presume, that after the failed makedirs(), the directory is mounted? I'd just handle the error just we handle EEXIST in 3.x now. ---------- nosy: +hynek stage: -> needs patch type: -> behavior versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 21:33:27 2012 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 30 Apr 2012 19:33:27 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335804926.58.0.135059540144.issue14700@psf.upfronthosting.co.za> Message-ID: <1335814407.97.0.0709957856997.issue14700@psf.upfronthosting.co.za> Mark Dickinson added the comment: Still, I think it would be useful to have some tests that exercise the overflow branches. (If those tests had existed before, then this issue would probably already have been found and fixed, since clang could have detected the undefined behaviour resulting from signed overflow.) I'll add tests and apply this later. ---------- assignee: -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 21:56:17 2012 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 30 Apr 2012 19:56:17 +0000 Subject: [issue14700] Integer overflow in classic string formatting In-Reply-To: <1335814407.97.0.0709957856997.issue14700@psf.upfronthosting.co.za> Message-ID: <1335815926.27093.55.camel@raxxla> Serhiy Storchaka added the comment: > I'll add tests and apply this later. Well, look at test_crasher in Lib/test/test_struct.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 21:59:08 2012 From: report at bugs.python.org (Daniel Blanchard) Date: Mon, 30 Apr 2012 19:59:08 +0000 Subject: [issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions In-Reply-To: <1280333027.17.0.112361474517.issue9400@psf.upfronthosting.co.za> Message-ID: <1335815948.43.0.800682296393.issue9400@psf.upfronthosting.co.za> Daniel Blanchard added the comment: The patch appears to fix the issue, so is there any chance of this actually getting accepted this time? It seems bizarre that such a simple bug that has been on the books for almost two years now can't get a patch accepted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 22:00:55 2012 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 30 Apr 2012 20:00:55 +0000 Subject: [issue13183] pdb skips frames after hitting a breakpoint and running step In-Reply-To: <1318618591.85.0.940577569218.issue13183@psf.upfronthosting.co.za> Message-ID: <1335816055.5.0.095507708769.issue13183@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Hi Senthil, Thanks for your help with this issue. self.frame_returning is both a flag to indicate that we are returning from the current frame and a value (the current frame). We need both as set_step() (the method invoked when the user runs the step command) does not know the current frame and wether we are returning from the current frame. Here is a raw sketch of the call chain in the case where the user types the step command on returning from the current frame (Pdb subclasses both bdb.Bdb and cmd.Cmd): Bdb::dispatch_return Pdb::user_return (Bdb overriden method) Pdb::interaction Cmd::cmdloop Cmd::onecmd Pdb::do_step Bdb::set_step So self.frame_returning must be set to None after the call to self.user_return() so that its value is not used in another later step command, where we are not returning from this frame. Actually it is more explicit and more robust to use a try-finally clause, such as: def dispatch_return(self, frame, arg): if self.stop_here(frame) or frame == self.returnframe: try: self.frame_returning = frame self.user_return(frame, arg) finally: self.frame_returning = None if self.quitting: raise BdbQuit return self.trace_dispatch Xavier ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 22:02:11 2012 From: report at bugs.python.org (Hynek Schlawack) Date: Mon, 30 Apr 2012 20:02:11 +0000 Subject: [issue14702] os.makedirs breaks under autofs directories In-Reply-To: <1335813257.88.0.458381281199.issue14702@psf.upfronthosting.co.za> Message-ID: <1335816131.29.0.0350882941195.issue14702@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 30 23:45:48 2012 From: report at bugs.python.org (Stefan Krah) Date: Mon, 30 Apr 2012 21:45:48 +0000 Subject: [issue9530] integer undefined behaviors In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za> Message-ID: <1335822348.1.0.329570038514.issue9530@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________